Анализ MonadBFT (Часть 1): Как решить проблему форка в конце цепи

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

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

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

И как только такой «строгий консенсус» установлен, блокчейн может разблокировать множество ключевых характеристик, таких как гарантия цифровой собственности, модель валюты, устойчивая к инфляции, и масштабируемая структура социального сотрудничества. Но前提 (предпосылка) в том, что сам протокол консенсуса должен одновременно гарантировать два фундаментальных аспекта:

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

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

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

Область механизмов консенсуса изучается уже несколько десятилетий. Самые ранние протоколы, такие как PBFT (Практическая византийская отказоустойчивость), уже могли справляться с очень реалистичной ситуацией: даже если часть узлов в сети выходит из строя, действует злонамеренно или говорит nonsense, пока их не более 1/3 от общего числа, система все еще может достичь согласия.

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

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

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

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

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

Это еще можно терпеть в небольшом кругу, но если разместить это в глобальной, открытой сетевой среде цепи, коммуникационная нагрузка сразу становится неприемлемой. Поэтому ранние BFT-протоколы, такие как PBFT и Tendermint, обычно используются только в сценариях с разрешением (permissioned network) или в системах с очень небольшим количеством валидаторов, чтобы хоть как-то работать.

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

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

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

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

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

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

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

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

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

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

То есть, больше не «подтвердить один, затем обработать следующий», а как на производственной линии, разные лидеры по очереди отвечают за каждый этап. Previous proposes block, next confirms it and continues proposing new block, consensus on chain passes down like a relay race.

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

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

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

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

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

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

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

Что такое Tail Forking? Можно просто понять как: блокчейн испытал неожиданную реорганизацию блоков (reorg) в «хвосте цепи».

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

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

Мы ранее говорили, что у каждого лидера в pipelined HotStuff есть две задачи:

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

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

Например: предположим, Alice — лидер, она предложила блок Bₙ на высоте n, этот блок получил голосование супер-большинства, уже «почти подтвержден». Далее должен быть Bob лидером,继续 продвигать следующий блок цепи Bₙ₊₁, и также должен упаковать QC (доказательство кворума) для Bₙ в свое предложение, завершив окончательное подтверждение Bₙ.

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

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

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

Почему Tail Forking серьезен?​

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

Во-первых, награды поглощаются: если блок отброшен, лидер, предложивший его, не получит никакой награды. Ни награды за блок, ни комиссий за транзакции. Например, Alice предложила合法 блок, еще получила поддержку голосования супер-большинства, в результате из-за ошибки Bob или злонамеренной операции, этот блок не был подтвержден, Alice в конечном итоге не получит ни копейки. Это приведет к ошибочной структуре стимулирования: злонамеренные узлы, такие как Bob, могут «отрезать» их источник награды, пропуская блоки конкурентов. Это поведение не требует технической атаки, нужно лишь намеренно «не сотрудничать», чтобы ослабить доход конкурентов. Если это происходит repeatedly, со временем это снизит участие и справедливость всей системы, даже诱发 сговор между узлами.

Во-вторых, пространство для атак MEV расширяется: Tail Forking также brings a more hidden but serious problem: пространство для злонамеренного манипулирования MEV (Maximal Extractable Value) увеличивается. Например: предположим, в блоке Alice есть крайне ценная арбитражная транзакция. Если Bob хочет создать проблемы, он может сговориться со следующим лидером Carol, намеренно не распространять блок Alice. Затем Carol реконструирует новый блок на той же высоте, «скопирует» эту арбитражную транзакцию Alice — превратив доход MEV в свой. Эта практика «реорганизации головы цепи + сговор присвоения»表面上 все еще следует правилам создания блоков, на самом деле это тщательно спланированное ограбление. Worse, it will induce leaders to establish «collusion relationships», making block confirmation a game of profit distribution, not public service.

В-третьих, разрушается гарантия финальности, влияя на пользовательский опыт: по сравнению с протоколами типа Nakamoto, большое преимущество BFT — детерминированная финальность: как только блок提交, он не может быть откатан. Но Tail Forking разрушает эту гарантию, особенно на那些 блоках «получивших голоса, но еще не официально подтвержденных». Некоторые high-throughput dapp обычно希望 could read data immediately after block voting passes to reduce latency, и если этот блок вдруг отброшен, может привести к откату состояния пользователя — например, аномалии баланса счета, только что завершенные high-leverage транзакции беспричинно исчезают, состояние игры вдруг сбрасывается и т.д.

В-четвертых, может вызвать каскадный сбой: вообще говоря, Tail Forking может только заставить какой-то блок подтвердиться на раунд позже, влияние не велико. Но в некоторых edge cases, если несколько лидеров подряд выбирают пропустить предыдущий блок, система может войти в состояние停滞, никто не хочет «принять» предыдущий блок. Продвижение всей цепи застревает здесь, пока наконец не появится лидер «готовый взять ответственность», сеть продолжит движение.

Хотя ранее были некоторые решения, например, механизм избежания Tail Forking, предложенный протоколом BeeGees, но часто требуют жертвовать производительностью, например, reintroduce quadratic communication complexity,得不偿失.

Что такое MonadBFT?​

MonadBFT — это протокол консенсуса нового поколения, специально разработанный для решения проблемы Tail Forking. Его сила в том: решая структурные скрытые опасности, не жертвуя преимуществами производительности, принесенными pipelined HotStuff. Другими словами, MonadBFT не начинает с нуля, а оптимизирует на основе核心 фреймворка HotStuff. Он сохранил три ключевые характеристики:

