#dusk $DUSK @Dusk
Раньше я думал, что Режим Чрезвычайной Ситуации Dusk — это просто план на случай, когда сеть не сможет сгенерировать блок.
Но после более глубокого рассмотрения я думаю, что здесь заложена более интересная идея: как поддерживать работу блокчейна, когда нормальный консенсус начинает давать сбои?
Обычно Dusk проходит через итерации, в которых предлагаются блоки, выполняется их проверка и последующая ратификация. Но если слишком много провайдеров уходит офлайн, несколько итераций могут провалиться одна за другой.
После 16 подряд неудачных итераций Dusk может перейти в Режим Чрезвычайной Ситуации.
То, что здесь меняется, довольно интересно. Обычные тайм-ауты шагов перестают быть главным ограничением, и несколько открытых итераций могут продолжать попытки, пока одна из них не получит кворум.
Конечно, это создает еще одну проблему. Несколько кандидатов означают и более высокий шанс конкурирующих блоков.
Dusk решает это тем, что принимает успешный блок из итерации с наименьшим номером и закрывает остальные открытые итерации.
Но что произойдет, если даже последняя итерация не сможет набрать кворум?
Именно здесь появляются Запросы Экстренных Блоков.
Если большинство провайдеров с учетом доли запрашивает один из них, Dusk может создать специальный пустой блок, подписанный самим Dusk, что позволяет цепочке продвинуться дальше, вместо того чтобы застрять бесконечно.
Часть, которая мне кажется наиболее интересной, — это компромисс.
Dusk добавляет контролируемый централизованный аварийный механизм, чтобы защитить живучесть сети при крайнем сценарии отказа.
Так что, возможно, реальный вопрос не в том, насколько Режим Чрезвычайной Ситуации децентрализован.
Вопрос в том, оправдана ли эта небольшая уступка ценой того, что сеть остается живой в худшем случае.
Именно этот баланс между децентрализацией и живучестью делает дизайн консенсуса Dusk для меня таким интересным.
Раньше я думал, что Режим Чрезвычайной Ситуации Dusk — это просто план на случай, когда сеть не сможет сгенерировать блок.
Но после более глубокого рассмотрения я думаю, что здесь заложена более интересная идея: как поддерживать работу блокчейна, когда нормальный консенсус начинает давать сбои?
Обычно Dusk проходит через итерации, в которых предлагаются блоки, выполняется их проверка и последующая ратификация. Но если слишком много провайдеров уходит офлайн, несколько итераций могут провалиться одна за другой.
После 16 подряд неудачных итераций Dusk может перейти в Режим Чрезвычайной Ситуации.
То, что здесь меняется, довольно интересно. Обычные тайм-ауты шагов перестают быть главным ограничением, и несколько открытых итераций могут продолжать попытки, пока одна из них не получит кворум.
Конечно, это создает еще одну проблему. Несколько кандидатов означают и более высокий шанс конкурирующих блоков.
Dusk решает это тем, что принимает успешный блок из итерации с наименьшим номером и закрывает остальные открытые итерации.
Но что произойдет, если даже последняя итерация не сможет набрать кворум?
Именно здесь появляются Запросы Экстренных Блоков.
Если большинство провайдеров с учетом доли запрашивает один из них, Dusk может создать специальный пустой блок, подписанный самим Dusk, что позволяет цепочке продвинуться дальше, вместо того чтобы застрять бесконечно.
Часть, которая мне кажется наиболее интересной, — это компромисс.
Dusk добавляет контролируемый централизованный аварийный механизм, чтобы защитить живучесть сети при крайнем сценарии отказа.
Так что, возможно, реальный вопрос не в том, насколько Режим Чрезвычайной Ситуации децентрализован.
Вопрос в том, оправдана ли эта небольшая уступка ценой того, что сеть остается живой в худшем случае.
Именно этот баланс между децентрализацией и живучестью делает дизайн консенсуса Dusk для меня таким интересным.