#dusk $DUSK Вчера обновил версию белой книги от Dusk и дошёл до раздела про консенсус Citadel — перечитал два раза, и только тогда осознал, насколько по-ленивому я раньше понимал PoS: я всё время по умолчанию считал, что консенсус PoS — это «кто стейкает больше, тот и решает», а затем в этих рамках обсуждал децентрализацию. Но в схеме Citadel «кто решает» и «кто может предложить следующий блок» разнесены на два независимых вопроса.
В Citadel используется механизм слепого отбора (blind selection) с шифрованной лотереей и поочерёдным выбыванием: на каждом раунде через VRF случайным образом выбирается комитет среди стейкеров, а внутри комитета затем запускается голосование в стиле BFT, чтобы сформировать финальный блок. Эта конструкция рвёт цепочку «больше стейка = больше контроля»: то, что вы держите больше, лишь повышает вероятность, что вас выберут, но не гарантирует, что вы обязательно сможете доминировать в результате консенсуса. Вдобавок Kadcast — это сетевой слой, который оптимизирует распространение: блоки между узлами пересылаются не традиционным gossip-«разливом» (flooding), а послойно, в соответствии с сетевой топологией; расход пропускной способности по сравнению с протоколом Gossip ниже на 25–50%.
Когда эти два уровня накладываются друг на друга, у меня создаётся ощущение, что Dusk в вопросе «эффективности» продумали больше мелочей, чем большинство L1. Случайность на уровне консенсуса обеспечивает устойчивость к цензуре; структурированное распространение на уровне сети снижает задержки; а затем поверх этого лежит Piecrust — VM, специально оптимизированная под доказательства с нулевым разглашением (zero-knowledge). Вся логика выбора технологий согласована между собой: это не «собрать пачку модных терминов», а сделать так, чтобы связка «комплаенс + приватность» реально работала на практике, а не оставалась красивыми словами из белой книги.
Но есть один момент, который я ещё не до конца продумал: случайность отбора в комитет полностью зависит от безопасности VRF. Если в реализации VRF или в генерации seed есть предсказуемые уязвимости, то вся предпосылка безопасности консенсуса становится шаткой. Эту часть я пока не нашёл в аудиторском отчёте Dusk — может, кто-то уже видел и подскажет, где это искать.
Кошелёк без изменений: добавляли стейк только те узлы, которые ждут данных о реальном времени выпуска блоков и показателях форков после запуска mainnet Citadel.
Как думаете, такая схема консенсуса с «слепым отбором» действительно будет устойчивее к цензуре, чем традиционный DPoS? Поделитесь логикой в комментариях. @Dusk $BTC