emergencymode

Я уже несколько недель держу небольшую позицию в $DUSK , в основном просто наблюдаю. Ничего драматичного — вчера лишь немного увеличил её после того, как заметил в документации к протоколу кое-что, о чём, насколько я видел, никто не говорил.

Речь о том, что происходит, когда консенсус просто… перестаёт работать. Не из‑за атаки. Не из‑за бага. Просто потому, что валидаторы начинают молчать.

У Dusk есть режим, называемый Emergency Mode. И моё первоначальное понимание было таким, что он существует, чтобы производить аварийные блоки. Это не совсем так.

Главная цель — сохранять живость (liveness), когда участие стейка становится ненадёжным.

Вот что привлекло моё внимание: Dusk не «замораживается», если валидаторы продолжают пропускать. Вместо этого он оставляет открытыми предыдущие итерации консенсуса, пока параллельно начинаются новые. Оставшимся провайдеры получают больше попыток договориться, вместо того чтобы упираться в жёсткую стену.

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

И если даже это не срабатывает, вступает в игру Emergency Block Request.

Как только EBR’ы, представляющие большинство стейка, накапливаются, цепочка производит пустой блок — без транзакций, только непрерывность и новый seed для следующего раунда.

Этот выбор дизайна говорит мне о том, что @Dusk не строит систему в расчёте на идеальные условия.

Он строит её для момента, когда эти условия ломаются.

Чего я пока искренне не знаю: как работает этот путь восстановления, если участие остаётся деградированным на протяжении нескольких подряд раундов. Вот это испытание нагрузкой я бы хотел увидеть в документации.

#Dusk #EmergencyMode #DuskEVM
Что в первую очередь важно в дизайне Emergency Mode от Dusk?