#dusk $DUSK @Dusk $DUSK

Предложение, Валидация, Ратификация: Трёхшаговый путь Dusk к финальному блоку

я всё время предполагал, что финальность блока в Dusk работает как одно голосование — предложить, подтвердить, и всё готово.

на самом деле это три отдельных шага, и мне пришлось пройти через каждый, чтобы понять почему.

шаг Предложение выбирает одного провайдер-валидатора (provisioner) с помощью детерминированной стохастической отборки (deterministic sortition), чтобы он сгенерировал кандидатный блок и разослал его. если ничего не приходит до истечения таймаута, эта итерация просто проваливается — без кандидата, и, насколько я могу судить по документации, в этом месте нет процедур резервной генерации.

я проследил, что происходит дальше. результат подаётся на Валидацию: новая комиссия, также случайно выбранная, проверяет кандидат относительно текущего хвоста (tip) цепочки и голосует «Valid» или «Invalid». кворум должен набрать две трети голосов «Valid» либо простое большинство голосов «Invalid» — любой из порогов завершает шаг.

третий шаг — и вот его я почти упустил: Ратификация. это ещё одна комиссия, которая голосует именно о том, достигла ли Валидация реального кворума, а не о содержимом блока. здесь действует то же правило двух третей или большинства — применимое и к этому шагу.

три комиссии, три отдельных решения — я не смог найти ни одной ситуации, где шаг повторял бы работу, которую уже выполнил предыдущий.

что бросилось в глаза, так это степень проверки, которой эта последовательность подверглась перед mainnet. Dusk провела десять аудитов по всему своему стеку, более двухсот страниц отчётов. один из этих десяти — Oak Security — был сфокусирован именно на SA, отмечая проблемы вокруг стимулов к слэшингу и логики голосования — все критические вопросы были решены до запуска.

так что «финализация блока» — это, насколько мне кажется, не одно решение. это три независимо подтверждённых проверки, уложенные друг за другом, и каждая способна перезапустить процесс — до пятидесяти итераций на раунд — если он не проходит.

снижает ли такой уровень проверок до запуска риск в данном случае, или это просто означает, что любая ошибка, которая проскочит, окажется потом в разы сложнее для обнаружения?