Я прошлой ночью вернулся к документации по Dusk, в частности к разделам про алгоритм DS и то, как выбираются провайдеры (provisioners) для консенсуса.

Сначала я попытался сопоставить правила допуска по доле. Доля провайдера S считается подходящей только в том случае, если ее размер не меньше минимального значения (установлено на 1000 DUSK) и ее возраст/длительность лежат в диапазоне от 0 до M. Затем процесс DS ранжирует эти подходящие доли по показателю, который смешивает размер доли с детерминированной функцией предыдущего хеша блока и публичного ключа провайдера. Провайдер с наивысшим score становится тем, кто может предложить следующий блок.

Читая дальше, поток стал яснее: выбранный провайдер транслирует кандидатный блок, комитет из других провайдеров выполняет валидацию, и если появляется простое большинство (½ + 1) сообщений ValidBk, блок переходит к ратификации. Само по себе подтверждение (ratification) требует более строгого порога ⅔ + 1, прежде чем блок считается окончательно зафиксированным (finalized) и новая группа провайдеров блокируется. Комитеты для аттестации и голосования формируются тем же детерминированным способом, просто с другими seed-ами.

Что пока остается для меня не до конца проясненным, так это насколько сильно вся цепочка чувствительна к точному значению M и к порогу 1000 DUSK. Если эти параметры сдвигаются, меняется ли эффективная децентрализация набора провайдеров в способах, которые трудно разглядеть извне? И если блок уже аттестован, то насколько практические способы восстановления/обжалования (recourse) существуют, если позже аудит покажет, что DS-ранжирование было «подкручено»?

Интересно, как другие, которые также копались в этих же страницах, трактуют запасы прочности (security margins) вокруг тех порогов большинства.
#dusk $DUSK @Dusk