Ядро Блокчейн заключается в реализации строгого глобального соглашения (strict global consensus): то есть, независимо от того, в какой стране или часовом поясе распределены узлы сети, все участники в конечном итоге должны согласовать набор объективных результатов.
Но в реальности распределенные сети не идеальны: узлы отключаются, узлы лгут, и даже есть люди, которые намеренно причиняют вред. В таких условиях как система может «говорить в унисон» и поддерживать согласованность?
Это проблема, которую должен решить протокол соглашения. По сути, это набор правил, предназначенных для того, чтобы направлять группу независимых друг от друга, а иногда даже ненадежных узлов, как прийти к единому решению по порядку и содержанию каждой транзакции.
И как только это "строгое соглашение" будет установлено, Блокчейн сможет разблокировать множество ключевых особенностей, таких как защита цифровой собственности, антиинфляционная денежная модель и масштабируемая структура социального сотрудничества. Но при этом соглашение само должно одновременно гарантировать два основных аспекта:
Не могут быть подтверждены два конфликтующих Блока.
Сеть должна постоянно развиваться, не может застревать или останавливаться.
MonadBFT является последним техническим прорывом в этом направлении.
Краткий обзор эволюции соглашений
В области механизмов согласия на самом деле исследуют уже десятилетиями. Первые протоколы, такие как PBFT (Практическое байтоновское согласие), уже могут обрабатывать одну очень реальную ситуацию: даже если в сети есть часть узлов, которые выходят из строя, действуют злонамеренно или говорят ерунду, пока их не более 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). В его механизме каждый валидатор просто отправляет свой голос текущему лидеру, который затем упаковывает эти голоса и генерирует Сертификат Кворума (QC, законодательно установленное большинство).
Этот QC по сути является коллективной подписью, подтверждающей всей сети: "Большинство узлов согласны с этим предложением."
В отличие от этого, коммуникационная модель PBFT представляет собой "всеобщее вещание", где все говорят в группе, что приводит к довольно хаотичной обстановке. Модель HotStuff больше похожа на "один собирает, один упаковывает", которая продолжает эффективно работать, независимо от того, сколько людей в сети.
Помимо линейной связи, HotStuff также может быть дополнительно обновлен до конвейерной версии (потоковый HotStuff), чтобы повысить эффективность.
В оригинальном HotStuff один и тот же валидатор будет непрерывно выступать в роли лидера в нескольких раундах, пока блок не будет полностью подтвержден. Этот процесс называется "обработка одного блока за раунд", и все силы сосредоточены на продвижении именно этого.
А в конвейере HotStuff механизм стал еще более гибким: в каждом раунде выбирается новый лидер, и у каждого лидера есть две задачи:
С одной стороны, упаковывая голосование предыдущего раунда в Соглашение о Кворуме (QC), транслируя его по всей сети;
Предложить новый Блок и подготовиться к следующему раунду.
То есть, это больше не "подтверждение одного перед обработкой следующего", а как на производственной линии, разные лидеры по очереди отвечают за каждый этап. Предыдущий предлагает Блок, следующий подтверждает его и продолжает предлагать новые Блоки, согласие в цепочке передается как эстафета.
Это и есть происхождение метафоры "конвейер": текущий Блок еще проходит процесс подтверждения, а следующий уже готовится, многократные шаги параллельно, что повышает эффективность пропускной способности.
В заключение, протоколы типа HotStuff существенно улучшили два аспекта по сравнению с традиционным BFT:
Во-первых, связь более легкая, каждый валидатор должен общаться только с лидером;
Во-вторых, эффективность обработки выше, несколько процессов подтверждения блоков могут выполняться параллельно.
Это сделало HotStuff шаблоном для дизайна многих современных механизмов соглашения PoS Блокчейн. Однако, как и в любом деле, есть свои плюсы и минусы — хотя конвейерная структура обладает высокой производительностью, она также тихо вводит структурный риск, который трудно обнаружить.
Теперь давайте углубимся в этот ключевой вопрос: отводный разветвление (Tail Forking).
Проблема разветвления хвоста (Tail-Forking)
Хотя HotStuff — особенно его конвейерная версия — решает проблемы масштабируемости соглашения, он также вводит некоторые новые вызовы. Одной из самых критических и легко игнорируемых является проблема так называемого «хвостового ответвления» (Tail Forking).
Что такое хвостовое разделение? Можно просто понять как: в "конце цепочки" Блокчейн произошла неожиданная переорганизация блока (reorg).
Конкретно говоря, есть один Блок, который является действительным и уже успешно распространен среди большинства Узлов, и получил достаточно голосов в поддержку, по идее, он должен быть немедленно подтвержден и записан в основную цепь. Но в конце концов, он был "пропущен", и был отвергнут (orphaned), на его место пришел другой новый Блок на той же высоте.
Это не ошибка и не атака, а потому что в самом дизайне протокола существует возможность «потери блока». Не кажется ли это немного несправедливым? Так как же это происходит?
Мы уже говорили, что у каждого лидера в конвейере HotStuff есть две задачи:
A. Предложить новый блок (например, Bₙ₊₁)
B. Собирать голоса за блок предыдущего лидера, генерировать QC (например, завершить окончательное подтверждение для Bₙ)
Эти две задачи выполняются параллельно, по очереди. Но проблема заключается в этом.
Пример: предположим, что Алиса является лидером, и она предложила Блок Bₙ на высоте n. Этот блок получил супербольшинство голосов и уже "почти подтвержден". Далее Боб должен занять пост лидера и продолжить продвигать следующий блок 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) валидаторов и объединять их в одно свидетельство о тайм-ауте (Timeout Certificate, TC). Этот TC представляет собой: единое когнитивное мгновенное восприятие всей сети о "головном блоке" в случае неудачи предыдущего раунда. Новый лидер выберет блок с самой высокой высотой (или последним номером вида), так называемый high_tip.
MonadBFT требует: предложение нового лидера должно содержать законный TC и должно повторно предложить самый высокий приостановленный Блок в TC, чтобы этот Блок снова получил шанс на подтверждение.
Почему? Как мы уже упоминали ранее: мы не хотим, чтобы почти подтвержденный Блок исчез.
Например: предположим, что Алиса является лидером view 5, предложила действительный Блок и получила большинство голосов. Затем лидер view 6, Боб, оказался офлайн и не смог продвинуть процесс цепочки. Когда Каролина станет лидером view 7, согласно правилам MonadBFT, она должна включить TC и снова предложить Блок Алисы. Таким образом, честный труд Алисы не будет напрасным.
Если у Кэрол нет блока Элис, она может запросить его у других узлов. Узлы могут:
Предоставьте этот Блок, или
Вернуть подписанное "сообщение без одобрения" (No-Endorsement, NE), указывающее на то, что у вас нет этого блока (механизм будет описан позже). (Не более f византийских узлов могут решить игнорировать запрос и не реагировать.)
Как только Кэрол повторно предложит блок Алисы, она получит дополнительную возможность для предложения, что гарантирует, что она не будет подвергнута "коллективной ответственности" из-за неудачи предыдущего лидера.
Эта функция механизма повторного предложения ясна: обеспечить справедливое продвижение Блока, чтобы никакая эффективная работа не была тихо отброшена из-за неудачи или вмешательства.
Без поручительства сертификат (NEC)
Продолжая предыдущий пример: после истечения времени раунда Боба, Кэрол запрашивает у других валидаторов предоставление high_tip Блок (т.е. блок Алис). В этот момент как минимум 2f+1 валидаторов ответят:
Либо предоставьте Блок Алисы
Отправьте подписанное сообщение NE, чтобы указать, что вы не получили блок Алиссы.
Как только Кэрол получит Блок от Элис, она должна будет заново предложить его в соответствии с правилами. Кэрол может пропустить этот Блок и предложить новый только в том случае, если по крайней мере 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 анализ (часть 1): Как решить проблему хвостового форка
Ядро Блокчейн заключается в реализации строгого глобального соглашения (strict global consensus): то есть, независимо от того, в какой стране или часовом поясе распределены узлы сети, все участники в конечном итоге должны согласовать набор объективных результатов.
Но в реальности распределенные сети не идеальны: узлы отключаются, узлы лгут, и даже есть люди, которые намеренно причиняют вред. В таких условиях как система может «говорить в унисон» и поддерживать согласованность?
Это проблема, которую должен решить протокол соглашения. По сути, это набор правил, предназначенных для того, чтобы направлять группу независимых друг от друга, а иногда даже ненадежных узлов, как прийти к единому решению по порядку и содержанию каждой транзакции.
И как только это "строгое соглашение" будет установлено, Блокчейн сможет разблокировать множество ключевых особенностей, таких как защита цифровой собственности, антиинфляционная денежная модель и масштабируемая структура социального сотрудничества. Но при этом соглашение само должно одновременно гарантировать два основных аспекта:
Не могут быть подтверждены два конфликтующих Блока.
Сеть должна постоянно развиваться, не может застревать или останавливаться.
MonadBFT является последним техническим прорывом в этом направлении.
Краткий обзор эволюции соглашений
В области механизмов согласия на самом деле исследуют уже десятилетиями. Первые протоколы, такие как PBFT (Практическое байтоновское согласие), уже могут обрабатывать одну очень реальную ситуацию: даже если в сети есть часть узлов, которые выходят из строя, действуют злонамеренно или говорят ерунду, пока их не более 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). В его механизме каждый валидатор просто отправляет свой голос текущему лидеру, который затем упаковывает эти голоса и генерирует Сертификат Кворума (QC, законодательно установленное большинство).
Этот QC по сути является коллективной подписью, подтверждающей всей сети: "Большинство узлов согласны с этим предложением."
В отличие от этого, коммуникационная модель PBFT представляет собой "всеобщее вещание", где все говорят в группе, что приводит к довольно хаотичной обстановке. Модель HotStuff больше похожа на "один собирает, один упаковывает", которая продолжает эффективно работать, независимо от того, сколько людей в сети.
Помимо линейной связи, HotStuff также может быть дополнительно обновлен до конвейерной версии (потоковый HotStuff), чтобы повысить эффективность.
В оригинальном HotStuff один и тот же валидатор будет непрерывно выступать в роли лидера в нескольких раундах, пока блок не будет полностью подтвержден. Этот процесс называется "обработка одного блока за раунд", и все силы сосредоточены на продвижении именно этого.
А в конвейере HotStuff механизм стал еще более гибким: в каждом раунде выбирается новый лидер, и у каждого лидера есть две задачи:
С одной стороны, упаковывая голосование предыдущего раунда в Соглашение о Кворуме (QC), транслируя его по всей сети;
Предложить новый Блок и подготовиться к следующему раунду.
То есть, это больше не "подтверждение одного перед обработкой следующего", а как на производственной линии, разные лидеры по очереди отвечают за каждый этап. Предыдущий предлагает Блок, следующий подтверждает его и продолжает предлагать новые Блоки, согласие в цепочке передается как эстафета.
Это и есть происхождение метафоры "конвейер": текущий Блок еще проходит процесс подтверждения, а следующий уже готовится, многократные шаги параллельно, что повышает эффективность пропускной способности.
В заключение, протоколы типа HotStuff существенно улучшили два аспекта по сравнению с традиционным BFT:
Во-первых, связь более легкая, каждый валидатор должен общаться только с лидером;
Во-вторых, эффективность обработки выше, несколько процессов подтверждения блоков могут выполняться параллельно.
Это сделало HotStuff шаблоном для дизайна многих современных механизмов соглашения PoS Блокчейн. Однако, как и в любом деле, есть свои плюсы и минусы — хотя конвейерная структура обладает высокой производительностью, она также тихо вводит структурный риск, который трудно обнаружить.
Теперь давайте углубимся в этот ключевой вопрос: отводный разветвление (Tail Forking).
Проблема разветвления хвоста (Tail-Forking)
Хотя HotStuff — особенно его конвейерная версия — решает проблемы масштабируемости соглашения, он также вводит некоторые новые вызовы. Одной из самых критических и легко игнорируемых является проблема так называемого «хвостового ответвления» (Tail Forking).
Что такое хвостовое разделение? Можно просто понять как: в "конце цепочки" Блокчейн произошла неожиданная переорганизация блока (reorg).
Конкретно говоря, есть один Блок, который является действительным и уже успешно распространен среди большинства Узлов, и получил достаточно голосов в поддержку, по идее, он должен быть немедленно подтвержден и записан в основную цепь. Но в конце концов, он был "пропущен", и был отвергнут (orphaned), на его место пришел другой новый Блок на той же высоте.
Это не ошибка и не атака, а потому что в самом дизайне протокола существует возможность «потери блока». Не кажется ли это немного несправедливым? Так как же это происходит?
Мы уже говорили, что у каждого лидера в конвейере HotStuff есть две задачи:
A. Предложить новый блок (например, Bₙ₊₁)
B. Собирать голоса за блок предыдущего лидера, генерировать QC (например, завершить окончательное подтверждение для Bₙ)
Эти две задачи выполняются параллельно, по очереди. Но проблема заключается в этом.
Пример: предположим, что Алиса является лидером, и она предложила Блок Bₙ на высоте n. Этот блок получил супербольшинство голосов и уже "почти подтвержден". Далее Боб должен занять пост лидера и продолжить продвигать следующий блок 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) валидаторов и объединять их в одно свидетельство о тайм-ауте (Timeout Certificate, TC). Этот TC представляет собой: единое когнитивное мгновенное восприятие всей сети о "головном блоке" в случае неудачи предыдущего раунда. Новый лидер выберет блок с самой высокой высотой (или последним номером вида), так называемый high_tip.
MonadBFT требует: предложение нового лидера должно содержать законный TC и должно повторно предложить самый высокий приостановленный Блок в TC, чтобы этот Блок снова получил шанс на подтверждение.
Почему? Как мы уже упоминали ранее: мы не хотим, чтобы почти подтвержденный Блок исчез.
Например: предположим, что Алиса является лидером view 5, предложила действительный Блок и получила большинство голосов. Затем лидер view 6, Боб, оказался офлайн и не смог продвинуть процесс цепочки. Когда Каролина станет лидером view 7, согласно правилам MonadBFT, она должна включить TC и снова предложить Блок Алисы. Таким образом, честный труд Алисы не будет напрасным.
Если у Кэрол нет блока Элис, она может запросить его у других узлов. Узлы могут:
Предоставьте этот Блок, или
Вернуть подписанное "сообщение без одобрения" (No-Endorsement, NE), указывающее на то, что у вас нет этого блока (механизм будет описан позже). (Не более f византийских узлов могут решить игнорировать запрос и не реагировать.)
Как только Кэрол повторно предложит блок Алисы, она получит дополнительную возможность для предложения, что гарантирует, что она не будет подвергнута "коллективной ответственности" из-за неудачи предыдущего лидера.
Эта функция механизма повторного предложения ясна: обеспечить справедливое продвижение Блока, чтобы никакая эффективная работа не была тихо отброшена из-за неудачи или вмешательства.
Без поручительства сертификат (NEC)
Продолжая предыдущий пример: после истечения времени раунда Боба, Кэрол запрашивает у других валидаторов предоставление high_tip Блок (т.е. блок Алис). В этот момент как минимум 2f+1 валидаторов ответят:
Либо предоставьте Блок Алисы
Отправьте подписанное сообщение NE, чтобы указать, что вы не получили блок Алиссы.
Как только Кэрол получит Блок от Элис, она должна будет заново предложить его в соответствии с правилами. Кэрол может пропустить этот Блок и предложить новый только в том случае, если по крайней мере 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:
Спекулятивная окончательность
Оптимистичная отзывчивость (Optimistic Responsiveness)
И далее проанализировать фактическое значение этих механизмов для валидаторов и разработчиков.
Продолжение следует.