MonadBFT: Переопределение безопасности консенсуса блокчейна, прощание с рисками хвостовых форков

Автор：michaellwy

Ядро блокчейна заключается в достижении строгого глобального консенсуса (strict global consensus): то есть, независимо от того, в какой стране или часовом поясе расположены узлы сети, все участники в конечном итоге должны прийти к согласию по набору объективных результатов.

Но реальные распределенные сети не идеальны: некоторые узлы отключаются, некоторые лгут, и даже есть те, кто намеренно саботирует работу. В таких условиях как система может говорить «одним голосом» и保持一致？

Именно эту проблему решает протокол консенсуса. По сути, это набор правил,指导如何指导一群彼此独立、甚至不完全可信的节点，如何就每笔交易的顺序和内容达成统一的决定。

Как только такой «строгий консенсус» установлен, блокчейн может разблокировать множество ключевых характеристик, таких как гарантия цифровых прав собственности, модель валюты, устойчивой к инфляции, и масштабируемая структура социальной координации. Но前提是，共识协议本身必须同时保证两个基本面：

• Нельзя подтверждать два конфликтующих блока одновременно;

• Сеть должна непрерывно прогрессировать, не застревая и не останавливаясь.

MonadBFT — это новейший технологический прорыв в этом направлении.

Краткий обзор эволюции протоколов консенсуса

Область механизмов консенсуса изучается уже несколько десятилетий. Самые ранние протоколы, такие как PBFT (Практическая византийская отказоустойчивость), уже могли处理一种很现实的情况：即使网络里有部分节点掉链子、作恶、胡说八道，只要它们不超过总数的 1/3，系统就还能达成一致。

Дизайн этих ранних протоколов был довольно «традиционным»: в каждом раунде выбирается лидер, который инициирует предложение, а другие валидаторы голосуют за это предложение в несколько раундов, шаг за шагом подтверждая порядок транзакций.

Весь процесс голосования обычно проходит несколько этапов, таких как pre-prepare, prepare, commit, reply. На каждом этапе все валидаторы должны общаться друг с другом. Иными словами, каждый должен сказать каждому, и объем сообщений растет взрывообразно по «сетевой» схеме.

Сложность этой коммуникационной структуры составляет n²—— то есть, если в сети 100 валидаторов, то в каждом раунде консенсуса может передаваться почти 10 000 сообщений.

В небольших сетях это не проблема, но как только количество валидаторов растет, коммуникационная нагрузка на систему быстро становится непосильной, и эффективность резко падает.

Источник:

https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

Такая вторичная коммуникационная структура «каждый должен общаться с каждым» на самом деле очень неэффективна. Например, в сети с 100 валидаторами каждый раунд консенсуса может требовать обработки десятков тысяч сообщений.

В небольшом кругу это еще терпимо, но если разместить это в глобальной, открытой сетевой среде блокчейна, нагрузка на коммуникацию сразу становится неприемлемой. Поэтому ранние протоколы BFT, такие как PBFT и Tendermint, обычно используются только в сценариях с разрешением (permissioned network) или в системах с очень небольшим количеством валидаторов, чтобы勉强跑得动。

Чтобы протоколы BFT могли адаптироваться к среде публичных блокчейнов без разрешения, некоторые новые дизайны начали переходить к более легким способам коммуникации: каждый валидатор общается только с лидером, а не со всеми подряд.

Это оптимизировало сложность сообщений с исходных n² до n —— значительно облегчив нагрузку на систему.

Протокол HotStuff был предложен именно в 2018 году для решения этой проблемы масштабируемости. Его концепция дизайна очень ясна: заменить сложный процесс голосования PBFT более простой структурой коммуникации, управляемой лидером.

Ключевой особенностью HotStuff является так называемая линейная коммуникация (linear communication). В его механизме каждый валидатор отправляет свой голос только текущему лидеру, лидер упаковывает эти голоса и генерирует Quorum Certificate (QC, сертификат кворума).

