Суть блокчейна заключается в достижении строгого глобального консенсуса: это означает, что независимо от того, в какой стране или часовом поясе расположены узлы сети, все участники в конечном итоге должны прийти к единому объективному результату.
Но распределенная сеть в реальности не идеальна: есть узлы, которые отключаются, есть узлы, которые лгут, а некоторые даже намеренно наносят ущерб. В такой ситуации как система может «говорить в унисон» и поддерживать согласованность?
Это проблема, которую должен решить протокол консенсуса. По сути, это набор правил, предназначенных для того, чтобы направлять группу независимых, а порой и не совсем надежных узлов к единому решению по порядку и содержанию каждой транзакции.
И как только этот "строгий консенсус" будет установлен, блокчейн сможет разблокировать множество ключевых характеристик, таких как защита цифровой собственности, устойчивые к инфляции денежные модели и масштабируемые структуры социального сотрудничества. Но при этом консенсус-протокол сам должен одновременно гарантировать два основных аспекта:
Не должно быть двух конфликтующих блоков, которые подтверждаются;
Сеть должна продолжать развиваться, она не может застрять или остановиться.
MonadBFT — это последнее технологическое достижение в этом направлении.
Краткий обзор эволюции протоколов консенсуса
На самом деле, область механизма консенсуса изучается десятилетиями. Самые ранние протоколы, такие как PBFT (Practical Byzantine Fault Tolerance), были способны справиться с очень реалистичной ситуацией: даже если некоторые узлы в сети были вне цепочек, творили зло и говорили чепуху, если их количество не превышало 1/3 от общего числа, система все равно могла согласиться.
Дизайн этих ранних протоколов был довольно "традиционным": в каждом раунде выбирается один лидер, который инициирует предложение, а другие валидаторы голосуют за это предложение в несколько раундов, постепенно подтверждая порядок транзакций.
Весь процесс голосования обычно проходит через несколько этапов, таких как pre-prepare, prepare, commit, reply. На каждом этапе все валидаторы должны общаться друг с другом. Другими словами, каждый должен сказать каждому, и объем сообщений резко возрастает, принимая "сетевую" форму.
Сложность такой структуры связи составляет n² — то есть, если в сети 100 валидаторов, то в каждом раунде консенсуса может потребоваться передать почти 10 тысяч сообщений.
Это не является большой проблемой в небольшой сети, но как только количество валидаторов увеличивается, коммуникационная нагрузка на систему может быстро стать невыносимой, а эффективность напрямую снизится.
Источников:
Такая структура вторичной связи "каждый должен общаться с каждым" на самом деле очень неэффективна. Например, в сети с 100 валидаторами за один раунд консенсуса может потребоваться обработать десятки тысяч сообщений.
В небольшой группе это еще возможно, но если говорить о глобальной, открытой сетевой цепочке, то нагрузка на связь становится немедленно неприемлемой. Поэтому такие ранние BFT-протоколы, как PBFT и Tendermint, обычно используются только в разрешенных сценариях (permissioned network) или в системах с очень небольшим количеством валидаторов, чтобы их можно было хоть как-то запустить.
Чтобы BFT-протокол также мог адаптироваться к среде публичных цепей без разрешений, некоторые новые поколения дизайна начали переходить к более легким способам связи: позволить каждому валидатору общаться только с лидером, а не со всеми.
Это уменьшает сложность сообщений с изначальных n² до n — значительно снижая нагрузку на систему.
Протокол HotStuff был предложен в 2018 году именно для решения проблемы масштабируемости. Его концепция очень ясна: заменить сложный процесс голосования PBFT на более простую, основанную на лидерах, структуру коммуникации.
Ключевая особенность HotStuff — это так называемая линейная связь (linear communication). В его механизме каждый валидатор должен отправить свой голос только текущему лидеру, который затем упаковывает эти голоса и генерирует сертификат кворума (Quorum Certificate, QC).
Этот QC по сути является коллективной подписью, подтверждающей всей сети: "Большинство узлов согласны с этим предложением."
В отличие от этого, коммуникационная модель PBFT представляет собой «всеобщее вещание», где каждый говорит в группе, что иногда приводит к хаосу. Модель HotStuff более похожа на «один собирает, один пакует», и, независимо от количества людей в сети, она по-прежнему может поддерживать высокую эффективность.
На рисунке сравнивается разветвленная структура коммуникации HotStuff с моделью полной сетевой взаимосвязи PBFT.
Источник информации:
Помимо линейной связи, HotStuff также может быть дополнительно обновлен до версионной обработки (параллельный HotStuff), чтобы повысить эффективность.
В оригинальном HotStuff один и тот же валидатор будет непрерывно выполнять роль лидера в нескольких раундах, пока блок не будет полностью подтвержден. Этот процесс заключается в «обработке одного блока за раунд», вся энергия сосредоточена на продвижении именно этого блока.
В пайплайне HotStuff механика гораздо более гибкая: в каждом раунде выбирается новый лидер, и у каждого лидера есть две задачи:
Одновременно упаковывая голосование предыдущего раунда в Кворумный сертификат (QC) и транслируя его по всей сети;
Представляя новый блок, готовясь начать следующий раунд.
Другими словами, это уже не «подтвердить одно, а затем обработать следующее», но, как и на производственной линии, разные руководители по очереди отвечают за каждое звено. Предыдущий бит предлагает блок, следующий подтверждает его и переходит к предложению нового блока, и ончейн-консенсус передается по наследству, как эстафета.
Вот откуда происходит метафора "конвейер": текущий блок все еще проходит процесс подтверждения, а следующий уже готовится, что позволяет выполнять несколько этапов параллельно и повышать пропускную способность.
В заключение, протоколы типа HotStuff значительно улучшили два аспекта по сравнению с традиционными BFT:
Во-первых, связь становится легче, каждый валидатор должен общаться только с лидером;
Во-вторых, эффективность обработки выше, несколько процессов подтверждения блоков могут выполняться параллельно.
Это сделало HotStuff шаблоном для разработки многих современных механизмов консенсуса PoS блокчейна. Но как и в любом деле, есть свои плюсы и минусы — хотя конвейерная структура обладает высокой производительностью, она также тихо вводит структурный риск, который не так легко обнаружить.
Теперь давайте углубимся в этот ключевой вопрос: хвостовое разветвление (Tail Forking).
Проблема раздвоения в конце (Tail-Forking)
Хотя HotStuff — особенно его версия с конвейерной архитектурой — решает проблему масштабируемости консенсусных протоколов, она также вводит некоторые новые вызовы. Среди них самая критическая и легко игнорируемая проблема — это так называемая проблема "Хвостового разделения" (Tail Forking).
Что такое конечная ветвь? Это можно просто понять как: неожиданная переорганизация блока произошла в "конце цепи" блокчейна (reorg).
Конкретно, есть блок, который является действительным, и он уже успешно распространился среди большинства валидаторов, а также получил достаточно голосов поддержки. По логике, он должен быть немедленно подтвержден и записан в основную цепочку. Но в итоге он был "пропущен", был отброшен (orphaned), и вместо него появился другой новый блок на той же высоте.
Это не ошибка и не атака, а потому что в самой структуре дизайна протокола существует возможность такого "обрыва цепочки". Разве это не звучит немного несправедливо? Так как же это происходит?
Мы уже говорили, что у каждого лидера в поточной линии HotStuff есть две задачи:
A. Предложите новый блок (например, Bₙ₊₁)
B. Сбор голосов за блок предыдущего лидера, создание QC (например, для завершения окончательного подтверждения Bₙ)
Эти две задачи выполняются параллельно, поочередно. Но проблема заключается в этом.
Возьмем пример: предположим, что Алиса является лидером, и она на высоте n предложила блок Bₙ, который получил супербольшинство голосов и уже "почти подтвержден".
Следующим лидером должен стать Боб, который продолжит продвигать следующий блок цепи Bₙ₊₁, а также должен упаковать QC (доказательство законного большинства) блока Bₙ в свое предложение, чтобы завершить окончательное подтверждение Bₙ.
Но если Боб в это время оффлайн или намеренно не подаст QC для Bₙ, то возникнут проблемы.
Поскольку никто не завершил QC упаковку блока Alice, запись голосования Bₙ не смогла распространиться, и этот блок, который должен был быть подтвержден, оказался «замороженным» и в конечном итоге был проигнорирован всей сетью.
Вот в чем суть разветвления на конце: блок предыдущего лидера пропускается из-за бездействия или злого умысла следующего лидера.
Почему хвостовое расщепление серьезно?
Проблема разветвления в конце сосредоточена на двух аспектах: 1) разрушение механизма стимулов, 2) угроза активности системы.
Во-первых, награда была поглощена:
Если блок будет отвергнут, его инициатор не получит никакого вознаграждения. Ни вознаграждения за создание блока, ни комиссий за транзакции. Например, если Элис предложила законный блок и получила поддержку супербольшинства голосов, но из-за ошибки или злонамеренных действий Боба этот блок не был подтвержден, Элис в конечном итоге не получит ни копейки. Это приведет к неправильной структуре стимулов: злонамеренные узлы, такие как Боб, могут "обрезать" источник вознаграждения своих соперников, пропуская их блоки. Для этого не требуется технической атаки, достаточно намеренно "не сотрудничать", чтобы ослабить доходы конкурента. Если такие события будут повторяться, со временем это приведет к снижению вовлеченности и справедливости всей системы, даже может спровоцировать сговор между узлами.
Во-вторых, пространство для атак MEV расширяется:
Конце ветвления также возникает более скрытая, но серьезная проблема: пространство для злонамеренного манипулирования MEV (максимально извлекаемая ценность) увеличивается. Пример: предположим, что в блоке Алисы есть очень ценная арбитражная сделка. Если у Боба есть намерение что-то испортить, он может сговориться с следующим лидером Каролом и намеренно не распространить блок Алисы. Затем Карол может воссоздать новый блок на той же высоте, "скопировав" арбитражную сделку Алисы — превратив доход от MEV в свой собственный. Такая практика "перестановки цепочки + сговора" на первый взгляд все еще соответствует правилам создания блоков, но на самом деле это тщательно спланированное ограбление. Еще хуже то, что это может побудить лидеров установить "сговорные отношения", превратив подтверждение блоков в игру распределения利益, а не в общественную службу.
Третье, разрушение гарантии окончательности, влияющее на пользовательский опыт:
Одним из больших преимуществ BFT по сравнению с протоколами, подобными протоколам Накамото, является детерминированная завершенность: после того, как блок был зафиксирован, его нельзя откатить. Но хвостовые форки подрывают эту гарантию, особенно на блоках, которые «были проголосованы, но не подтверждены официально». Некоторые децентрализованные приложения с высокой пропускной способностью обычно хотят иметь возможность считывать данные сразу после голосования за блок, чтобы уменьшить задержку, и если блок внезапно отбрасывается, это может привести к откату состояния пользователя - например, аномальный баланс счета, только что завершенная транзакция с высоким кредитным плечом исчезает без причины, внезапный сброс состояния игры и т. д.
Четвертое, может вызвать цепную реакцию неисправностей:
В общем, разветвление на конце может привести к тому, что определенный блок будет подтвержден только с задержкой на один раунд, влияние незначительное. Однако в некоторых пограничных сценариях, если несколько подряд лидеров решат пропустить предыдущий блок, система может оказаться в состоянии стагнации, никто не захочет «взять на себя» предыдущий блок. Вся цепь будет заблокирована, пока не появится «лидер, который готов взять на себя ответственность», и сеть не сможет продолжить движение.
Хотя ранее существовали некоторые решения, такие как механизм избежания хвостового разветвления, предложенный протоколом BeeGees, они часто требуют жертвовать производительностью, например, повторно вводя сложность вторичной связи, что не оправдывает затраты.
Что такое MonadBFT?
MonadBFT - это новое поколение консенсусного протокола, специально разработанное для решения проблемы конечного разветвления. Его сила заключается в том, что при решении структурных рисков не была жертвуема производительность, обеспечиваемая конвейерным HotStuff. Иными словами, MonadBFT не является полным пересмотром, а продолжает оптимизацию на основе ядра HotStuff. Он сохраняет три ключевых характеристики:
Ротация лидера (rotating leader): каждый раунд выбирается новый лидер для продвижения цепочки;
Пайплайновые коммиты (pipelined commits): процесс подтверждения нескольких блоков может выполняться параллельно;
Линейная связь (linear messaging): каждому валидатору нужно общаться только с лидером, что экономит значительные сетевые ресурсы.
Но полагаться только на эти три пункта недостаточно для обеспечения безопасности. Чтобы устранить структурную уязвимость, связанную с концом ответвления, MonadBFT добавил две ключевые механизмы:
Механизм принудительного повторного предложения (Re-Proposal)
В BFT-протоколе время делится на раунды (называемые view), в каждом из которых один лидер отвечает за предложение нового блока. Если лидер терпит неудачу (например, не предлагает блок вовремя или предложение недействительно), система переходит к следующему раунду и выбирает нового лидера.
MonadBFT добавила механизм, который гарантирует, что в процессе переключения представлений никакие честно предложенные блоки не будут "потеряны" из-за смены лидера.
Когда текущий лидер раунда выходит из строя, валидаторы отправляют подписанное сообщение о смене раунда (view change), указывая, что текущий раунд истек.
Особенно важно, что это сообщение не только указывает на «время ожидания», но и должно содержать информацию о блоке последнего голосования этого валидатора, что эквивалентно следующему: «Я не получил законное предложение, это последний блок, который я сейчас вижу.»
Новый раунд лидеров будет собирать эти сообщения о тайм-ауте от валидаторов супербольшинства (2f+1) и объединять их в сертификат тайм-аута (TC). Этот TC представляет собой единый когнитивный снимок «блока главы цепочки» по всей сети, когда предыдущий раунд не удался. Новый лидер выбирает блок с наибольшей высотой (или последним номером просмотра), так называемый high_tip.
Требования MonadBFT: предложение нового лидера должно содержать легитимный TC, и необходимо повторно предложить самый высокий приостановленный блок в TC, чтобы этот блок снова получил шанс на подтверждение.
Почему? Как мы упоминали ранее: мы не хотим, чтобы почти подтвержденный блок просто исчез.
Например: предположим, что Алиса является лидером view 5, предложила действительный блок и получила большинство голосов. Затем лидер view 6 Боб вышел из сети и не смог продвинуть процесс цепочки. Когда Каролина станет лидером view 7, согласно правилам MonadBFT, она должна включить TC и повторно предложить блок Алисы. Таким образом, честный труд Алисы не будет напрасным.
Если у Кэрол нет блока Элис, она может запросить его у других узлов. Узлы могут:
Предоставьте этот блок, или
Вернуть подписанное "сообщение без одобрения" (No-Endorsement, NE), указывающее на то, что у вас нет этого блока (механизм будет описан далее). (Не более f византийских узлов могут выбрать игнорировать запрос и не отвечать.)
Как только Кэрол повторно предложит блок Алисы, она получит дополнительную возможность предложить, чтобы ее не «подвели» из-за неудачи предыдущего лидера.
Эта механика повторного предложения имеет четкую цель: обеспечить справедливое продвижение цепочки, чтобы никакая эффективная работа не была тихо отброшена из-за неудачи или вмешательства кого-либо.
Безрецептурный сертификат (NEC)
Продолжая предыдущий пример: после тайм-аута раунда Боба, Кэрол запрашивает у других валидаторов блок high_tip (то есть блок Алис). В это время как минимум 2f+1 валидаторов отреагируют:
Предоставьте блок Alice
Отправьте подписанное сообщение NE, чтобы указать, что вы не получили блок Alice.
Как только Кэрол получит блок от Элис, она должна пере proposer его в соответствии с правилами. Кэрол может пропустить этот блок и предложить новый только в том случае, если по крайней мере f+1 валидаторов подпишут сообщение NE.
Почему f+1? В BFT-системе, состоящей из 3f+1 валидаторов, может быть максимум f злонамеренных. Если блок Алисы действительно получил супербольшинство голосов, то как минимум 2f+1 честных узла его получили.
Таким образом, если Кэрол утверждает, что «я не могу получить блок Алис», то она должна представить подписи f+1 валидаторов, чтобы доказать, что эти люди ничего не получили. Это и будет сертификат без одобрения (No-Endorsement Certificate, NEC).
NEC является лидирующим сертификатом "отказа от ответственности": это проверяемое доказательство того, что предыдущий блок еще не готов к подтверждению, и он не был злонамеренно пропущен, а был обоснованно "отказан".
Повторное предложение + отсутствие сертификата о поддержке = решение проблемы с окончательным ответвлением
MonadBFT вводит механизм повторного предложения (Re-Proposal) и сертификат без одобрения (NEC, No-Endorsement Certificate), устанавливая строгие и четкие правила обработки цепочки.
Либо завершить окончательную подачу для блока, "близкого к подтверждению";
либо предоставить достаточные доказательства того, что этот блок еще не соответствует условиям для подтверждения,
В противном случае не допускается пропускать или заменять предыдущий блок.
Этот механизм обеспечивает: любой блок, получивший законное большинство голосов, не будет отвергнут из-за ошибки лидера или намеренного уклонения.
Структурные риски, связанные с конечными разветвлениями, систематически разрешаются, а протокол способен накладывать четкие ограничения на ненадлежащее поведение.
Если какой-либо лидер попытается без причины пропустить предыдущий блок, но не сможет предоставить доказательства NEC, протокол немедленно распознает и отвергнет это действие. Пропуск без криптографических доказательств будет считаться незаконным и не получит поддержки сетевого консенсуса.
С точки зрения экономических стимулов, этот дизайн предоставляет четкую защиту для валидаторов:
Только честно предложенные блоки, получившие поддержку голосования, не будут лишены вознаграждения из-за сбоев на последующих этапах;
Даже в экстремальных ситуациях, например, если какой-то узел намеренно пропускает свой раунд предложений, пытаясь помочь другим захватить MEV предыдущего блока, протокол также будет принуждать последующих лидеров приоритизировать повторное предложение оригинального блока, что не позволит злоумышленникам получить экономическую выгоду, пропуская процесс.
Более того, MonadBFT не жертвует производительностью протокола ради повышения безопасности.
Ранее некоторые решения для обработки разделений цепи (например, протокол BeeGees) имели определенные защитные способности, но часто зависели от высокой сложности связи (n²) или активации повторных коммуникационных процессов на каждом раунде, что на практике значительно увеличивало нагрузку на систему.
Стратегия проектирования MonadBFT более изящна:
Дополнительная связь (например, сообщения о тайм-ауте, повторные предложения блоков) запускается только в случае неудачи представления или наличия аномалий. В большинстве случаев протокол по-прежнему поддерживает легкое и эффективное состояние работы на обычном пути последовательного создания блоков честными лидерами.
Этот динамический баланс между производительностью и безопасностью является одним из ключевых преимуществ MonadBFT по сравнению с предыдущими протоколами.
Резюме
В этой статье рассматриваются основные механизмы традиционного консенсуса PBFT, прослеживается путь развития протокола HotStuff, а также подробно объясняется, как MonadBFT решает проблему хвостового разветвления, присущую конвейерному HotStuff, на уровне структуры протокола.
Конечные разветвления могут искажать экономические стимулы предложителей блоков и представлять потенциальную угрозу для активности сети. MonadBFT вводит механизм повторного предложения и сертификаты без одобрения (NEC), чтобы гарантировать, что любой блок, предложенный честным лидером и получивший законное большинство голосов, не будет заброшен или пропущен.
В следующей статье мы продолжим обсуждать две другие ключевые характеристики MonadBFT:
и далее проанализировать реальное значение этих механизмов для валидаторов и разработчиков.
Продолжение следует.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
MonadBFT: Переопределение безопасности согласования Блокчейн, прощание с риском хвостового форка
Автор: michaellwy
Суть блокчейна заключается в достижении строгого глобального консенсуса: это означает, что независимо от того, в какой стране или часовом поясе расположены узлы сети, все участники в конечном итоге должны прийти к единому объективному результату.
Но распределенная сеть в реальности не идеальна: есть узлы, которые отключаются, есть узлы, которые лгут, а некоторые даже намеренно наносят ущерб. В такой ситуации как система может «говорить в унисон» и поддерживать согласованность?
Это проблема, которую должен решить протокол консенсуса. По сути, это набор правил, предназначенных для того, чтобы направлять группу независимых, а порой и не совсем надежных узлов к единому решению по порядку и содержанию каждой транзакции.
И как только этот "строгий консенсус" будет установлен, блокчейн сможет разблокировать множество ключевых характеристик, таких как защита цифровой собственности, устойчивые к инфляции денежные модели и масштабируемые структуры социального сотрудничества. Но при этом консенсус-протокол сам должен одновременно гарантировать два основных аспекта:
Не должно быть двух конфликтующих блоков, которые подтверждаются;
Сеть должна продолжать развиваться, она не может застрять или остановиться.
MonadBFT — это последнее технологическое достижение в этом направлении.
Краткий обзор эволюции протоколов консенсуса
На самом деле, область механизма консенсуса изучается десятилетиями. Самые ранние протоколы, такие как PBFT (Practical Byzantine Fault Tolerance), были способны справиться с очень реалистичной ситуацией: даже если некоторые узлы в сети были вне цепочек, творили зло и говорили чепуху, если их количество не превышало 1/3 от общего числа, система все равно могла согласиться.
Дизайн этих ранних протоколов был довольно "традиционным": в каждом раунде выбирается один лидер, который инициирует предложение, а другие валидаторы голосуют за это предложение в несколько раундов, постепенно подтверждая порядок транзакций.
Весь процесс голосования обычно проходит через несколько этапов, таких как pre-prepare, prepare, commit, reply. На каждом этапе все валидаторы должны общаться друг с другом. Другими словами, каждый должен сказать каждому, и объем сообщений резко возрастает, принимая "сетевую" форму.
Сложность такой структуры связи составляет n² — то есть, если в сети 100 валидаторов, то в каждом раунде консенсуса может потребоваться передать почти 10 тысяч сообщений.
Это не является большой проблемой в небольшой сети, но как только количество валидаторов увеличивается, коммуникационная нагрузка на систему может быстро стать невыносимой, а эффективность напрямую снизится.
Источников:
Такая структура вторичной связи "каждый должен общаться с каждым" на самом деле очень неэффективна. Например, в сети с 100 валидаторами за один раунд консенсуса может потребоваться обработать десятки тысяч сообщений.
В небольшой группе это еще возможно, но если говорить о глобальной, открытой сетевой цепочке, то нагрузка на связь становится немедленно неприемлемой. Поэтому такие ранние BFT-протоколы, как PBFT и Tendermint, обычно используются только в разрешенных сценариях (permissioned network) или в системах с очень небольшим количеством валидаторов, чтобы их можно было хоть как-то запустить.
Чтобы BFT-протокол также мог адаптироваться к среде публичных цепей без разрешений, некоторые новые поколения дизайна начали переходить к более легким способам связи: позволить каждому валидатору общаться только с лидером, а не со всеми.
Это уменьшает сложность сообщений с изначальных n² до n — значительно снижая нагрузку на систему.
Протокол HotStuff был предложен в 2018 году именно для решения проблемы масштабируемости. Его концепция очень ясна: заменить сложный процесс голосования PBFT на более простую, основанную на лидерах, структуру коммуникации.
Ключевая особенность HotStuff — это так называемая линейная связь (linear communication). В его механизме каждый валидатор должен отправить свой голос только текущему лидеру, который затем упаковывает эти голоса и генерирует сертификат кворума (Quorum Certificate, QC).
Этот QC по сути является коллективной подписью, подтверждающей всей сети: "Большинство узлов согласны с этим предложением."
В отличие от этого, коммуникационная модель PBFT представляет собой «всеобщее вещание», где каждый говорит в группе, что иногда приводит к хаосу. Модель HotStuff более похожа на «один собирает, один пакует», и, независимо от количества людей в сети, она по-прежнему может поддерживать высокую эффективность.
На рисунке сравнивается разветвленная структура коммуникации HotStuff с моделью полной сетевой взаимосвязи PBFT.
Источник информации:
Помимо линейной связи, HotStuff также может быть дополнительно обновлен до версионной обработки (параллельный HotStuff), чтобы повысить эффективность.
В оригинальном HotStuff один и тот же валидатор будет непрерывно выполнять роль лидера в нескольких раундах, пока блок не будет полностью подтвержден. Этот процесс заключается в «обработке одного блока за раунд», вся энергия сосредоточена на продвижении именно этого блока.
В пайплайне HotStuff механика гораздо более гибкая: в каждом раунде выбирается новый лидер, и у каждого лидера есть две задачи:
Одновременно упаковывая голосование предыдущего раунда в Кворумный сертификат (QC) и транслируя его по всей сети;
Представляя новый блок, готовясь начать следующий раунд.
Другими словами, это уже не «подтвердить одно, а затем обработать следующее», но, как и на производственной линии, разные руководители по очереди отвечают за каждое звено. Предыдущий бит предлагает блок, следующий подтверждает его и переходит к предложению нового блока, и ончейн-консенсус передается по наследству, как эстафета.
Вот откуда происходит метафора "конвейер": текущий блок все еще проходит процесс подтверждения, а следующий уже готовится, что позволяет выполнять несколько этапов параллельно и повышать пропускную способность.
В заключение, протоколы типа HotStuff значительно улучшили два аспекта по сравнению с традиционными BFT:
Во-первых, связь становится легче, каждый валидатор должен общаться только с лидером;
Во-вторых, эффективность обработки выше, несколько процессов подтверждения блоков могут выполняться параллельно.
Это сделало HotStuff шаблоном для разработки многих современных механизмов консенсуса PoS блокчейна. Но как и в любом деле, есть свои плюсы и минусы — хотя конвейерная структура обладает высокой производительностью, она также тихо вводит структурный риск, который не так легко обнаружить.
Теперь давайте углубимся в этот ключевой вопрос: хвостовое разветвление (Tail Forking).
Проблема раздвоения в конце (Tail-Forking)
Хотя HotStuff — особенно его версия с конвейерной архитектурой — решает проблему масштабируемости консенсусных протоколов, она также вводит некоторые новые вызовы. Среди них самая критическая и легко игнорируемая проблема — это так называемая проблема "Хвостового разделения" (Tail Forking).
Что такое конечная ветвь? Это можно просто понять как: неожиданная переорганизация блока произошла в "конце цепи" блокчейна (reorg).
Конкретно, есть блок, который является действительным, и он уже успешно распространился среди большинства валидаторов, а также получил достаточно голосов поддержки. По логике, он должен быть немедленно подтвержден и записан в основную цепочку. Но в итоге он был "пропущен", был отброшен (orphaned), и вместо него появился другой новый блок на той же высоте.
Это не ошибка и не атака, а потому что в самой структуре дизайна протокола существует возможность такого "обрыва цепочки". Разве это не звучит немного несправедливо? Так как же это происходит?
Мы уже говорили, что у каждого лидера в поточной линии HotStuff есть две задачи:
A. Предложите новый блок (например, Bₙ₊₁)
B. Сбор голосов за блок предыдущего лидера, создание QC (например, для завершения окончательного подтверждения Bₙ)
Эти две задачи выполняются параллельно, поочередно. Но проблема заключается в этом.
Возьмем пример: предположим, что Алиса является лидером, и она на высоте n предложила блок Bₙ, который получил супербольшинство голосов и уже "почти подтвержден".
Следующим лидером должен стать Боб, который продолжит продвигать следующий блок цепи Bₙ₊₁, а также должен упаковать QC (доказательство законного большинства) блока Bₙ в свое предложение, чтобы завершить окончательное подтверждение Bₙ.
Но если Боб в это время оффлайн или намеренно не подаст QC для Bₙ, то возникнут проблемы.
Поскольку никто не завершил QC упаковку блока Alice, запись голосования Bₙ не смогла распространиться, и этот блок, который должен был быть подтвержден, оказался «замороженным» и в конечном итоге был проигнорирован всей сетью.
Вот в чем суть разветвления на конце: блок предыдущего лидера пропускается из-за бездействия или злого умысла следующего лидера.
Почему хвостовое расщепление серьезно?
Проблема разветвления в конце сосредоточена на двух аспектах: 1) разрушение механизма стимулов, 2) угроза активности системы.
Во-первых, награда была поглощена:
Если блок будет отвергнут, его инициатор не получит никакого вознаграждения. Ни вознаграждения за создание блока, ни комиссий за транзакции. Например, если Элис предложила законный блок и получила поддержку супербольшинства голосов, но из-за ошибки или злонамеренных действий Боба этот блок не был подтвержден, Элис в конечном итоге не получит ни копейки. Это приведет к неправильной структуре стимулов: злонамеренные узлы, такие как Боб, могут "обрезать" источник вознаграждения своих соперников, пропуская их блоки. Для этого не требуется технической атаки, достаточно намеренно "не сотрудничать", чтобы ослабить доходы конкурента. Если такие события будут повторяться, со временем это приведет к снижению вовлеченности и справедливости всей системы, даже может спровоцировать сговор между узлами.
Во-вторых, пространство для атак MEV расширяется:
Конце ветвления также возникает более скрытая, но серьезная проблема: пространство для злонамеренного манипулирования MEV (максимально извлекаемая ценность) увеличивается. Пример: предположим, что в блоке Алисы есть очень ценная арбитражная сделка. Если у Боба есть намерение что-то испортить, он может сговориться с следующим лидером Каролом и намеренно не распространить блок Алисы. Затем Карол может воссоздать новый блок на той же высоте, "скопировав" арбитражную сделку Алисы — превратив доход от MEV в свой собственный. Такая практика "перестановки цепочки + сговора" на первый взгляд все еще соответствует правилам создания блоков, но на самом деле это тщательно спланированное ограбление. Еще хуже то, что это может побудить лидеров установить "сговорные отношения", превратив подтверждение блоков в игру распределения利益, а не в общественную службу.
Третье, разрушение гарантии окончательности, влияющее на пользовательский опыт:
Одним из больших преимуществ BFT по сравнению с протоколами, подобными протоколам Накамото, является детерминированная завершенность: после того, как блок был зафиксирован, его нельзя откатить. Но хвостовые форки подрывают эту гарантию, особенно на блоках, которые «были проголосованы, но не подтверждены официально». Некоторые децентрализованные приложения с высокой пропускной способностью обычно хотят иметь возможность считывать данные сразу после голосования за блок, чтобы уменьшить задержку, и если блок внезапно отбрасывается, это может привести к откату состояния пользователя - например, аномальный баланс счета, только что завершенная транзакция с высоким кредитным плечом исчезает без причины, внезапный сброс состояния игры и т. д.
Четвертое, может вызвать цепную реакцию неисправностей:
В общем, разветвление на конце может привести к тому, что определенный блок будет подтвержден только с задержкой на один раунд, влияние незначительное. Однако в некоторых пограничных сценариях, если несколько подряд лидеров решат пропустить предыдущий блок, система может оказаться в состоянии стагнации, никто не захочет «взять на себя» предыдущий блок. Вся цепь будет заблокирована, пока не появится «лидер, который готов взять на себя ответственность», и сеть не сможет продолжить движение.
Хотя ранее существовали некоторые решения, такие как механизм избежания хвостового разветвления, предложенный протоколом BeeGees, они часто требуют жертвовать производительностью, например, повторно вводя сложность вторичной связи, что не оправдывает затраты.
Что такое MonadBFT?
MonadBFT - это новое поколение консенсусного протокола, специально разработанное для решения проблемы конечного разветвления. Его сила заключается в том, что при решении структурных рисков не была жертвуема производительность, обеспечиваемая конвейерным HotStuff. Иными словами, MonadBFT не является полным пересмотром, а продолжает оптимизацию на основе ядра HotStuff. Он сохраняет три ключевых характеристики:
Ротация лидера (rotating leader): каждый раунд выбирается новый лидер для продвижения цепочки;
Пайплайновые коммиты (pipelined commits): процесс подтверждения нескольких блоков может выполняться параллельно;
Линейная связь (linear messaging): каждому валидатору нужно общаться только с лидером, что экономит значительные сетевые ресурсы.
Но полагаться только на эти три пункта недостаточно для обеспечения безопасности. Чтобы устранить структурную уязвимость, связанную с концом ответвления, MonadBFT добавил две ключевые механизмы:
Механизм принудительного повторного предложения (Re-Proposal)
Безудостоверенный сертификат (NEC, No-Endorsement Certificate)
Механизм повторного предложения (Re-Proposal)
В BFT-протоколе время делится на раунды (называемые view), в каждом из которых один лидер отвечает за предложение нового блока. Если лидер терпит неудачу (например, не предлагает блок вовремя или предложение недействительно), система переходит к следующему раунду и выбирает нового лидера.
MonadBFT добавила механизм, который гарантирует, что в процессе переключения представлений никакие честно предложенные блоки не будут "потеряны" из-за смены лидера.
Когда текущий лидер раунда выходит из строя, валидаторы отправляют подписанное сообщение о смене раунда (view change), указывая, что текущий раунд истек.
Особенно важно, что это сообщение не только указывает на «время ожидания», но и должно содержать информацию о блоке последнего голосования этого валидатора, что эквивалентно следующему: «Я не получил законное предложение, это последний блок, который я сейчас вижу.»
Новый раунд лидеров будет собирать эти сообщения о тайм-ауте от валидаторов супербольшинства (2f+1) и объединять их в сертификат тайм-аута (TC). Этот TC представляет собой единый когнитивный снимок «блока главы цепочки» по всей сети, когда предыдущий раунд не удался. Новый лидер выбирает блок с наибольшей высотой (или последним номером просмотра), так называемый high_tip.
Требования MonadBFT: предложение нового лидера должно содержать легитимный TC, и необходимо повторно предложить самый высокий приостановленный блок в TC, чтобы этот блок снова получил шанс на подтверждение.
Почему? Как мы упоминали ранее: мы не хотим, чтобы почти подтвержденный блок просто исчез.
Например: предположим, что Алиса является лидером view 5, предложила действительный блок и получила большинство голосов. Затем лидер view 6 Боб вышел из сети и не смог продвинуть процесс цепочки. Когда Каролина станет лидером view 7, согласно правилам MonadBFT, она должна включить TC и повторно предложить блок Алисы. Таким образом, честный труд Алисы не будет напрасным.
Если у Кэрол нет блока Элис, она может запросить его у других узлов. Узлы могут:
Предоставьте этот блок, или
Вернуть подписанное "сообщение без одобрения" (No-Endorsement, NE), указывающее на то, что у вас нет этого блока (механизм будет описан далее). (Не более f византийских узлов могут выбрать игнорировать запрос и не отвечать.)
Как только Кэрол повторно предложит блок Алисы, она получит дополнительную возможность предложить, чтобы ее не «подвели» из-за неудачи предыдущего лидера.
Эта механика повторного предложения имеет четкую цель: обеспечить справедливое продвижение цепочки, чтобы никакая эффективная работа не была тихо отброшена из-за неудачи или вмешательства кого-либо.
Безрецептурный сертификат (NEC)
Продолжая предыдущий пример: после тайм-аута раунда Боба, Кэрол запрашивает у других валидаторов блок high_tip (то есть блок Алис). В это время как минимум 2f+1 валидаторов отреагируют:
Предоставьте блок Alice
Отправьте подписанное сообщение NE, чтобы указать, что вы не получили блок Alice.
Как только Кэрол получит блок от Элис, она должна пере proposer его в соответствии с правилами. Кэрол может пропустить этот блок и предложить новый только в том случае, если по крайней мере f+1 валидаторов подпишут сообщение NE.
Почему f+1? В BFT-системе, состоящей из 3f+1 валидаторов, может быть максимум f злонамеренных. Если блок Алисы действительно получил супербольшинство голосов, то как минимум 2f+1 честных узла его получили.
Таким образом, если Кэрол утверждает, что «я не могу получить блок Алис», то она должна представить подписи f+1 валидаторов, чтобы доказать, что эти люди ничего не получили. Это и будет сертификат без одобрения (No-Endorsement Certificate, NEC).
NEC является лидирующим сертификатом "отказа от ответственности": это проверяемое доказательство того, что предыдущий блок еще не готов к подтверждению, и он не был злонамеренно пропущен, а был обоснованно "отказан".
Повторное предложение + отсутствие сертификата о поддержке = решение проблемы с окончательным ответвлением
MonadBFT вводит механизм повторного предложения (Re-Proposal) и сертификат без одобрения (NEC, No-Endorsement Certificate), устанавливая строгие и четкие правила обработки цепочки.
Либо завершить окончательную подачу для блока, "близкого к подтверждению";
либо предоставить достаточные доказательства того, что этот блок еще не соответствует условиям для подтверждения,
В противном случае не допускается пропускать или заменять предыдущий блок.
Этот механизм обеспечивает: любой блок, получивший законное большинство голосов, не будет отвергнут из-за ошибки лидера или намеренного уклонения.
Структурные риски, связанные с конечными разветвлениями, систематически разрешаются, а протокол способен накладывать четкие ограничения на ненадлежащее поведение.
Если какой-либо лидер попытается без причины пропустить предыдущий блок, но не сможет предоставить доказательства NEC, протокол немедленно распознает и отвергнет это действие. Пропуск без криптографических доказательств будет считаться незаконным и не получит поддержки сетевого консенсуса.
С точки зрения экономических стимулов, этот дизайн предоставляет четкую защиту для валидаторов:
Только честно предложенные блоки, получившие поддержку голосования, не будут лишены вознаграждения из-за сбоев на последующих этапах;
Даже в экстремальных ситуациях, например, если какой-то узел намеренно пропускает свой раунд предложений, пытаясь помочь другим захватить MEV предыдущего блока, протокол также будет принуждать последующих лидеров приоритизировать повторное предложение оригинального блока, что не позволит злоумышленникам получить экономическую выгоду, пропуская процесс.
Более того, MonadBFT не жертвует производительностью протокола ради повышения безопасности.
Ранее некоторые решения для обработки разделений цепи (например, протокол BeeGees) имели определенные защитные способности, но часто зависели от высокой сложности связи (n²) или активации повторных коммуникационных процессов на каждом раунде, что на практике значительно увеличивало нагрузку на систему.
Стратегия проектирования MonadBFT более изящна:
Дополнительная связь (например, сообщения о тайм-ауте, повторные предложения блоков) запускается только в случае неудачи представления или наличия аномалий. В большинстве случаев протокол по-прежнему поддерживает легкое и эффективное состояние работы на обычном пути последовательного создания блоков честными лидерами.
Этот динамический баланс между производительностью и безопасностью является одним из ключевых преимуществ MonadBFT по сравнению с предыдущими протоколами.
Резюме
В этой статье рассматриваются основные механизмы традиционного консенсуса PBFT, прослеживается путь развития протокола HotStuff, а также подробно объясняется, как MonadBFT решает проблему хвостового разветвления, присущую конвейерному HotStuff, на уровне структуры протокола.
Конечные разветвления могут искажать экономические стимулы предложителей блоков и представлять потенциальную угрозу для активности сети. MonadBFT вводит механизм повторного предложения и сертификаты без одобрения (NEC), чтобы гарантировать, что любой блок, предложенный честным лидером и получивший законное большинство голосов, не будет заброшен или пропущен.
В следующей статье мы продолжим обсуждать две другие ключевые характеристики MonadBFT:
2）Оптимистичная отзывчивость (Optimistic Responsiveness)
и далее проанализировать реальное значение этих механизмов для валидаторов и разработчиков.
Продолжение следует.