В первой части мы изучили, как работает классическое PBFT (практическая отказоустойчивость Byzantine) соглашение и как работали ранние версии 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-family
MonadBFT основан на серии протоколов согласования HotStuff, но выделяется благодаря реализации сочетания ряда идеальных характеристик. Ранние протоколы обычно оптимизировались для определенных измерений, таких как конвейерная пропускная способность или линейная связь, но приходилось жертвовать другими аспектами. MonadBFT уникально сочетает линейную сложность сообщений, конвейерную подачу, мощную защиту от хвостовых форков, мгновенную реакцию без фиксированной задержки и эффективные механизмы восстановления, одновременно сохраняя быструю финализацию и гарантии высокой доступности. В следующей таблице приведено сравнение MonadBFT с другими протоколами BFT с ротацией лидеров по этим ключевым измерениям:
Что это означает для разработчиков и пользователей?
Для разработчиков MonadBFT означает несколько моментов:
Более простая модель окончательной определенности: используя MonadBFT, вы можете рассматривать блоки с QC (голосование большинства) как фактически окончательно определенные, поскольку протокол либо окончательно определяет их, либо применяет наказание. Разработчики могут с высокой уверенностью безопасно работать с 1 подтверждением блока.
Улучшение пользовательского опыта приложения: Если вы разрабатываете приложение с высокой пропускной способностью (биржа, игры и т. д.), низкая задержка и устойчивость к форкам MonadBFT приведут к более плавному пользовательскому опыту. Пользователи могут почти мгновенно видеть, что их операции подтверждены, и не будут часто сталкиваться с запутанными перестройками или откатами. Таким образом, вы сможете создать приложение с окончательной определенностью и быстрым обновлением.
Детерминированное поведение: более строгие правила MonadBFT (например, требования к повторному предложению) уменьшают неопределенность, связанную с включением блока. Из-за тонких временных факторов, таких как то, достигает ли голосование или тайм-аут лидера, становится меньше «граничных случаев», когда блок включается или пропускается. MonadBFT заменяет эту времязависимую неопределенность ясными правилами и проверяемыми доказательствами. Это упрощает проверку правильности протокола и тестирование. Оно также предоставляет четкие основания для выявления неисправных узлов (например, если кто-то не смог повторно предложить или предложил конфликтующий блок, вы знаете, что они нарушили соглашение).
Пространство масштабируемости: Если вы разработчик, который сосредоточен на масштабируемости, MonadBFT предоставляет вам больше пространства до того, как вы столкнетесь с узким местом. В отличие от вторичных протоколов, вы можете легче увеличить размер блока или количество валидаторов. Кроме того, такие функции, как кодирование блоков с удалением, означают, что вы можете отправлять большие объемы данных по сети, не перегружая отдельный узел. Это позволяет нацелиться на более высокую пропускную способность и открывает пространство для проектирования более амбициозных приложений на цепочке.
Для конечных пользователей: Обычные пользователи не будут понимать никакого из того, что мы здесь обсуждаем, но они будут чувствовать его влияние. С MonadBFT в качестве основы для цепочки Monad пользователи могут ожидать все хорошие характеристики, не жертвуя децентрализацией и сопротивлением цензуре.
Более быстрое подтверждение: Транзакции (такие как отправка токенов, обмен активов, выпуск NFT, выполнение транзакций) будут быстро подтверждены.
Снижение непредвиденных ситуаций: согласованность состояния цепи выше, потому что такие вещи, как хвостовой форк, которые по своей сути относятся к реорганизации, были устранены.
Справедливость и прозрачность: Улучшение соглашения косвенно означает, что работа цепи становится более справедливой. Ни один отдельный валидатор не может легко проверять транзакции или манипулировать порядком между блоками.
Заключение
В заключение, MonadBFT вводит четыре ключевых инновации на основе конвейерного соглашения в стиле HotStuff:
Устойчивость к разветвлению хвоста: MonadBFT является первым протоколом BFT с конвейером, устраняющим атаки с разветвлением хвоста. Это делается путем того, что следующий лидер повторно предлагает последний проголосованный блок в случае поражения предыдущего лидера или демонстрирует сертификат об отсутствии поддержки (NEC), который доказывает, что блоку не хватает поддержки. Это гарантирует, что любой блок, получивший поддержку большинства, не будет отменен, защищая награды честных лидеров и предотвращая злонамеренные реорганизации и извлечение MEV из перекрестных блоков.
Конечность однократной спекуляции: валидаторы могут подтвердить блок после однократной коммуникации (предложение и голосование одного лидера), предоставляя клиенту мгновенную гарантию включения. Эта спекулятивная проверка восстанавливается только в случае атаки эквивалентности лидера (действия, которые могут быть доказаны и наказаны), что делает её, на практике, безопасным предположением.
Оптимистичная отзывчивость: Протокол работает на скорости сети, без врожденной задержки. Лидер немедленно продвигает соглашение после получения необходимых голосов, изменения в представлении происходят немедленно после истечения времени наблюдения кворума, а не после ожидания фиксированного временного интервала. Такой дизайн оптимистичной отзывчивости минимизирует время ожидания и максимизирует пропускную способность, одновременно обеспечивая надежную обработку в условиях асинхронности и сбоев.
Линейная коммуникация: На счастливом пути (т.е. лидер честен) сложность сообщений и проверок линейна количеству валидаторов. MonadBFT сохраняет эффективную коммуникационную модель HotStuff, используя агрегированные подписи и простую трансляцию лидеров для валидаторов, что позволяет масштабировать протокол до сотен валидаторов без узких мест производительности.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
MonadBFT анализ (часть 2): что это означает для разработчиков и пользователей
В первой части мы изучили, как работает классическое PBFT (практическая отказоустойчивость Byzantine) соглашение и как работали ранние версии 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-family
MonadBFT основан на серии протоколов согласования HotStuff, но выделяется благодаря реализации сочетания ряда идеальных характеристик. Ранние протоколы обычно оптимизировались для определенных измерений, таких как конвейерная пропускная способность или линейная связь, но приходилось жертвовать другими аспектами. MonadBFT уникально сочетает линейную сложность сообщений, конвейерную подачу, мощную защиту от хвостовых форков, мгновенную реакцию без фиксированной задержки и эффективные механизмы восстановления, одновременно сохраняя быструю финализацию и гарантии высокой доступности. В следующей таблице приведено сравнение MonadBFT с другими протоколами BFT с ротацией лидеров по этим ключевым измерениям:
Что это означает для разработчиков и пользователей?
Для разработчиков MonadBFT означает несколько моментов:
Более простая модель окончательной определенности: используя MonadBFT, вы можете рассматривать блоки с QC (голосование большинства) как фактически окончательно определенные, поскольку протокол либо окончательно определяет их, либо применяет наказание. Разработчики могут с высокой уверенностью безопасно работать с 1 подтверждением блока.
Улучшение пользовательского опыта приложения: Если вы разрабатываете приложение с высокой пропускной способностью (биржа, игры и т. д.), низкая задержка и устойчивость к форкам MonadBFT приведут к более плавному пользовательскому опыту. Пользователи могут почти мгновенно видеть, что их операции подтверждены, и не будут часто сталкиваться с запутанными перестройками или откатами. Таким образом, вы сможете создать приложение с окончательной определенностью и быстрым обновлением.
Детерминированное поведение: более строгие правила MonadBFT (например, требования к повторному предложению) уменьшают неопределенность, связанную с включением блока. Из-за тонких временных факторов, таких как то, достигает ли голосование или тайм-аут лидера, становится меньше «граничных случаев», когда блок включается или пропускается. MonadBFT заменяет эту времязависимую неопределенность ясными правилами и проверяемыми доказательствами. Это упрощает проверку правильности протокола и тестирование. Оно также предоставляет четкие основания для выявления неисправных узлов (например, если кто-то не смог повторно предложить или предложил конфликтующий блок, вы знаете, что они нарушили соглашение).
Пространство масштабируемости: Если вы разработчик, который сосредоточен на масштабируемости, MonadBFT предоставляет вам больше пространства до того, как вы столкнетесь с узким местом. В отличие от вторичных протоколов, вы можете легче увеличить размер блока или количество валидаторов. Кроме того, такие функции, как кодирование блоков с удалением, означают, что вы можете отправлять большие объемы данных по сети, не перегружая отдельный узел. Это позволяет нацелиться на более высокую пропускную способность и открывает пространство для проектирования более амбициозных приложений на цепочке.
Для конечных пользователей: Обычные пользователи не будут понимать никакого из того, что мы здесь обсуждаем, но они будут чувствовать его влияние. С MonadBFT в качестве основы для цепочки Monad пользователи могут ожидать все хорошие характеристики, не жертвуя децентрализацией и сопротивлением цензуре.
Более быстрое подтверждение: Транзакции (такие как отправка токенов, обмен активов, выпуск NFT, выполнение транзакций) будут быстро подтверждены.
Снижение непредвиденных ситуаций: согласованность состояния цепи выше, потому что такие вещи, как хвостовой форк, которые по своей сути относятся к реорганизации, были устранены.
Справедливость и прозрачность: Улучшение соглашения косвенно означает, что работа цепи становится более справедливой. Ни один отдельный валидатор не может легко проверять транзакции или манипулировать порядком между блоками.
Заключение
В заключение, MonadBFT вводит четыре ключевых инновации на основе конвейерного соглашения в стиле HotStuff:
Устойчивость к разветвлению хвоста: MonadBFT является первым протоколом BFT с конвейером, устраняющим атаки с разветвлением хвоста. Это делается путем того, что следующий лидер повторно предлагает последний проголосованный блок в случае поражения предыдущего лидера или демонстрирует сертификат об отсутствии поддержки (NEC), который доказывает, что блоку не хватает поддержки. Это гарантирует, что любой блок, получивший поддержку большинства, не будет отменен, защищая награды честных лидеров и предотвращая злонамеренные реорганизации и извлечение MEV из перекрестных блоков.
Конечность однократной спекуляции: валидаторы могут подтвердить блок после однократной коммуникации (предложение и голосование одного лидера), предоставляя клиенту мгновенную гарантию включения. Эта спекулятивная проверка восстанавливается только в случае атаки эквивалентности лидера (действия, которые могут быть доказаны и наказаны), что делает её, на практике, безопасным предположением.
Оптимистичная отзывчивость: Протокол работает на скорости сети, без врожденной задержки. Лидер немедленно продвигает соглашение после получения необходимых голосов, изменения в представлении происходят немедленно после истечения времени наблюдения кворума, а не после ожидания фиксированного временного интервала. Такой дизайн оптимистичной отзывчивости минимизирует время ожидания и максимизирует пропускную способность, одновременно обеспечивая надежную обработку в условиях асинхронности и сбоев.
Линейная коммуникация: На счастливом пути (т.е. лидер честен) сложность сообщений и проверок линейна количеству валидаторов. MonadBFT сохраняет эффективную коммуникационную модель HotStuff, используя агрегированные подписи и простую трансляцию лидеров для валидаторов, что позволяет масштабировать протокол до сотен валидаторов без узких мест производительности.