По сути, этот QC представляет собой коллективную подпись, доказывающую всей сети: «Большинство узлов согласовало это предложение».

Для сравнения, режим коммуникации PBFT — это «вещание всем», каждый говорит в группе,场面一度十分混乱。Режим HotStuff больше похож на «один собирает, один упаковывает», независимо от количества людей в сети, она может оставаться эффективной.

На рисунке выше сравнивается структура коммуникации веерной рассылки HotStuff и режим полной связности сети PBFT

Источник:

https://www.mdpi.com/1424-8220/24/16/5417

Помимо линейной коммуникации, HotStuff может быть дополнительно улучшен до конвейерной версии (pipelined HotStuff) для повышения эффективности.

В оригинальном HotStuff один и тот же валидатор последовательно выступает лидером несколько раундов, пока блок не будет полностью подтвержден. Этот процесс представляет собой «один раунд обрабатывает один блок», все усилия сосредоточены на продвижении текущего.

А в конвейерном HotStuff механизм более гибкий: в каждом раунде выбирается новый лидер, и у каждого лидера есть две задачи:

• Упаковать голоса предыдущего раунда в Quorum Certificate (QC) и транслировать их всей сети;

• Предложить новый блок,准备开启下一轮。

То есть, больше не «подтвердить один, затем обработать следующий», а как на производственной линии, разные лидеры по очереди отвечают за каждый этап. Один предлагает блок, следующий подтверждает его и продолжает предлагать новый, консенсус в цепи передается как эстафета.

Вот откуда взялась метафора «конвейер»: текущий блок все еще находится в процессе подтверждения, следующий уже готовится, много шагов параллельно, повышая пропускную способность.

Подводя итог, протоколы типа HotStuff внесли значительные улучшения по сравнению с традиционным BFT в двух аспектах:

• Во-первых, коммуникация легче, каждый валидатор общается только с лидером;

• Во-вторых, эффективность обработки выше, процессы подтверждения нескольких блоков могут выполняться параллельно.

Это сделало HotStuff шаблоном дизайна для многих современных механизмов консенсуса блокчейнов PoS. Но у всего есть плюсы и минусы —— хотя конвейерная структура мощна по производительности, она также тихо внедряет структурный риск, который нелегко обнаружить.

Далее мы подробно обсудим эту ключевую проблему: разветвление хвоста (Tail Forking).

Проблема разветвления хвоста (Tail-Forking)

Хотя HotStuff —— особенно его конвейерная версия —— решил проблему масштабируемости протокола консенсуса, он также внес некоторые новые вызовы. Самый ключевой и самый легко игнорируемый из них — это так называемая проблема «разветвления хвоста» (Tail Forking).

Что такое разветвление хвоста? Это можно просто понять как: неожиданная реорганизация блока (reorg) произошла в «хвосте» цепи.

Конкретно говоря, есть блок, который действителен, уже успешно распространен большинству валидаторов и получил достаточно голосов поддержки, по логике, он вот-вот будет подтвержден и записан в основную цепь. Но в конце концов, он был «пропущен», отвергнут (orphaned), и заменен новым блоком на той же высоте.

Это не баг и не атака, а потому что в самой структуре дизайна протокола существует такая возможность «потери хвоста». Звучит немного несправедливо? Так как же это происходит?

Как мы говорили ранее, каждый лидер в конвейерном HotStuff имеет две задачи:

• A. Предложить новый блок (например, Bₙ₊₁)

• B. Собрать голоса для блока предыдущего лидера и сгенерировать QC (например, завершить окончательное подтверждение для Bₙ)

Эти две задачи параллельны, эстафета по очереди. Но проблема именно здесь.

Например: предположим, Alice — лидер, она предложила блок Bₙ на высоте n, этот блок получил голоса супербольшинства и уже «почти подтвержден».

Далее Bob должен выступить лидером, продолжить продвижение следующего блока цепи Bₙ₊₁, и также должен упаковать QC (сертификат кворума) для Bₙ в свое предложение, завершив окончательное подтверждение Bₙ.

