Компромиссы моделей консенсуса для интероперабельности: PoW, PoS, DPoS и BFT в безопасности кроссчейн-мостов

Более 2,3 миллиарда долларов было выведено из кросс-чейн мостов только в первой половине 2025 года — это уже превышает общий показатель за весь 2024 год. В то время как большая часть дискуссий в индустрии сосредоточена на аудитах смарт-контрактов и управлении ключами мультисигов, часто остается незамеченной менее обсуждаемая, но столь же критическая уязвимость: несоответствие между тем, как различные блокчейны достигают консенсуса, и тем, как мосты предполагают, что они это делают.

Каждый кросс-чейн мост делает неявные предположения о финализации. Когда эти предположения сталкиваются с реальной моделью консенсуса исходной сети или сети назначения, злоумышленники находят окна для эксплуатации. Понимание различий между механизмами консенсуса PoW, PoS, DPoS и BFT — и того, как эти различия каскадно влияют на выбор архитектуры моста и протокола обмена сообщениями — является одной из самых важных тем в инфраструктуре Web3 на сегодняшний день.

Что на самом деле означает финализация для мостов

Прежде чем сравнивать типы консенсуса, полезно четко определить, что именно мостам нужно от уровня консенсуса сети: финализация (finality) — гарантия того, что подтвержденная транзакция не может быть отменена.

Финализация бывает двух видов:

• Вероятностная финализация: Транзакция становится более безопасной со временем по мере добавления новых блоков поверх нее, но необратимость никогда не является математически абсолютной. Биткоин — канонический пример.
• Детерминированная (мгновенная) финализация: Как только блок зафиксирован квалифицированным большинством валидаторов, он не может быть отменен. Большинство сетей на базе BFT предлагают такую гарантию.

Для мостов это различие огромно. Мост, который считает депозит в Биткоине подтвержденным после шести блоков, делает вероятностную ставку. Мост, подтверждающий перевод Cosmos IBC после фиксации одного блока, полагается на детерминированные гарантии, заложенные в движок консенсуса CometBFT.

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

PoW: Глубокая безопасность, медленная финализация, неудобство для мостов

Сети Proof-of-Work, такие как Биткоин, обеспечивают исключительную устойчивость к атаке Сивиллы и проверенную временем безопасность на базовом уровне. Стоимость атаки 51% на Биткоин огромна — по оценкам, она составляет миллиарды долларов в час при текущих скоростях хеширования — что делает глубокие реорганизации блоков экономически нецелесообразными.

Но эта безопасность обходится дорого для разработчиков мостов:

• Только вероятностная финализация: Не существует жесткого порога, после которого блок Биткоина считается «финальным». Шесть подтверждений (~60 минут) — это конвенция, а не протокол.
• Медленное время блока: Среднее время блока Биткоина в 10 минут означает, что мосты должны либо ждать час, либо принимать риск отмены.
• Окно реорганизации: Любой мост, обрабатывающий депозиты до глубокого подтверждения, уязвим для атак двойной траты через реорганизацию блокчейна.

Реальная опасность возникает, когда PoW-сеть со слабой мощностью хеширования (не Биткоин, а более мелкие PoW-сети) подключается к высоколиквидной экосистеме DeFi. Ethereum Classic подвергся атаке 51% в 2020 году, и любой мост, считавший депозиты ETC финальными слишком быстро, мог быть использован для кражи средств в тот момент.

Подходящий протокол обмена сообщениями: Поскольку в PoW-сетях отсутствует поддержка легких клиентов для эффективной проверки доказательств, мосты, подключающиеся к ним, обычно полагаются на внешних валидаторов или комитеты оракулов, а не на криптографические доказательства финализации. Здесь лучше подходят такие протоколы, как Axelar (сеть валидаторов, защищенная DPoS) и модель Oracle+Relayer от LayerZero, чем мосты на базе легких клиентов в стиле IBC, так как последние требуют мгновенной финализации исходной сети для эффективной работы.

PoS: Улучшенная финализация, но сложность чекпоинтов

Переход Ethereum на Proof-of-Stake принес значительные улучшения в архитектуру кросс-чейн мостов. Уровень консенсуса Ethereum использует комбинацию выбора форка LMD-GHOST и финализации Casper FFG, что обеспечивает экономическую финализацию каждые две эпохи (~12,8 минуты).

Для мостов это существенное улучшение по сравнению с Биткоином:

• Финализированные чекпоинты криптографически подтверждаются квалифицированным большинством застейканных ETH.
• Реорганизация после финализированного чекпоинта потребует слэшинга более трети всех застейканных ETH — на данный момент это десятки миллиардов долларов.
• Легкие клиенты могут проверять подписи Комитета синхронизации (Sync Committee) Ethereum, что позволяет создавать более бездоверительные (trustless) конструкции мостов.

Однако PoS привносит свои сложности:

