Эволюция консенсуса Sui: от Tusk до Mysticeti

Sui дважды заменял своё консенсусное ядро. Сети так и не потребовался хардфорк.

Эта статья является частью серии о Sui:

• Discovering Sui: A Blockchain With Multiple Innovations
• Under the Hood of Sui: Validators, Consensus and Staking
• Sui: The Object Model, or Rethinking Blockchains Through Data
• Sui Governance: Upgrading Without Breaking
• Sui's Consensus Explained: How Narwhal and Mysticeti Finalize in 0.5 Seconds

Причина кроется в архитектурном решении. Narwhal — слой, отвечающий за распространение транзакций между валидаторами и их организацию в DAG, — оставался стабильным во всех трёх протоколах. Над ним механизм упорядочивания транзакций можно было заменять. Tusk, затем Bullshark, затем Mysticeti — каждый подключался к одному и тому же фундаменту. Там, где другим блокчейнам пришлось бы перестраиваться с нуля, Sui заменил лишь один слой.

Один терминологический момент, который стоит прояснить заранее. Sui по-разному обрабатывает два типа транзакций, и это разграничение никак не связано с тем, какой консенсусный протокол запущен. Объекты, принадлежащие одной стороне, — например, простой перевод — полностью обходят консенсус через Byzantine Consistent Broadcast, что быстрее. Консенсус для упорядочивания требуется только для общих объектов. Этот механизм действует с момента запуска Sui и работает вне зависимости от активного консенсусного протокола. Его не следует путать с эволюцией самого консенсусного протокола, которой и посвящена данная статья.

Tusk: асинхронная отправная точка

Tusk был разработан для сети, в которой ничего нельзя предполагать относительно времени доставки сообщений. Никаких временны́х ограничений, никаких допущений о синхронности. Это наиболее неблагоприятный сценарий — и при этом наиболее реалистичный для глобальной сети, где условия сильно различаются от одного валидатора к другому.

Основная идея: как только DAG Narwhal построен, консенсус достигается без какой-либо дополнительной коммуникации. Каждый валидатор применяет один и тот же детерминированный алгоритм к своему локальному представлению DAG и приходит к тому же порядку, что и все остальные валидаторы. Никаких раундов голосования, никакой явной координации. Порядок считывается из самой референсной структуры путём определения якорных точек, выступающих в роли маркеров фиксации (commit markers).

Бенчмарки из оригинальной статьи, измеренные на 20 валидаторах, показали пропускную способность около 160 000 транзакций в секунду при задержке примерно 3 секунды. На тот момент это опережало возможности классических систем.

Две проблемы оставались нерешёнными. Первая — задержка: 3 секунды приемлемы для многих сценариев, но неприемлемы для трейдинга или игр в реальном времени. Вторая — справедливость. В полностью асинхронной среде лучше подключённые валидаторы видели свои транзакции включёнными чаще, чем другие, — структурный дисбаланс в пользу самых быстрых узлов.

Tusk существовал преимущественно в исследовательской среде и на тестовой сети. К моменту запуска мейннета Sui в 2023 году Bullshark уже был в деле.

Bullshark: частичная синхронность

Концептуальный прорыв Bullshark основан на одном допущении: большую часть времени сеть ведёт себя нормально. Вместо того чтобы всегда готовиться к худшему, протокол использует периоды, когда сообщения поступают в разумные сроки. Это частично синхронная модель: при нормальных условиях предполагаются временны́е ограничения; асинхронная устойчивость включается при деградации сети.

Из этого допущения следует реальный быстрый путь Bullshark — не следует путать его с упомянутым выше различием между собственными и общими объектами. В синхронные периоды протокол может выполнять фиксацию быстрее, не ожидая столько раундов, как в режиме деградации. Это сокращение задержки, обусловленное состоянием сети.

Bullshark также решил проблему справедливости, оставшуюся нерешённой в Tusk, — с помощью слабых связей (weak links). Эти связи позволяют временно медленному валидатору быть включённым в окончательный консенсус, даже если более быстрые валидаторы ещё не ссылались на него. Ни один честный валидатор не отстраняется из-за плохого соединения. Протокол также усовершенствовал выбор якорей и очистку памяти, что позволило ему выдерживать нагрузку в течение длительных периодов.

Цена: большая сложность. Слабые связи и адаптация к сети порождают граничные случаи и вычислительные накладные расходы. В статье сообщается о 125 000 TPS при задержке 2 секунды на 50 участниках — ниже, чем у Tusk на бумаге, но сравнение вводит в заблуждение: Tusk измерялся на 20 валидаторах, а пропускная способность механически снижается по мере роста сети. Эти два показателя нельзя напрямую сравнивать. Задержка, между тем, оставалась в диапазоне секунды — всё ещё слишком медленно для самых требовательных приложений.

Для Sui переход имел одну главную ценность: доказательство того, что сеть может менять консенсус без сбоев. Значимый сигнал доверия для разработчиков, строящих на её основе.

Mysticeti: отказ от явной сертификации