Но если Bob в этот момент оффлайн или намеренно не предоставит QC для Bₙ, возникает проблема.

Потому что никто не упаковал QC для блока Alice, запись голосов для Bₙ не была распространена, этот блок, который должен был быть подтвержден, был таким образом «холодно обработан» и в конечном итоге проигнорирован всей сетью.

В этом суть разветвления хвоста: блок предыдущего лидера пропускается из-за халатности или злонамеренности следующего лидера.

Почему разветвление хвоста серьезно?

Проблемы разветвления хвоста сосредоточены в двух аспектах: 1) нарушаются стимулы, 2) активность системы находится под угрозой.

Во-первых, вознаграждение поглощается:

Если блок отвергнут, лидер, предложивший его, не получит никакого вознаграждения. Ни вознаграждения за блок, ни комиссий за транзакции. Например, Alice предложила合法区块，还拿到了超级多数投票支持，结果因为 Bob 的失误或者恶意操作，这个区块没能被确认，Alice 最终一分钱也拿不到。这将会导致了错误的激励结构：像 Bob 这样的恶意节点，可以通过跳过对手的区块，来«掐断»他们的奖励来源。这种行为不需要技术攻击，只需要故意«不配合»，就能削弱竞争者的收益。如果这种事情反复发生，久而久之，会让整个系统的参与度和公平性都下降，甚至诱发节点之间的сговор.

Во-вторых, пространство для атак MEV расширяется:

Разветвление хвоста также создает более скрытую, но серьезную проблему: пространство для злонамеренного манипулирования MEV (Максимально извлекаемая стоимость) увеличивается. Например: предположим, в блоке Alice есть очень ценная арбитражная транзакция. Если Bob хочет создать проблемы, он может сговориться со следующим лидером Carol и намеренно не распространять блок Alice. Затем Carol реконструирует новый блок на той же высоте и «украдет» эту арбитражную транзакцию Alice —— превратив доход MEV в свой. Эта практика «перестановки головы цепи + сговор и присвоение»表面上还是照章出块，实则是一场精心设计的掠夺。更糟的是，它会诱导领导者们之间建立«共谋关系»，让区块确认变成一个利益分配游戏，而不是公共服务。

В-третьих, нарушается гарантия окончательности, влияет на пользовательский опыт:

По сравнению с протоколами типа Nakamoto, большим преимуществом BFT является детерминированная окончательность: как только блок提交，就无法被回滚。但尾部分叉破坏了这种保证，尤其是在那些«已获得投票但尚未正式确认»的区块上。某些高吞吐 dapp 通常希望能在区块投票通过后立刻读取数据以降低延迟，而如果该区块被突然丢弃，可能导致用户状态回滚——例如账户余额异常、刚刚完成的高杠杆交易无故消失、游戏状态突然重置等。

В-четвертых, может вызвать каскадный сбой:

Вообще говоря, разветвление хвоста может лишь задержать подтверждение某个 блока на один раунд, влияние невелико。但在一些边缘场景下，如果连续几位领导者都选择跳过上一区块，系统可能陷入停滞状态，没有人愿意«接»前一个区块。整个链的推进就此卡住，直到终于出现一个«愿意把责任扛下来»的领导者，网络才会继续前进。

Хотя ранее были некоторые решения, например, механизм избегания разветвления хвоста, предложенный протоколом BeeGees, но часто требуется жертвовать производительностью, например, повторно вводить сложность二次通信，得不偿失。

Что такое MonadBFT?

MonadBFT — это протокол консенсуса нового поколения, специально разработанный для решения проблемы разветвления хвоста。Его сила заключается в том, что решая структурные скрытые угрозы, он не жертвует преимуществами производительности, привнесенными конвейерным HotStuff。Иными словами, MonadBFT не начинает с нуля, а продолжает оптимизацию на основе核心框架 HotStuff。Оно сохраняет три ключевые характеристики：

