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

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

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

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

• Два противоречащих блока не могут быть подтверждены;
• Сеть должна продолжать двигаться вперед и не может застрять или остановиться.

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

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

В области механизма консенсуса изучается уже десятилетия. Самые ранние протоколы, такие как PBFT (Practical Byzantine Fault Tolerance), уже могут обрабатывать очень реалистичную ситуацию: даже если некоторые узлы в сети отказываются от цепи, действуют злонамеренно или говорят глупости, пока их количество не превышает треть от общего числа, система все равно может достичь консенсуса.

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

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

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

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

Источник информации:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

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

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

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

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

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

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

Этот КС в основном является коллективной подписью, доказывающей всей сети: 'Большинство узлов согласны с этим предложением.'

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

Фигура сравнивает структуру коммуникации с распределением вентилятора HotStuff с полностью взаимосвязанным режимом PBFT Источник:

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

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

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

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

• Упаковать последний раунд голосов в Сертификат Кворума (QC) с одной стороны и передать его по всей сети;
• С одной стороны предлагается новый блок, готовый начать следующий раунд.

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

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

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

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

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

Далее мы собираемся погрузиться в эту основную проблему: Tail Forking.

Проблема хвостовой вилки в конце

Хотя HotStuff, особенно его конвейерная версия, решает проблему масштабируемости протокола консенсуса, он также вносит некоторые новые вызовы. Самая важная и легко пренебрегаемая - так называемая проблема "Tail Forking".

Что такое хвостовая вилка? Это можно просто понять как: блокчейн переживает случайную реорганизацию блоков на 'хвосте' цепи.

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

Это не ошибка и не атака, а потому что в структуре дизайна самого протокола есть возможность этого 'цепного хвоста'. Это звучит немного несправедливо? Так как это происходит?

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

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

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

Например, предположим, что Алиса является лидером, и она предложила блок Bₙ на высоте n, который получил сверхбольшинство голосов и «почти подтвержден».

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

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

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

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

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

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

Сначала вознаграждения поглощаются:

Если блок отклоняется, лидер, который его предложил, не получит никаких вознаграждений, ни блок-наград, ни комиссий за транзакции. Например, если Алиса предложила действительный блок и получила подавляющую поддержку на голосовании, но из-за ошибки или злонамеренных действий Боба блок не мог быть подтвержден, в конце концов Алиса не получит ни цента. Это приведет к несовершенной системе стимулирования: злонамеренные узлы, подобные Бобу, могут 'отрезать' свой источник вознаграждения, пропуская блоки противников. Для такого поведения не требуются технические атаки, достаточно умышленного 'несотрудничества' для ослабления прибыли конкурентов. Если такое повторяется, со временем участие и справедливость всей системы уменьшатся, и даже могут вызвать сговор среди узлов.

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

Вилки хвоста также создают более скрытую, но серьезную проблему: есть больше места для злонамеренного манипулирования MEV (Максимальная Извлекаемая Стоимость). Вот пример: Допустим, у Элис есть ценная арбитражная сделка в ее блоке. Если Боб хочет навредить, он может сговориться с следующим лидером, Кэрол, и умышленно не распространять блок Элис. Затем Кэрол воссоздает новый блок на том же уровне, «украв» исходную арбитражную сделку Элис - сделав MEV выигрышем для себя. Эта практика «перестановки головы цепи + сговора и присвоения» все еще блок согласно правилам на поверхности, но на самом деле это хорошо спланированное разорение. Что еще хуже, это вызывает «сговор» между лидерами, превращая подтверждение блока в игру по распределению выгод, а не общественную услугу.

Третье, подорвать гарантию окончательности, повлияв на опыт пользователя:

По сравнению с протоколами типа Накамото, одним из основных преимуществ BFT является детерминированная окончательность: как только блок зафиксирован, его нельзя отменить. Однако хвостовая вилка нарушает эту гарантию, особенно на блоках, которые 'предварительно зафиксированы, но еще не формально подтверждены'. Некоторые высокопроизводительные dapp-приложения часто хотят сразу читать данные после голосования за блок, чтобы сократить задержку, и если блок внезапно отклоняется, это может вызвать откат состояния пользователя - например, аномальные балансы счетов, исчезновение завершенных сделок с высоким плечом без видимой причины или внезапные сбросы состояния игры.

Четвертый, может вызвать цепную реакцию отказа:

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

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

Что такое MonadBFT?

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

1) Поворотный лидер: Выберите нового лидера для каждого раунда, чтобы продвигать цепь вперед;
2) Pipelined commits: Множественные процессы подтверждения блоков могут перекрываться;
3) Линейное взаимодействие (линейная передача сообщений): каждый валидатор должен общаться только с лидером, что позволяет сэкономить много сетевого трафика.

