#dusk $DUSK
Фраза «аварийный режим» снова и снова появлялась в белой книге Dusk, и я все проходил мимо нее. Когда я наконец прочитал раздел, выяснилось, что механизм точнее, чем подсказывает само название.
Нормальный консенсус Dusk: каждый раунд выполняется максимум до 50 итераций. На каждом шаге — Proposal (предложение), Validation (валидация), Ratification (ратификация) — есть таймаут. Если к таймауту не сформируется кворум, шаг пропускается, и в итоге начинается новая итерация. Последовательно, ограниченно, предсказуемо.
Аварийный режим устроен иначе. Он включается после 16 подряд неудачных итераций — где «неудачных» означает, что кворум так и не был достигнут, обычно потому что валидаторы офлайн или изолированы. После включения: таймауты шагов отключаются. Запускаются новые итерации, но каждая текущая итерация остается активной, вместо того чтобы закрываться. Несколько открытых итераций работают параллельно. Это повышает шанс произвести блок. А также повышает шанс форков.
Форки в аварийном режиме разрешаются выбором блока с наименьшим номером итерации. Если сеть все равно не может сформировать блок, последняя мера — аварийный блок: пустой блок, без транзакций, подписанный Dusk как сущностью с использованием ее глобального публичного ключа. Провайдеры, владеющие большинством доли, запрашивают его.
Так почему бы сети просто не включать аварийный режим всякий раз, когда хочется работать быстрее.
Нормальный режим жертвует частью скорости ради более чистой окончательности. Параллельные открытые итерации повышают живучесть под нагрузкой, но добавляют сложность. Падение к пустому блоку — это централизованное вмешательство: цепь продолжает двигаться, но Dusk как сущность оказывается тем, кто ее двигает.
На самом деле я нахожу вопрос о том, как устроен аварийный блок, более интересным — потому что это означает: гарантия живучести в конечном счете зависит от доступности сущности Dusk и ее готовности подписывать. Безопасность протокола и децентрализация тянут в слегка разные стороны.
То, что мне не доводилось видеть объясненным, — это что происходит с транзакциями, которые были в полете, когда аварийный блок заменяет обычный блок: попадают ли они повторно в следующую итерацию или же отбрасываются. @Dusk
$DUSK #dusk
Фраза «аварийный режим» снова и снова появлялась в белой книге Dusk, и я все проходил мимо нее. Когда я наконец прочитал раздел, выяснилось, что механизм точнее, чем подсказывает само название.
Нормальный консенсус Dusk: каждый раунд выполняется максимум до 50 итераций. На каждом шаге — Proposal (предложение), Validation (валидация), Ratification (ратификация) — есть таймаут. Если к таймауту не сформируется кворум, шаг пропускается, и в итоге начинается новая итерация. Последовательно, ограниченно, предсказуемо.
Аварийный режим устроен иначе. Он включается после 16 подряд неудачных итераций — где «неудачных» означает, что кворум так и не был достигнут, обычно потому что валидаторы офлайн или изолированы. После включения: таймауты шагов отключаются. Запускаются новые итерации, но каждая текущая итерация остается активной, вместо того чтобы закрываться. Несколько открытых итераций работают параллельно. Это повышает шанс произвести блок. А также повышает шанс форков.
Форки в аварийном режиме разрешаются выбором блока с наименьшим номером итерации. Если сеть все равно не может сформировать блок, последняя мера — аварийный блок: пустой блок, без транзакций, подписанный Dusk как сущностью с использованием ее глобального публичного ключа. Провайдеры, владеющие большинством доли, запрашивают его.
Так почему бы сети просто не включать аварийный режим всякий раз, когда хочется работать быстрее.
Нормальный режим жертвует частью скорости ради более чистой окончательности. Параллельные открытые итерации повышают живучесть под нагрузкой, но добавляют сложность. Падение к пустому блоку — это централизованное вмешательство: цепь продолжает двигаться, но Dusk как сущность оказывается тем, кто ее двигает.
На самом деле я нахожу вопрос о том, как устроен аварийный блок, более интересным — потому что это означает: гарантия живучести в конечном счете зависит от доступности сущности Dusk и ее готовности подписывать. Безопасность протокола и децентрализация тянут в слегка разные стороны.
То, что мне не доводилось видеть объясненным, — это что происходит с транзакциями, которые были в полете, когда аварийный блок заменяет обычный блок: попадают ли они повторно в следующую итерацию или же отбрасываются. @Dusk
$DUSK #dusk
