ВЧасть 1,Мы изучили, как работает классическое согласование PBFT, и как работают более ранние версии HotStuff. Мы также рассмотрели, как MonadBFT решает проблему tail-forking в HotStuff, когда действительные блоки иногда остаются позади в конвейерных системах.

Эта проблема разветвления хвоста создает две большие проблемы: 1) это портит награды для честных строителей блоков и 2) потенциально может замедлить сеть.

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

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

Однокруговая спекулятивная окончательность

Помимо устойчивости к хвостовой вилке, еще одной основной особенностью MonadBFT является спекулятивная окончательность в пределах одного раунда.

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

Напомним, что в протоколах базовой версии HotStuff блок обычно не считается окончательным (необратимым), пока он не пройдет как минимум две фазы (например, Fast-Hotstuff и Diem-BFT): одну фазу для получения сертификата кворума (блок блокируется ≥2f+1 голосами) и вторую фазу, где следующий лидер строит на этом СК и фиксирует блок.

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

MonadBFT в основном позволяет считать транзакцию достаточно окончательной (безопасной для действий) после всего одного раунда голосования. Это называется спекулятивной окончательностью.

Когда лидер предлагает блок, а валидаторы голосуют за формирование КК для этого блока, этот блок теперь находится в состоянии Проголосовано (он заблокирован кворумом). В MonadBFT валидаторы будут выполнять транзакции блока сразу после формирования КК и даже отправят предварительное подтверждение клиентам, указывающее, что блок (предварительно) принят. Это похоже на сказанное: «У нас есть сверхбольшинство, согласное на этот блок. Если что-то очень неожиданное не произойдет, считайте этот блок подтвержденным».

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

Вы можете рассматривать спекулятивную окончательность как приятный побочный продукт сопротивления хвостовому вилению. Сопротивление хвостовому вилению гарантирует, что даже если следующий лидер выйдет из строя, текущее предложение не будет заброшено (благодаря правилам повторного предложения и NEC). Таким образом, единственное время, когда спекулятивно выполненный блок отбрасывается, - это если первоначальный предлагающий сделал двойное подписание (доказуемо злонамеренная ошибка), которая: 1) обнаруживается с помощью конфликтующих QС, 2) подлежит штрафу и 3) крайне редкая.

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

Оптимистичная отзывчивость

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

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

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

MonadBFT разработан таким образом, что в обычном случае и даже при восстановлении после сбоя он не приостанавливается на предварительно определенное время, если необходимости в этом нет.

• В счастливом сценарии (означает, что у нас есть честный лидер): Нет встроенной задержки при предложении или голосовании. Как только у лидера наступает очередь, он предлагает блок. Как только валидаторы получают действительное предложение, они голосуют. В момент, когда лидер (или скорее следующий лидер, поскольку голоса идут на следующего предлагающего в канале HotStuff) собирает 2f+1 голосов, формируется QC и может быть распространен. В оптимистично отзывчивом дизайне это сразу запускает следующую фазу.

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

Он не ждет, например, полной секунды "времени слота", если ему не нужно. В отличие от основной сети Ethereum, которая следуетмодель слота и эпохи. На Ethereum производство блоков фиксировано с интервалом в 12 секунд. Даже если все готовы раньше, протокол ждет.

Подход MonadBFT устраняет ненужные задержки. Он сохраняет структуру HotStuff с конвейерной передачей данных, но удаляет жесткое правило "вы должны ждать Δ секунд" в обычном случае. Это означает, что он может превзойти системы, ограниченные временем, в отзывчивости, не жертвуя безопасностью.

• В несчастном случае (отказ лидера): Во многих протоколах консенсуса, когда лидер не предлагает блок, другие узлы осознают это только после истечения тайм-аута Δ. Если Δ, например, равно 1 секунде, то это время фактически теряется. MonadBFT обрабатывает это по-другому. Когда валидаторы обнаруживают отсутствующее предложение, они немедленно транслируют сообщения тайм-аута (TC или Сертификат тайм-аута). Как только видно 2f+1 из этих тайм-аутов, новый лидер берет на себя. Переход к новому виду вызывается доказательством на основе кворума, а не часами.

Сравнение с согласованием семьи hotstuff

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

Что это значит для разработчиков и пользователей?

Для разработчиков MonadBFT означает несколько вещей:

• Более простая модель окончательности: с MonadBFT вы можете рассматривать блок, который имеет QC (супербольшинство голосов), как фактически окончательный для большинства целей, потому что протокол завершит его или сократит, если нет. Разработчики могут безопасно действовать на подтверждениях 1 блока с высокой уверенностью.
• Улучшенный UX для приложений: Если вы создаете приложение с высокой пропускной способностью (биржа, игра и т. д.), Низкая задержка и устойчивость к вилкам MonadBFT обеспечивают более плавный UX. Пользователи почти мгновенно видят подтверждение своих действий и редко сталкиваются с путаницей в переорганизации или откате. Это позволяет вам создавать приложения, предполагающие окончательность и быстрые обновления.
• Детерминированное поведение: более строгие правила MonadBFT (например, требование повторного предложения) уменьшают недетерминированность включения блока. Есть меньше "угловых" сценариев, где блок может быть включен или пропущен в зависимости от тонких временных интервалов, таких как то, достигнул ли голос или тайм-аут лидера первым. MonadBFT заменяет такую зависящую от времени неопределенность явными правилами и проверяемыми доказательствами. Это упрощает рассуждения о корректности протокола и его тестирование. Также предоставляются ясные основания для выявления неисправных узлов (например, если кто-то не повторно предлагает или предлагает конфликтующий блок, вы знаете, что они нарушили протокол).
• Запас пропускной способности: Если вы разработчик, беспокоящийся о масштабировании, MonadBFT дает вам больше пространства перед ударом по узким местам. Вы можете увеличить размеры блоков или количество валидаторов более комфортно, чем на квадратичном протоколе. И функции, такие как распространение блоков с использованием кодирования стирания, означают, что вы можете передавать много данных через сеть, не перегружая отдельные узлы. Это позволяет стремиться к более высокой пропускной способности, что открывает пространство для более амбициозных онлайн-приложений

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

• Более быстрые подтверждения: Транзакции (например, отправка токенов, обмен активами, выпуск NFT, выполнение сделок) будут подтверждаться очень быстро.
• Меньше сюрпризов: Согласованность состояния цепи выше, так как вещи типа хвостового вилкинга, что по сути является реорганизацией, устраняются
• Честность и прозрачность: Улучшения в консенсусе косвенно означают, что работа цепи становится более справедливой. Ни один отдельный валидатор не может легко цензурировать транзакции или играть с порядком блоков.

Заключение

Для краткого повтора, MonadBFT вводит четыре основных инновации поверх консенсуса в стиле HotStuff с трубопроводной структурой:

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

Спекулятивная окончательность за один раунд: Валидаторы могут подтвердить блок после одного раунда коммуникации (предложение лидера и голосование), обеспечивая клиентам немедленное уверенность во включении. Это спекулятивное подтверждение будет отменено только в случае двойственного поведения лидера (действие, которое можно доказать и наказать), что делает его безопасным предположением на практике.

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

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

Отказ от ответственности:

1. Эта статья представлена ​​по лицензии [michael_lwy]. Все авторские права принадлежат оригинальному автору [michael_lwy]. Если есть возражения к этому повторному изданию, пожалуйста, свяжитесь сGate Learnкоманда, и они незамедлительно справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционной консультацией.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.