1) Смена лидера (rotating leader): в каждом раунде выбирается новый лидер для продвижения цепи;

2) Конвейерная提交 (pipelined commits): процессы подтверждения нескольких блоков могут перекрываться;

3) Линейная коммуникация (linear messaging): каждый валидатор общается только с лидером, экономя大量网络开销。

Но только этих трех пунктов недостаточно для безопасности。Чтобы закрыть структурную уязвимость разветвления хвоста, MonadBFT добавил два ключевых механизма：

1) Механизм принудительного повторного предложения (Re-Proposal)

2) Сертификат отсутствия подтверждения (NEC, No-Endorsement Certificate)

Механизм повторного предложения (Re-Proposal)

В протоколах BFT время делится на раунды (называемые view), в каждом раунде один лидер отвечает за предложение нового блока。Если лидер выходит из строя (например, не предложил блок вовремя, или предложение недействительно), система переключится на следующий раунд и выберет нового лидера。

MonadBFT добавил механизм, гарантирующий, что в процессе переключения view любой честно предложенный блок не «отвалится» из-за смены лидера.

Когда лидер текущего раунда выходит из строя, валидаторы отправляют подписанное сообщение о смене раунда (view change), указывая, что текущий раунд истек。

Особенность в том, что это сообщение не просто означает «истекло», оно должно также содержать информацию о блоке последнего голосования этого валидатора, как бы говоря: «Я не получил легитимного предложения, это последний блок, который я вижу»。

Лидер нового раунда соберет эти сообщения о тайм-ауте от супербольшинства (2f+1) валидаторов и объединит их в Сертификат тайм-аута (Timeout Certificate, TC)。Этот TC представляет собой: единый снимок восприятия «блока головы цепи» всей сетью, когда предыдущий раунд провалился。Новый лидер выберет из них блок с самой высокой высотой (или новейшим номером view), так называемый high_tip。

MonadBFT требует: предложение нового лидера должно содержать легитимный TC и должно повторно предложить самый высокий pending блок в TC, давая этому блоку шанс быть подтвержденным снова。

Почему? Как мы упоминали ранее: мы не хотим, чтобы блок, близкий к подтверждению, просто исчез。

Например: предположим, Alice — лидер view 5, предложила действительный блок и получила голоса большинства。Далее лидер view 6 Bob оффлайн, не смог продвинуть процесс цепи。Когда Carol становится лидером view 7, согласно правилам MonadBFT, она должна включить TC и повторно предложить блок Alice。Таким образом, честный труд Alice не будет напрасным。

Если у Carol нет блока Alice, она может запросить его у других узлов。Узлы могут：

• Предоставить этот блок, или

• Вернуть подписанное «сообщение без подтверждения» (No-Endorsement, NE), указывая, что у них нет этого блока (механизм будет介绍 ниже)。（Максимум f византийских узлов могут выбрать игнорировать запрос и не отвечать。）

Как только Carol повторно предложит блок Alice, она получит дополнительную возможность предложения, гарантируя, что не будет «наказана» за провал лидера предыдущего раунда。

Роль этого механизма повторного предложения ясна: гарантировать, что продвижение цепи справедливо, и любая эффективная работа не будет тихо отвергнута из-за неудачи или чьих-то происков.

Сертификат отсутствия подтверждения (NEC)

Продолжая предыдущий пример: после тайм-аута раунда Bob, Carol запрашивает у других валидаторов блок high_tip (即 блок Alice)。В этот момент как минимум 2f+1 валидаторов ответят：

• Либо предоставят блок Alice

• Либо отправят подписанное сообщение NE, указывая, что они не получили блок Alice

Как только Carol получит блок Alice, она должна по правилам повторно предложить его。 Только если как минимум f+1 валидаторов подпишут сообщение NE , Carol может пропустить этот блок и предложить новый.

Почему f+1? В системе BFT, состоящей из 3f+1 валидаторов, максимум f могут быть злонамеренными。Если блок Alice действительно получил голоса супербольшинства, то как минимум 2f+1 честных узлов получили его。