• Ротация набора валидаторов: Легкие клиенты моста должны отслеживать изменения в наборе валидаторов. Устаревший легкий клиент может принять доказательства, подписанные набором валидаторов, который больше не существует.
• Слэшинг не является мгновенным наказанием: Экономические штрафы сдерживают атаки, но не предотвращают их полностью в коротком окне до финализации.
• Чекпоинты финализации создают задержку: Мосты, ожидающие финализации Casper FFG, добавляют 12–13 минут к времени кросс-чейн транзакций — это приемлемо для крупных переводов, но неудобно для пользователей DeFi.

Подходящий протокол обмена сообщениями: Модель PoS Ethereum становится все более совместимой с конструкциями мостов на базе ZK-доказательств. Новые протоколы, такие как Telepathy от Succinct, используют ZK-SNARK для проверки подписей Sync Committee Ethereum в сети, что позволяет создавать мосты с минимизацией доверия и разумной задержкой. Поддержка DVN (децентрализованных сетей верификаторов) с ZK-доказательствами в LayerZero v2 также хорошо сочетается с PoS-сетями, которые предоставляют проверяемые криптографические доказательства состояния.

DPoS: Быстрый консенсус, риски набора валидаторов

Системы Delegated Proof-of-Stake (DPoS) — используемые EOS, BNB Chain и, что крайне важно, самой сетью валидаторов Axelar — внедряют уменьшенный, избранный набор валидаторов для достижения более быстрого консенсуса.

Преимущества DPoS для мостов:

• Быстрое время блока и почти мгновенная финальность: Имея от 21 до 101 активного валидатора, BNB Chain подтверждает блоки примерно за 3 секунды с практической финальностью в течение ~15 секунд.
• Предсказуемые наборы валидаторов: Мосты могут поддерживать более «легкие» доказательства, поскольку набор валидаторов меняется в рамках медленного цикла выборов.
• Более низкие вычислительные затраты: Меньшее количество валидаторов означает меньшее количество подписей для проверки.

Однако DPoS сужает поверхность атаки:

• Риск сговора: Квалифицированное большинство избранных делегатов — потенциально всего 11 из 21 в некоторых сетях — теоретически может вступить в сговор для подделки консенсуса. Атаки с подкупом голосов на выборах делегатов были задокументированы в EOS.
• Картельная динамика: На практике небольшое количество организаций часто контролирует несколько слотов делегатов, что снижает децентрализацию.
• Каскад компрометации ключей: Если мост полагается на набор валидаторов DPoS и несколько валидаторов будут скомпрометированы одновременно, безопасность моста рухнет вместе с базовой цепочкой.

Сеть Axelar является интересным примером: сама по себе она представляет собой DPoS-цепочку (построенную на Cosmos SDK с консенсусом CometBFT и более чем 75 активными валидаторами), которая служит хабом для передачи межсетевых сообщений. Безопасность каждого сообщения, передаваемого Axelar, в конечном итоге подкрепляется экономической безопасностью стейкинга AXL — осознанное проектное решение, которое делает модель безопасности моста явной и поддающейся количественной оценке.

Наиболее подходящий протокол обмена сообщениями: Цепочки DPoS естественно сочетаются с архитектурами интероперабельности типа «ступица и спицы» (hub-and-spoke), такими как Axelar, где специально созданный уровень консенсуса DPoS защищает межсетевые сообщения. Протоколы «точка-точка», такие как IBC, также могут работать, если DPoS-цепочка предоставляет совместимые интерфейсы легких клиентов, хотя меньший набор валидаторов означает, что порог криптографической безопасности ниже, чем в более децентрализованных сетях PoS.

BFT: Мгновенная финальность, нативная среда IBC

Консенсус Byzantine Fault Tolerant (BFT) — в частности CometBFT (ранее Tendermint), используемый во всей экосистеме Cosmos — является наиболее дружественной к мостам моделью консенсуса, находящейся сейчас в эксплуатации.

Гарантии BFT:

• Детерминированная, мгновенная финальность: Блок необратимо фиксируется в тот момент, когда его подписывает квалифицированное большинство (2/3+) валидаторов. Вероятностного периода ожидания не существует.
• Отсутствие форков по определению: При нормальных сетевых условиях цепочки BFT не разветвляются. Один подтвержденный блок является канонической цепочкой.
• Обнаружение ненадлежащего поведения (misbehavior detection): Протокол легкого клиента IBC включает в себя подачу доказательств ненадлежащего поведения — если набор валидаторов допускает двусмысленность (подписывает два конфликтующих блока), доказательство может быть представлено в сети, что замораживает легкий клиент для предотвращения дальнейшего ущерба.

Эти свойства — именно то, вокруг чего был разработан протокол Inter-Blockchain Communication (IBC). IBC минимизирует доверие (trust-minimized), потому что:

1. Он полагается на проверку заголовков встречной цепочки легким клиентом, а не на внешних валидаторов.
2. Детерминированная финальность BFT означает, что легкому клиенту никогда не нужно хеджироваться от реорганизаций (reorgs).
3. Здесь нет кастодианов, нет мультисигов — только криптографические доказательства включения в состояние.

