Прошлой ночью я вернулся к документации Dusk, и раздел об аварийном режиме заставил меня взглянуть на консенсус немного иначе.
Сначала я подумал, что аварийный механизм — это просто резерв на случай, когда валидаторы уходят в офлайн. Но детали оказываются интереснее.
В Dusk используются комитеты валидации и ратификации: случайно выбранные провайдеры голосуют о том, является ли предложенный блок корректным, и нужно ли принять результат. Для достижения кворума требуются разные пороги в зависимости от варианта голосования, включая 2/3 супербольшинства для голосов «Valid».
Что происходит, если сеть не может набрать этот кворум?
После 16 неудачных итераций, согласно документации, протокол переходит в аварийный режим. Вместо того чтобы истечь по тайм-ауту и отказаться, итерации могут оставаться открытыми, пока кандидат не получит достаточную поддержку. Несколько итераций могут выполняться одновременно, что повышает шанс получить блок, но также создает возможность форков.
Мне показалась интересной эта компромиссная схема.
Если несколько кандидатных блоков достигают консенсуса, протокол разрешает форк, выбирая кандидата из наименьшей итерации. Мне интересно, как это ведет себя при длительной перегрузке сети или частичной изоляции, особенно когда разные части сети видят сообщения в разное время.
Финальный запасной вариант еще более необычен. Если последняя итерация не срабатывает, провайдеры, у которых в сумме есть большинство от общего объема стейка, могут запросить аварийный блок. Этот блок не содержит транзакций и позволяет сети перейти в следующий раунд.
Это поднимает у меня вопросы о управлении и децентрализации.
Приведет ли требование большинства стейка для аварийного блока к полезному механизму безопасности или же оно может стать точкой влияния во время серьезного сбоя сети?
И насколько устойчива система, когда связь сильно нарушена, но разные комитеты продолжают работать?
Я все еще разбираюсь в пограничных случаях, но именно эти части дизайна консенсуса я считаю наиболее важными для понимания.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
Сначала я подумал, что аварийный механизм — это просто резерв на случай, когда валидаторы уходят в офлайн. Но детали оказываются интереснее.
В Dusk используются комитеты валидации и ратификации: случайно выбранные провайдеры голосуют о том, является ли предложенный блок корректным, и нужно ли принять результат. Для достижения кворума требуются разные пороги в зависимости от варианта голосования, включая 2/3 супербольшинства для голосов «Valid».
Что происходит, если сеть не может набрать этот кворум?
После 16 неудачных итераций, согласно документации, протокол переходит в аварийный режим. Вместо того чтобы истечь по тайм-ауту и отказаться, итерации могут оставаться открытыми, пока кандидат не получит достаточную поддержку. Несколько итераций могут выполняться одновременно, что повышает шанс получить блок, но также создает возможность форков.
Мне показалась интересной эта компромиссная схема.
Если несколько кандидатных блоков достигают консенсуса, протокол разрешает форк, выбирая кандидата из наименьшей итерации. Мне интересно, как это ведет себя при длительной перегрузке сети или частичной изоляции, особенно когда разные части сети видят сообщения в разное время.
Финальный запасной вариант еще более необычен. Если последняя итерация не срабатывает, провайдеры, у которых в сумме есть большинство от общего объема стейка, могут запросить аварийный блок. Этот блок не содержит транзакций и позволяет сети перейти в следующий раунд.
Это поднимает у меня вопросы о управлении и децентрализации.
Приведет ли требование большинства стейка для аварийного блока к полезному механизму безопасности или же оно может стать точкой влияния во время серьезного сбоя сети?
И насколько устойчива система, когда связь сильно нарушена, но разные комитеты продолжают работать?
Я все еще разбираюсь в пограничных случаях, но именно эти части дизайна консенсуса я считаю наиболее важными для понимания.
@Dusk $DUSK #dusk
#dusk $DUSK @Dusk