Поэтому, если Carol утверждает «я не могу получить блок Alice», она должна предоставить подписи f+1 валидаторов, доказывающие, что все они не получили его。Это构成一个Сертификат отсутствия подтверждения (No-Endorsement Certificate, NEC)。

NEC — это凭证 лидера для «освобождения от ответственности»: это проверяемое доказательство, указывающее, что предыдущий блок еще не готов к подтверждению, и она не злонамеренно пропускает его, а «отказывается» обоснованно。

Повторное предложение + Сертификат отсутствия подтверждения = Решение проблемы разветвления хвоста

MonadBFT, внедряя механизм повторного предложения (Re-Proposal) и Сертификат отсутствия подтверждения (NEC, No-Endorsement Certificate), установил набор строгих и четких правил обработки головы цепи：

Либо завершить окончательную提交 для блока «близкого к подтверждению»;

Либо предоставить достаточные доказательства, что этот блок еще не具备 условий для подтверждения,

В противном случае не разрешается пропускать или заменять предыдущий блок。

Этот механизм гарантирует: любой блок, получивший кворум голосов, не будет отвергнут из-за ошибки лидера или намеренного уклонения.

Структурный риск разветвления хвоста системно устранен, протокол может形成 четкие ограничения на ненадлежащее поведение пропуска。

Если какой-либо лидер попытается без причины пропустить предыдущий блок, но не предоставит подтверждение NEC, протокол немедленно идентифицирует и отклонит это поведение。 Прыжок без криптографических доказательств будет считаться незаконным и не получит поддержки консенсуса сети.

С точки зрения экономических стимулов, этот дизайн обеспечивает четкую защиту для валидаторов：

• Пока блок честно предложен и получил голоса поддержки, его вознаграждение не будет лишено из-за сбоя в последующих этапах;

• Даже в экстремальных ситуациях, например, если какой-то узел намеренно пропускает свой раунд предложения, пытаясь помочь другим захватить MEV предыдущего блока, протокол также принудительно заставит последующего лидера приоритетно повторно предложить оригинальный блок, делая невозможным для атакующего получить экономическую выгоду через процесс пропуска.

Что еще важнее, MonadBFT не жертвует производительностью протокола ради повышения безопасности。

Некоторые предыдущие дизайны для应对 разветвления хвоста (например, протокол BeeGees), хотя и обладают определенной защитной способностью, но часто зависят от высокой сложности коммуникации (n²) или включения процесса повторной коммуникации в каждом раунде, что на практике значительно увеличит нагрузку на систему。

Стратегия дизайна MonadBFT более изящна：

Дополнительная коммуникация (например, сообщения о тайм-ауте, повторное предложение блоков) запускается только при сбое view или наличии аномалий。На обычном пути, где большинство честных лидеров последовательно создают блоки, протокол остается легким и эффективным。

Это динамическое平衡 между производительностью и безопасностью является одним из ключевых преимуществ MonadBFT по сравнению с протоколами предыдущего поколения。

Заключение

В этой статье回顾ены основные механизмы традиционного консенсуса PBFT,梳理了 путь развития протокола HotStuff, и重点讲解了, как MonadBFT решает эндогенную проблему разветвления хвоста в конвейерном HotStuff на уровне структуры протокола。

Разветвление хвоста искажает экономические стимулы предложителей блоков и также представляет потенциальную угрозу для активности сети。MonadBFT, внедряя механизм повторного предложения и Сертификат отсутствия подтверждения (NEC), гарантирует, что любой блок, предложенный честным лидером и получивший кворум голосов, не будет遗弃或 пропущен。

В следующей статье мы продолжим обсуждать две другие ключевые характеристики MonadBFT：

1) Предварительная окончательность (Speculative Finality)

2) Оптимистичная отзывчивость (Optimistic Responsiveness)

И进一步 проанализируем практическое значение этих механизмов для валидаторов и разработчиков。

Продолжение следует.