#dusk $DUSK Сегодня я разбирал(а) консенсус-протокол SA с кодом @Dusk и застрял(а) на одном слове: "committee-based". Многие PoS-цепочки используют механизм комитетов, но SA Dusk — Succinct Attestation — разбивает процесс на три шага: предложение, проверка и утверждение; и каждый шаг выполняет отдельный случайно выбранный provisioner.
На первом шаге один provisioner создает и транслирует кандидатный блок. На втором шаге проверочный комитет оценивает корректность блока. На третьем шаге другой комитет утверждения подтверждает результат проверки и финализирует блок. На первый взгляд кажется, что шагов стало больше, но этот шаг разъединяет "проверку" и "подтверждение результата проверки".
Я понимаю замысел этого дизайна: если проверку и утверждение выполняют одни и те же люди, то сам результат проверки становится окончательным вердиктом без противовеса. Разделение на два шага означает, что комитет утверждения должен смотреть не только на блок, но и на то, выполнял ли комитет проверки работу добросовестно. По сути, это добавляет в консенсус дополнительный слой контроля качества.
У этого дизайна есть и скрытое ограничение: комитеты выбираются случайно, в зависимости от объема стейка. Атакующему, чтобы контролировать какой-то шаг, нужно одновременно контролировать большое количество стейка и при этом случайно попасть в один и тот же комитет. С точки зрения вероятности это гораздо сложнее, чем контролировать одну группу верификаторов.
Но у пошагового консенсуса есть цена — задержка. Каждый дополнительный шаг добавляет еще один раунд обмена сообщениями. Как SA сохраняет низкую задержку подтверждения в сценариях высокочастотных финансовых транзакций — это место, где я пока не нашел(ла) достаточно данных в открытой документации.
Смотря на уровни консенсуса #dusk , я буду продолжать следить за интервалами от выпуска блока до финализации, частотой ротации комитетов и фактической скоростью разветвлений в сети. Для DUSK как стейкового актива предположения о безопасности консенсуса напрямую определяют тип рисков, с которыми сталкиваются стейкхолдеры. #dusk @Dusk
На первом шаге один provisioner создает и транслирует кандидатный блок. На втором шаге проверочный комитет оценивает корректность блока. На третьем шаге другой комитет утверждения подтверждает результат проверки и финализирует блок. На первый взгляд кажется, что шагов стало больше, но этот шаг разъединяет "проверку" и "подтверждение результата проверки".
Я понимаю замысел этого дизайна: если проверку и утверждение выполняют одни и те же люди, то сам результат проверки становится окончательным вердиктом без противовеса. Разделение на два шага означает, что комитет утверждения должен смотреть не только на блок, но и на то, выполнял ли комитет проверки работу добросовестно. По сути, это добавляет в консенсус дополнительный слой контроля качества.
У этого дизайна есть и скрытое ограничение: комитеты выбираются случайно, в зависимости от объема стейка. Атакующему, чтобы контролировать какой-то шаг, нужно одновременно контролировать большое количество стейка и при этом случайно попасть в один и тот же комитет. С точки зрения вероятности это гораздо сложнее, чем контролировать одну группу верификаторов.
Но у пошагового консенсуса есть цена — задержка. Каждый дополнительный шаг добавляет еще один раунд обмена сообщениями. Как SA сохраняет низкую задержку подтверждения в сценариях высокочастотных финансовых транзакций — это место, где я пока не нашел(ла) достаточно данных в открытой документации.
Смотря на уровни консенсуса #dusk , я буду продолжать следить за интервалами от выпуска блока до финализации, частотой ротации комитетов и фактической скоростью разветвлений в сети. Для DUSK как стейкового актива предположения о безопасности консенсуса напрямую определяют тип рисков, с которыми сталкиваются стейкхолдеры. #dusk @Dusk
三步共识比两步更安全吗
100%
SA的最终确认到底要多久
0%
质押者面临的最大风险是啥?
0%
1 проголосовали • Голосование закрыто