Я вернулся прошлой ночью к whitepaper’у Dusk, уделив особое внимание разделам про режим аварийного восстановления, fallback и rolling finality. Детали оказались более тонкими, чем я сперва ожидал.

Режим аварийного восстановления активируется после 16 неудачных итераций. Затем отключаются таймауты шагов, а открытые итерации продолжаются до тех пор, пока кандидатный блок не достигнет кворума как в валидации, так и в ратификации. Одновременно могут выполняться несколько итераций, что повышает шанс получить блок, но также увеличивает вероятность форков. Если несколько кандидатов приходят к консенсусу, выбирается итерация с наименьшим номером. На последней итерации провайдеры (provisioners) могут запросить аварийный блок, но для этого они должны контролировать большинство от общего объёма стейка в сети.

Правила fallback тоже привлекли моё внимание: блок из итерации J > 0 потенциально может быть заменён блоком с более низкой итерацией, который позже достигнет консенсуса, тогда как итерацию 0 таким образом заменить нельзя.

Затем rolling finality добавляет ещё один уровень. Если n предыдущих итераций провалили аттестацию, блок принимается и для того, чтобы стать подтверждённым, ему нужно 2×n подряд идущих аттестованных или подтверждённых блоков. В примере из статьи используется итерация 5, n=2, то есть требуется ещё 4 блока.

Я всё ещё размышляю: создаёт ли такая конструкция какие-либо существенные риски централизации вокруг аварийного восстановления, зависящего от стейка?

@Dusk #dusk $DUSK