Mysticeti не расширяет Bullshark — он меняет лежащую в основе логику. Tusk и Bullshark оба опираются на сертифицированный DAG: каждый блок должен быть подписан кворумом валидаторов, прежде чем считается доступным. Такая сертификация обходится дорого — в подписях для создания и проверки, а также в сетевых обменах. Это было узким местом обоих предыдущих поколений.

Mysticeti полностью устраняет этот шаг. Он работает на несертифицированном DAG: валидаторы подписывают и транслируют свои блоки — и всё. Соглашение больше не голосуется; оно выводится. Когда валидатор ссылается на блок другого в своём собственном выводе, этот акт ссылки представляет собой неявное одобрение. Консенсус выводится из поведения ссылок, без каких-либо специализированных сообщений для голосования вообще.

Результаты проявляются в двух измерениях. По задержке Mysticeti выполняет фиксацию за три раунда сообщений — теоретический минимум, сопоставимый с практическими BFT-системами. По ресурсам устранение тысяч подписей за раунд значительно снижает нагрузку на CPU: примерно на 40% меньше в продакшне (с ~48% до ~29% на развёрнутых валидаторах). Протокол также запускает несколько лидеров параллельно в каждом раунде, что снижает медианные и хвостовые задержки, и он поглощает недоступность лидера без остановки.

Вариант Mysticeti-FPC добавляет быстрый путь фиксации для переводов активов. Его отличительная черта — вплетение этих транзакций непосредственно в DAG, а не их отдельная обработка, что экономит подписи и сообщения. Именно здесь живёт реальный быстрый путь фиксации, встроенный в структуру, — а не в Bullshark.

Показатели, измеренные в контролируемой среде: 300 000 TPS при 10 узлах и 400 000 TPS при 50 узлах до того, как задержка превышает одну секунду. При устойчивой нагрузке фиксации происходят примерно за 0,5 секунды при 200 000 TPS. В тех же тестах другие ведущие протоколы достигают пика ниже 150 000 TPS при задержках от примерно 2 секунд.

Также широко цитируется «снижение задержки на 80% по сравнению с Bullshark» (с ~1,9 с до ~400 мс). Цифра точна, но это сравнение в лучшем случае: оно противопоставляет Bullshark в условиях деградации и Mysticeti в оптимальных условиях. При типичной нагрузке на общие объекты выигрыш скромнее, хотя ни одно публичное измерение не даёт точной цифры. Стоит также помнить: цифры 200 000–400 000 TPS получены из контролируемых бенчмарков. В мейннете, в реальных условиях, наблюдаемая пропускная способность значительно ниже.

Что показывает эта траектория

Выстраивая три поколения в ряд, прогресс очевиден — при условии, что цифры читаются в контексте.

Пропускная способность растёт с ~160 000 TPS (Tusk, 20 валидаторов) до 125 000 TPS (Bullshark, 50 участников), а затем до 300 000–400 000 TPS в зависимости от конфигурации (Mysticeti). Количество узлов различается, поэтому эти значения нельзя сравнивать напрямую: они дают порядок величины, а не строгий рейтинг. Задержка, напротив, снижается однозначно: с 3 секунд до примерно 0,5 секунды, проходя через ~2 секунды у Bullshark. С точки зрения коммуникации прогресс движется от нулевых накладных расходов после построения DAG (но с дорогостоящей сертификацией на предыдущем этапе) к неявной сертификации, устраняющей большую часть трафика голосования.

Реальная точка перелома находится не между Tusk и Bullshark — оба принадлежат к одному семейству: сертифицированный DAG, явная сертификация, инкрементальные оптимизации. Разрыв — между Bullshark и Mysticeti, с отказом от сертификации. Tusk и Bullshark оптимизировали шаг; Mysticeti устранил его.

Стоит подчеркнуть одну вещь: во всех трёх протоколах Narwhal почти не изменился. Все инновации сосредоточились на слое упорядочивания, не дестабилизируя распространение данных. Именно это разделение ответственности сделало возможными замены без прерывания сервиса — тот вид архитектурного выбора, который не окупается немедленно, но в итоге меняет всё.

Mysticeti, вероятно, не последнее слово. Подход Sui — именно в том, чтобы заменять компонент, когда появляется лучший, не трогая остальное. Если появится четвёртое поколение, оно, скорее всего, подключится к тому же Narwhal.

Источники

• Tusk — Danezis, Kokoris-Kogias, Sonnino, Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus (2021). arXiv · PDF
• Bullshark — Spiegelman, Giridharan, Sonnino, Kokoris-Kogias. Bullshark: DAG BFT Protocols Made Practical (2022). arXiv · PDF
• Mysticeti — Babel, Chursin, Danezis, Kichidis, Kokoris-Kogias, Koshy, Sonnino, Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs (2023, NDSS 2025). arXiv · PDF

Эволюция консенсуса Sui: от Tusk до Mysticeti была первоначально опубликована в Coinmonks на Medium, где люди продолжают обсуждение, выделяя и отвечая на эту историю.