Анализ MonadBFT (Часть 2): Что это означает для разработчиков и пользователей

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

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

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

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

Спекулятивная финальность за один раунд​

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

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

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

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

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

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

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

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

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

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

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

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

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 блок.
• Улучшенный пользовательский опыт приложений:  Если вы создаете высокопроизводительное приложение (биржа, игры и т. д.), низкая задержка MonadBFT и устойчивость к разветвлениям приведут к более плавному пользовательскому опыту. Пользователи почти мгновенно увидят подтверждение своих действий и не будут часто сталкиваться с запутывающими реорганизациями или откатами. Таким образом, вы можете проектировать приложения с финальностью и быстрыми обновлениями.
• Детерминированное поведение:  Более строгие правила MonadBFT (например, требование повторного предложения) уменьшают неопределенность включения блоков. Существует меньше “крайних случаев”, когда блоки включаются или пропускаются из-за тонких временных факторов, таких как то, достигнут ли голоса или тайм-ауты лидера первыми. MonadBFT заменяет эту временную неопределенность четкими правилами и проверяемыми доказательствами. Это упрощает обоснование правильности протокола и тестирование. Это также предоставляет четкие основания для идентификации неисправных узлов (например, если кто-то не смог повторно предложить или предложил конфликтующий блок, вы знаете, что они нарушили протокол).
• Пространство для масштабируемости:  Если вы разработчик, ориентированный на масштабируемость, MonadBFT предоставляет вам больше пространства до возникновения узких мест. По сравнению с квадратичными протоколами, вы можете легче увеличивать размер блока или количество валидаторов. Кроме того, такие функции, как распространение блоков с кодированием стирания, означают, что вы можете передавать большие объемы данных по сети, не перегружая отдельные узлы. Это делает возможным ориентацию на более высокую пропускную способность, открывая пространство для дизайна для более амбициозных ончейн-приложений.

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

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

Заключение​

Подводя итог, MonadBFT внедряет четыре ключевые инновации на основе консенсуса в стиле конвейерного HotStuff:

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

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

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

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