IBC v2, запущенный в марте 2025 года, расширяет эту модель на Ethereum, используя ZK-доказательства, чтобы сделать контрольные точки финальности PoS в Ethereum проверяемыми в контексте легкого клиента IBC. Это знаковое событие: нативная модель доверия BFT адаптируется для охвата цепочек PoS, значительно расширяя поверхность безопасности IBC.

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

Наиболее подходящий протокол обмена сообщениями: IBC является каноническим выбором для BFT-цепочек и золотым стандартом межсетевого взаимодействия с минимальным доверием. Hyperlane также хорошо подходит здесь: его модули межсетевой безопасности (ISMs) могут быть настроены для прямой проверки состояния BFT-цепочки, а модель ретранслятора без разрешений (permissionless relayer) означает, что любой может управлять инфраструктурой для передачи сообщений между BFT-сетями.

Сопоставление протоколов обмена сообщениями с типами консенсуса

Ниже приведена практическая структура для выбора протокола обмена сообщениями на основе типов консенсуса подключенных цепочек:

LayerZero v2 работает практически с любой цепочкой, но требует тщательной настройки DVN. Его модульный стек безопасности, в котором разработчики приложений сами выбирают, какие децентрализованные сети верификаторов (Decentralized Verifier Networks) подтверждают их сообщения, делает его агностичным к блокчейнам (chain-agnostic) за счет перекладывания решений по безопасности на разработчиков. Лучше всего подходит для гетерогенных сред, где нет единой доминирующей модели финальности.

Axelar специально создан для цепочек, где приемлема внешняя экономическая безопасность. Его сеть валидаторов DPoS напрямую обрабатывает несоответствие консенсусов: валидаторы Axelar наблюдают за финальностью исходной цепочки (как бы эта цепочка её ни определяла) перед ретрансляцией сообщений. Это делает его универсальным, но вводит собственный набор валидаторов Axelar в качестве допущения о доверии. Лучше всего подходит для подключения цепочек PoW или PoS к более широкой экосистеме.

IBC — вариант с минимальным уровнем доверия, но он требует, чтобы исходные цепочки имели быструю детерминированную финальность и совместимые реализации легких клиентов. С расширением поддержки Ethereum в IBC v2 его охват растет. Лучше всего подходит для соединений BFT-to-BFT и, во все большей степени, для соединений BFT-to-PoS через ZK-мосты.

Hyperlane предлагает максимальную гибкость для разработчиков благодаря настраиваемым ISM. Команды могут выбрать мультисиг ISM (на основе комитета, аналогично модели Axelar) или ZK-легкий клиент ISM (аналогично IBC) в зависимости от типа консенсуса исходной цепочки. Лучше всего подходит для команд, создающих суверенные роллапы или прикладные цепочки (appchains), которым необходимо определить собственные параметры безопасности.

Chainlink CCIP полагается на децентрализованную сеть оракулов (DON) Chainlink для верификации межсетевых сообщений, что делает его относительно агностичным к консенсусу. Лучше всего подходит для корпоративных приложений и протоколов DeFi, уже использующих ценовые потоки Chainlink, где важны простота интеграции и доверие к бренду.

Скрытые издержки несоответствия финализации

Взломы мостов, определившие эпоху 2022–2024 годов — Ronin ($625 млн), Wormhole ($320 млн), Nomad ($190 млн) — имели общую черту: в каждом из них были сделаны опасные предположения о финализации транзакций в подключенных сетях.

Валидаторы Ronin подтверждали депозиты до того, как наступила адекватная ончейн-финализация. Окно защиты от мошенничества (fraud-proof window) Nomad не учитывало риск реорганизации в подключенных сетях. Это были не просто ошибки в смарт-контрактах — это были архитектурные несоответствия между моделями финализации.

Поскольку индустрия переваривает убытки в размере более $2,3 миллиарда за первую половину 2025 года, урок очевиден: безопасность моста зависит не только от того, сколько аудиторов проверили контракт. Речь идет о том, соответствуют ли предположения о финализации моста фактическим гарантиям каждой подключенной сети — включая самое слабое звено в цепочке.

Взгляд в будущее: ZK-доказательства как универсальный адаптер

Самым захватывающим событием в области безопасности мостов является появление легких клиентов на базе ZK-доказательств в качестве уровня верификации финализации, не зависящего от консенсуса. Такие проекты, как Succinct Labs, Polyhedra и инициатива IBC v2, создают ZK-схемы, которые могут проверять подписи чекпоинтов PoS, наборы валидаторов BFT и даже заголовки блоков PoW — и всё это внутри ончейн-смарт-контрактов.

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

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

---

BlockEden.xyz предоставляет инфраструктуру узлов корпоративного уровня и API-сервисы для более чем 27 блокчейн-сетей, включая Sui, Aptos, Ethereum и сети Cosmos. Независимо от того, создаете ли вы кроссчейн-приложение или нуждаетесь в надежном RPC-доступе для инфраструктуры моста, изучите наш маркетплейс API, чтобы строить на фундаменте, разработанном для промышленной надежности.