Сначала я предположил, что живучесть в консенсусе Dusk — это просто функция стейка и участия: достаточно добросовестных провайдеров онлайн, и цепочка продолжает двигаться сама по себе. Но чем больше я смотрел на раздел про аварийный режим, тем тише становилась картина по сравнению с этим. Когда проходит достаточно последовательных итераций без успеха и ни один кандидат не достигает кворума, сеть не просто продолжает бесконечно ретраить в рамках собственных условий. Провайдеры могут запросить аварийный блок, а его создание зависит от seed, подписанного ключом, который в статье просто называют «Dusk», и проверяемого по публичному ключу, указанному как глобальный параметр. Сам запрос должен опираться на большинство заблокированного стейком веса, так что он не является односторонним. Тем не менее, резервный сценарий для самого худшего случая в итоге направляет процесс через одну конкретную названную сторону вместо открытой сортиции, используемой везде в остальных случаях. Возможно, это разумный компромисс для цепочки, построенной вокруг регулируемых финансов. Заставляет задуматься, лучше ли судить о децентрализации по типичному случаю или по тому, что происходит, когда типичный сценарий ломается.
#dusk #Consensus @Dusk $DUSK