На прошлой неделе в Исламабаде у нас была сессия отключения электроэнергии: сеть просто продолжала выходить из строя снова и снова, и каждый раз, когда она возвращалась, резервная система должна была перезапускаться с нуля, а не продолжать с того места, где остановилась. Я предположил, что аварийный режим Dusk работает так же: сетевые зависания, и он просто продолжает повторять один и тот же фиксированный таймаут, пока что-нибудь не сработает.
Но это не так. Аварийный режим включается только после 16 подряд неудачных итераций, и когда он активируется, вся структура таймаутов удаляется. Итерации больше не истекают — они выполняются бесконечно, пока кандидатский блок не будет фактически предложен и не достигнет квorum как на этапе валидации, так и на этапе ратификации. Голоса NoCandidate и NoQuorum тоже отключаются, так что каждый шаг должен корректно завершиться, прежде чем начнётся следующий.
То, что для меня всё переосмыслило, — что несколько таких открытых итераций могут выполняться одновременно. Это не ошибка — это задумано: так повышаются шансы, что хотя бы одна итерация произведёт валидный блок. Компромисс в том, что возрастает риск форков, который решается тем, что всегда выбирается тот кандидат, который достиг консенсуса на наименьшем номере итерации.
Есть ещё и план «последний резерв» внутри «последнего резерва». Если даже финальная итерация зависает, валидаторы, удерживающие большинство от общего стейка, могут запросить аварийный блок — специальный пустой блок, подписанный Dusk, без каких-либо транзакций, просто чтобы раунд продолжился.
Чего whitepaper не говорит — это как часто это реально срабатывало на инфраструктуре Dusk до сих пор. У меня нет данных, чтобы утверждать какую-то частоту.

Настоящая проверка для DUSK — насколько редко аварийный режим должен запускаться после того, как mainnet начнёт работать в реальном масштабе.
Кто-нибудь уже видел, как на Dusk срабатывает аварийный режим?
@Dusk #dusk $DUSK