Но просто полагаться на эти три точки недостаточно безопасно. Для устранения структурной уязвимости хвостовой вилки MonadBFT добавил два ключевых механизма:

1) Обязательный механизм повторного предложения (Re-Proposal)
2) Неудостоверительное свидетельство (НУС)

Механизм повторного предложения

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

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

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

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

Новый раунд лидеров соберет эти сообщения о таймауте от сверхбольшинства (2f+1) валидаторов и объединит их в Сертификат таймаута (TC). Этот TC представляет собой унифицированный когнитивный снимок 'головного блока цепи' всей сети в случае сбоя предыдущего раунда. Новый лидер выберет блок с наибольшей высотой (или последний номер просмотра), известный как high_tip, из него.

MonadBFT требует: Предложение нового лидера должно включать действительный TC и повторно предлагать наивысший ожидающий блок в TC, чтобы дать этому блоку еще один шанс на подтверждение.

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

Например, предположим, что Алиса является лидером представления 5, предложила действительный блок и получила большинство голосов. Далее, когда лидер представления 6, Боб, находится в офлайне и не может продвинуть цепочку дальше, к моменту, когда Кэрол становится лидером представления 7, согласно правилам MonadBFT, ей необходимо включить TC и повторно предложить блок Алисы. Таким образом, добросовестная работа Алисы не пропадет даром.

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

• Предоставьте блок, или
• Вернуть подписанное сообщение 'Без одобрения (NE)', указывающее, что отправитель не имеет этот блок (его механизм объясняется позже). (До f византийских узлов могут выбрать игнорировать запрос и не отвечать).

Когда Кэрол пере предлагает блок Алисы, она получит дополнительную возможность предложения, чтобы убедиться, что она не 'причастна' к неудаче предыдущего лидера.

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

Непереустраиваемый сертификат (NEC)

Продолжая предыдущий пример: После истечения времени хода Боба, Кэрол просит других валидаторов предоставить блок high_tip (т.е. блок Алисы). На этом этапе ответят по крайней мере 2f+1 валидаторов:

• Либо предоставьте блоки Элис
• Отправьте подписанное сообщение NE, указывающее, что вы не получили блок Алисы.

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

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

Поэтому, если Кэрол утверждает: «Я не могу получить блок Алисы», она должна предоставить f+1 подписей валидатора, чтобы доказать, что ни один из них его не получил. Это составляет Свидетельство об Отказе (NEC).

NEC - это удостоверение "отказа" лидера: это подтверждение того, что предыдущий блок не готов к подтверждению, не был злонамеренно пропущен, а был "заброшен" по определенным причинам.

Пересмотр + Неподтвержденный сертификат = Разрешить хвостовую вилку

MonadBFT вводит набор строгих и четких правил обработки головных цепочек, представляя механизм повторного предложения и сертификат без-подтверждения (NEC).

Либо окончательно подтвердите блок 'почти подтвержденный';

Предоставьте достаточные доказательства того, что блок еще не готов к подтверждению,

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

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

Структурные риски хвостовой вилки систематически устраняются, и протокол может четко ограничивать неправильное пропускание поведения.

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

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

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

Более того, MonadBFT не жертвовал производительностью протокола для повышения безопасности.

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

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

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

Динамический баланс между производительностью и безопасностью является одним из основных преимуществ MonadBFT перед своими предшественниками протоколами.

Сводка

Эта статья рассматривает основной механизм традиционного согласия PBFT, систематизирует путь развития протокола HotStuff и фокусируется на том, как MonadBFT решает врожденную проблему хвостовой вилки в структуре протокола HotStuff на уровне протокола.

Задние вилки могут исказить экономические стимулы блок-предложителей и представлять потенциальную угрозу для сетевой активности. MonadBFT гарантирует, что любой блок, предложенный честными лидерами и утвержденный большинством голосов, не будет заброшен или пропущен путем введения механизма повторного предложения и сертификата Non-Endorsed (NEC).

В следующей статье мы продолжим изучать другие два основных элемента MonadBFT:

1）Спекулятивная окончательность
2）Оптимистичная отзывчивость

Дальнейший анализ этих механизмов и их практическое значение для валидаторов и разработчиков.

Утверждение:

1. Эта статья перепечатана из [michael_lwy], авторские права принадлежат автору оригинала [michael_lwy]，если у вас есть возражения к перепечатке, пожалуйста, свяжитесь Gate Learn Team) команда обработает его как можно скорее в соответствии с соответствующим процессом.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционными советами.
3. Другие языковые версии статьи переведены командой Gate Learn без упоминанияGateНе копируйте, не распространяйте и не плагиатируйте переведенные статьи без разрешения.