Вчера я смотрел правила окончательности Dusk, и одна небольшая формула заставила меня остановиться: 2 × n.
Сначала я думал, что «прокатка» окончательности — это просто ожидание фиксированного числа блоков. Но Dusk делает это иначе.
Здесь n — это число предыдущих ненадтестированных (non-attested) итераций блока в том же раунде. Если n = 0, новый блок помечается как attested (подтверждённый). Подтверждённый блок становится confirmed (окончательно подтверждённым), когда его преемник становится attested или confirmed.
Но когда n > 0, всё меняется.
Блок становится accepted (принятым), и для того чтобы стать confirmed, ему нужно 2 × n подряд идущих блоков, отмеченных как attested или confirmed.
Итак, если n = 1 — 2 блока.
Если n = 2 — 4 блока.
Если n = 3 — 6 блоков.
Если n = 4 — 8 блоков.
В whitepaper приводится простой пример: если блок находится на итерации 5 и две более ранние итерации не смогли стать attested, ему нужно ещё 4 блока (2 × 2), которые должны быть attested или confirmed до подтверждения. После этого он становится финальным, когда его родитель уже финален.
Мне интересно, что Dusk не относится ко каждому блоку одинаково.
Блок, который приходит после неудачных более ранних итераций, несёт больше неопределённости, поэтому протокол запрашивает больше доказательств.
Для меня 2×n — это по сути адаптивный буфер безопасности.
Больше неудачных путей → требуется больше подтверждений.
Вот что в Rolling Finality теперь мне стало гораздо понятнее.
#dusk @Dusk $DUSK
Сначала я думал, что «прокатка» окончательности — это просто ожидание фиксированного числа блоков. Но Dusk делает это иначе.
Здесь n — это число предыдущих ненадтестированных (non-attested) итераций блока в том же раунде. Если n = 0, новый блок помечается как attested (подтверждённый). Подтверждённый блок становится confirmed (окончательно подтверждённым), когда его преемник становится attested или confirmed.
Но когда n > 0, всё меняется.
Блок становится accepted (принятым), и для того чтобы стать confirmed, ему нужно 2 × n подряд идущих блоков, отмеченных как attested или confirmed.
Итак, если n = 1 — 2 блока.
Если n = 2 — 4 блока.
Если n = 3 — 6 блоков.
Если n = 4 — 8 блоков.
В whitepaper приводится простой пример: если блок находится на итерации 5 и две более ранние итерации не смогли стать attested, ему нужно ещё 4 блока (2 × 2), которые должны быть attested или confirmed до подтверждения. После этого он становится финальным, когда его родитель уже финален.
Мне интересно, что Dusk не относится ко каждому блоку одинаково.
Блок, который приходит после неудачных более ранних итераций, несёт больше неопределённости, поэтому протокол запрашивает больше доказательств.
Для меня 2×n — это по сути адаптивный буфер безопасности.
Больше неудачных путей → требуется больше подтверждений.
Вот что в Rolling Finality теперь мне стало гораздо понятнее.
#dusk @Dusk $DUSK
Fixed Finality
100%
Adaptive Finality
0%
Stronger Security
0%
2 проголосовали • Голосование закрыто
