Искусственный интеллект: анализ

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

Проблемы, связанные с цепочкой подтверждений

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

Старая версия HotShot использовала цепочку HotStuff: блок, предложенный в просмотре v, даже при достижении квалифицированного большинства голосов, не достигает окончательного результата немедленно. Его подтверждение должно быть включено в предложение просмотра v+1, а подтверждение самого просмотра v+1, в свою очередь, должно быть включено в просмотр v+2, чтобы исходный блок соответствовал правилам протокола.

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

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

Реструктуризация: два раунда голосования, окончательный результат достигается в пределах одного просмотра

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

1. Лидер предлагает блок, разбивает его на несколько небольших фрагментов с использованием избыточности и распределяет их по всем узлам-валидаторам.
2. Узлы-валидаторы, получив фрагменты, транслируют первый раунд голосования всем остальным узлам-валидаторам, а не следующему лидеру.
3. Любой узел, собравший квалифицированное большинство голосов в первом раунде, самостоятельно генерирует подтверждение 1, фиксирует блок и немедленно транслирует второй раунд голосования.
4. Любой узел, собравший квалифицированное большинство голосов во втором раунде, генерирует подтверждение 2, и блок официально достигает окончательного результата.

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

Голосование между всеми узлами сети против агрегирования голосов лидером

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

В новом протоколе используется голосование между всеми узлами сети: каждый проверяющий узел транслирует свой голос всем остальным узлам. Узел может самостоятельно сформировать сертификат, как только обнаружит легитимное большинство голосов. Сложность взаимодействия возрастает до O(n²), но это полностью устраняет "узкое место" агрегирования голосов и исключает класс проблем с неактивностью, вызванных сбоями в одном узле. Кроме того, подпротокол синхронизации "вида", который в старом протоколе использовался для решения проблем блокировки, больше не требуется. В режиме голосования между всеми узлами, где узлы могут самостоятельно формировать сертификаты, узел, пропустивший часть голосов, может завершить процесс принятия решения, получив сертификат, собранный другими узлами. Только в случае, если лидер действительно отключился или действует злонамеренно, можно использовать простой механизм таймаута для формирования сертификата.

При масштабе примерно в 100 проверяющих узлов, объем сообщений с голосами невелик, и затраты на взаимодействие O(n²) вполне управляемы. Это компромисс, адаптированный к текущему масштабу проверяющих узлов в HotShot. Если количество проверяющих узлов увеличится на порядок или более, потребуется оптимизация с использованием дополнительных решений, таких как выборка комитета, агрегирование подписей, иерархическая пересылка голосов. Мы рассматриваем это как проблему масштабирования в контексте децентрализации сети, которая является независимой от оптимизации задержки окончательного подтверждения, на которой мы сосредоточены в данном случае.

Доступность данных: повышение эффективности и отмена комитета по доступности данных

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

Новая версия протокола полностью полагается на VID (Verified Identity Data) для обеспечения доступности данных, и ключевая причина этого – значительное увеличение скорости восстановления блоков: лидер, основываясь на взвешенном вкладе, генерирует фрагменты данных для каждого валидатора с использованием кодов восстановления. Валидаторы начинают первый раунд голосования только после получения фрагментов, предназначенных для них. Это означает, что достижение квалифицированного большинства голосов в первом раунде само по себе доказывает наличие в сети набора фрагментов, пригодных для восстановления блока. Если две трети узлов, внесших залог, завершают голосование, это означает, что две трети узлов, внесших залог, владеют соответствующими фрагментами; а коды восстановления гарантируют, что этих фрагментов достаточно для восстановления целостного блока. Комитет DA (Decentralized Autonomous Organization) был полностью исключен, что позволило избежать целого цикла голосования и распределения нагрузки.

Сравнение с другими протоколами консенсуса, уже находящимися в эксплуатации

Ethereum Gasper (LMD-GHOST fork choice + Casper FFG finality mechanism)

Его архитектура ориентирована на другие принципы: количество валидаторов значительно превышает количество в HotShot, он явно поддерживает использование стандартного оборудования и низкую пропускную способность для обычных пользователей, внесших залог. Окончательность достигается путем проверки контрольных точек на границах эпох, а не путем выдачи сертификатов для каждого блока. Эти решения определяют, что время достижения окончательности в Ethereum измеряется минутами, а не миллисекундами: фиксированные временные слоты для создания блоков, массовая агрегация подписей от десятков тысяч валидаторов, компоненты окончательности накладываются на правила выбора ветки, а не являются единой BFT-цепочкой (Byzantine Fault Tolerance). Это не является недостатком дизайна, а представляет собой разумный компромисс – приоритет отдается максимальному вовлечению валидаторов и устойчивости к цензуре, а не низкой задержке. HotShot имеет контролируемое количество валидаторов, основанное на механизме залога, и изначально предназначен для быстрого достижения окончательности данных, что представляет собой другой подход.

CometBFT (публичный блокчейн-движок консенсуса, основанный на Tendermint)

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

Конечные преимущества: сверхбыстрая окончательность, неизменная безопасность

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

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