1. Rotation лидера (rotating leader): каждый раунд выбирается новый лидер для продвижения цепи;
2. Pipeline commits (pipelined commits): процессы подтверждения нескольких блоков могут перекрываться;
3. Linear messaging (linear messaging): каждый валидатор общается только с лидером, экономя大量 сетевых накладных расходов.

Но только этих трех точек недостаточно для безопасности. Чтобы堵住 эту структурную уязвимость Tail Forking, MonadBFT добавил два ключевых механизма:

1. Механизм принудительного повторного предложения (Re-Proposal)
2. Сертификат без одобрения (NEC, No-Endorsement Certificate)

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

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

MonadBFT добавил механизм,确保 в процессе переключения view,任何 честно предложенный блок не «отвалится» из-за rotation лидера.

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

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

Лидер нового раунда соберет эти сообщения timeout от супер-большинства (2f+1) валидаторов и объединит их в доказательство timeout (Timeout Certificate, TC). Этот TC представляет: когда предыдущий раунд failed, unified cognitive snapshot всей сети关于 «блока головы цепи». Новый лидер выберет из них блок с highest height (или latest view number), так называемый high_tip.

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

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

Например: предположим, Alice — лидер view 5, proposed valid block, и получил majority votes. Далее, лидер view 6 Bob offline, не смог продвинуть процесс цепи. Когда Carol станет лидером view 7, согласно правилам MonadBFT, она должна include TC, и повторно предложить блок Alice. Таким образом, honest labor Alice не будет wasted.

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

• Предоставить этот блок, или
• Вернуть подписанное «сообщение без одобрения» (No-Endorsement, NE), indicating они не имеют这个 блока (mechanism introduced later). (Max f Byzantine nodes may choose to ignore request, no response.)

Как только Carol повторно предложит блок Alice, она получит extra proposal opportunity, ensuring не будет «collectively punished» из-за failure предыдущего лидера.

Функция этого механизма повторного предложения ясна: ensure продвижение цепи is fair, any valid work не будет quietly discarded из-за bad luck или someone messing around.

Сертификат без одобрения (NEC)​

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

• Либо предоставят блок Alice
• Либо отправят подписанное NE сообщение, indicating они не received блок Alice

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

Почему f+1? В BFT системе consisting of 3f+1 валидаторов, max только f могут be malicious. Если блок Alice действительно получил супер-большинство votes, то至少 2f+1 honest nodes received it.

Поэтому, если Carol claims «I cannot get блок Alice», она должна produce f+1 валидаторов signatures, proving эти люди не received. Это constitutes No-Endorsement Certificate (NEC).

NEC is «exemption» credential для лидера: это verifiable evidence, indicating предыдущий блок еще не ready быть confirmed,自己 not maliciously skipping, but有理有据 «giving up».

Re-Proposal + No-Endorsement Certificate = Решение Tail Forking​

MonadBFT через введение Механизма повторного предложения (Re-Proposal) и Сертификата без одобрения (NEC, No-Endorsement Certificate), established一套 rigorous and clear rules для处理 головы цепи:

Либо complete final submission для блоков «close to being confirmed»; либо provide enough evidence, proving этот блок еще не has conditions быть confirmed, иначе, not allowed skip or replace previous block.

Этот механизм ensures: any блок, получивший legal majority votes, не будет abandoned из-за leader error или intentional avoidance. Structural risk Tail Forking systematically resolved, protocol can form clear constraints для improper skipping behavior.

Если какой-то лидер пытается无故 skip previous block, но failed provide NEC evidence, protocol will immediately identify and reject this behavior. Jumping behavior without crypto evidence will be considered illegal, не получит network consensus support.

С точки зрения economic incentives, this design provides clear protection для валидаторов:

• As long as honestly proposed and received vote support blocks, their rewards не will be deprived из-за subsequent link failure;
• Even in extreme scenarios, например, какой-то节点 intentionally skips own proposal round, trying to assist others grab previous block MEV, protocol will force successor leader priority re-propose original block, making attackers unable to get economic benefits через skipping process.

More importantly, MonadBFT не sacrificed protocol performance для повышения security.

Previously some designs для coping with Tail Forking (如 BeeGees protocol) although have certain protection ability, но often rely on high communication complexity (n²) или enable re-communication process в каждом раунде, this在实践中 will significantly increase system burden.

Design strategy MonadBFT is more ingenious:

Only when view fails или exists anomaly, start extra communication (如 timeout messages, block re-proposal). В большинстве honest leaders consecutive block generation regular path, protocol still maintains lightweight, efficient running state.

This dynamic balance между performance и security is именно one of core advantages MonadBFT compared to previous generation protocols.

Summary​

This article reviewed basic mechanisms traditional PBFT consensus, sorted out development path HotStuff protocol, and重点 explained how MonadBFT from protocol layer structure, solves pipelined HotStuff inherent Tail Forking problem.

Tail Forking will distort economic incentives block proposers, also constitutes potential threat для network liveness. MonadBFT через введение mechanism re-proposal и No-Endorsement Certificate (NEC), ensures any blocks proposed by honest leaders и received legal majority votes не will be abandoned or skipped.

In next article, we will continue explore another two core features MonadBFT:

1. Speculative Finality (Предварительная финальность)
2. Optimistic Responsiveness (Оптимистичная отзывчивость)

And further analyze practical significance these mechanisms для валидаторов и developers.

To be continued.