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

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

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

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

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

Для организаций такой подход к обработке пограничных ситуаций, вероятно, стоит включать в due diligence даже больше, чем обычные ежедневные секундные расчёты. В нормальном режиме большинство финансовых блокчейнов уровня enterprise способны демонстрировать хорошую работу. Настоящее различие проявляется тогда, когда система даёт сбой: что именно предложено — «деградация, но продолжение работы» или «прямая блокировка».

#dusk $DUSK @Dusk
Как вы считаете, при оценке надёжности сети, насколько большой вес должен занимать дизайн ответных мер на крайних сценариях?