Безопасность L2-сетей на Ethereum во многом упирается не только в их внутреннюю архитектуру, но и в то, как устроены мосты между L1 и L2, а также кросс-чейн мосты между самими L2 и другими сетями. Ошибка в мосте, multisig или протоколе сообщений часто приводит к потерям средств даже при корректной работе самого роллапа.
Эта статья рассматривает архитектуру мостов L2↔L1, различие между canonical bridge и внешними мостами, ключевые векторы атак и то, как оценивать риски с точки зрения пользователя и разработчика.
Canonical bridge L2↔L1
Для каждого L2-роллапа обычно существует официальный (canonical) мост между Ethereum и этой сетью. Он привязан к протоколу L2 и является частью его доверенной базы.
Характерные черты canonical bridge:
- Контракты на L1 и L2 тесно связаны с самой архитектурой роллапа.
- Через него проходят основные операции:
- депозиты ETH и токенов из L1 в L2;
- вывод средств обратно в L1 (после периода ожидания и/или доказательства).
- Обновление логики моста часто подчиняется тем же правам апгрейда, что и остальной протокол L2:
- multisig команды/фонда;
- timelock и on-chain governance;
- в некоторых случаях — «аварийные» функции (emergency brake).
Примеры таких мостов есть у Arbitrum, Optimism, zkSync Era, Starknet и других сетей из хаба Layer-2 и роллапы на Ethereum.
С точки зрения безопасности:
- canonical bridge обычно максимально прозрачен и документирован;
- но его контракты и права апгрейда входят в основной trust assumptions для L2 (см. Риски использования L2).
Архитектура мостов в optimistic- и zk-rollup’ах
Архитектура моста зависит от того, на каком типе роллапа построена сеть.
Optimistic rollup
Для optimistic L2 (Arbitrum, Optimism и др.) важны:
- Inbox / Outbox.
- Inbox на L1 принимает сообщения (депозиты, вызовы) в L2.
- Outbox на L1 исполняет сообщения, исходящие из L2, после завершения окна челленджа.
- Окно челленджа.
- вывод средств занимает время (обычно несколько дней), чтобы любой участник мог подать fraud-proof;
- если доказано, что состояние L2 неверно, соответствующий batch/заявка могут быть отменены.
- Роль секвенсера.
- секвенсер L2 формирует батчи и публикует их в L1;
- поведение секвенсера и механизм его контроля напрямую влияют на работу моста.
Риски:
- уязвимости в логике exit’ов и диспутных игр;
- централизованный секвенсер может задерживать публикацию данных и тем самым влиять на возможность выхода.
Подробнее про архитектуру optimistic-роллапов см. Optimistic-роллапы: устройство и безопасность и Fraud-proofs и диспутные игры.
ZK-rollup
Для zk-rollup’ов (zkSync, Starknet, Scroll, Polygon zkEVM и др.) мост опирается на validity-proof:
- состояние L2 считается корректным, если к нему приложено корректное доказательство;
- bridge-контракт на L1 проверяет zk-доказательства перед тем, как разблокировать средства по выходу;
- нет длинного окна челленджа, но есть задержка на генерацию/верификацию proof.
Риски:
- ошибки в системе доказательств (SNARK/STARK), trusted setup, логике проверки proof’ов;
- критические баги в коде моста или агрегатора доказательств.
Подробнее см. Validity-proofs и zk-доказательства и ZK-rollup.
Внешние кросс-чейн мосты для L2
Помимо canonical bridge, для L2 существует множество внешних (third-party) мостов, которые:
- соединяют L2 с другими L2, L1 или альтернативными сетями (Solana, BNB Chain и др.);
- используют собственные модели доверия и проверки сообщений.
Типичные архитектуры:
- Lock-and-mint.
- активы блокируются в одной сети и выпускаются «обёртка» в другой;
- контроль за блокировкой/разблокировкой часто у multisig, сети валидаторов или оракулов.
- Liquidity networks.
- ликвидность держится в пулах, а не в контракте-блокировщике;
- перевод обеспечивается off-chain координацией наборов «маркет-мейкеров».
- Messaging-платформы.
- общий уровень сообщений (message bus) поверх разных сетей;
- мосты строятся как приложения поверх этого слоя.
Подробно архитектуры и риски внешних мостов описаны в Кросс-чейн мосты: принципы и угрозы и в терминологической статье Мосты между блокчейнами.
Ключевые риски безопасности мостов L2
Основные классы рисков, характерные для мостов L2↔L1 и кросс-чейн мостов:
- Ошибки в смарт-контрактах.
- уязвимости в логике депозита/вывода;
- некорректные проверки подписи, proof’ов или параметров;
- переполнения/недостатки в обработке пограничных случаев.
- Компрометация мультисигов и ключей апгрейда.
- если мост управляется мультисигом, захват большинства ключей даёт атакующему контроль над активами;
- такие ключи могут управлять апгрейдом контрактов (upgradeable proxy), что добавляет риск «злонамеренного обновления».
- Централизация секвенсера и операторов.
- для canonical bridge в optimistic-rollup’ах злоупотребление секвенсером или оператором может задерживать выход средств;
- в некоторых моделях операторы мостов могут «заморозить» транзакции или менять параметры без on-chain governance.
- Проблемы с data availability.
- если данные L2 недоступны (off-chain DA или validium), пользователи могут не иметь достаточно информации для безопасного выхода;
- это особенно критично для решений класса Validium и гибридных L2.
- Ошибки в логике сообщений.
- несогласованность состояний при сложных сценариях (мульти-хоп переводы, асинхронные сообщения);
- неправильная обработка отмен, возвратов и повторных сообщений.
Совокупность этих факторов подробно рассматривается в Рисках мостов между блокчейнами и интегрируется в общую модель рисков L2.
Как пользователю оценивать безопасность L2-моста
Несколько практических вопросов, которые имеет смысл задать при выборе моста:
- Это официальный canonical bridge роллапа или сторонний сервис?
- Кто контролирует апгрейды и критические функции:
- адреса multisig, timelock;
- публичная ли информация о ключевых участниках?
- Есть ли публичные аудиты контрактов моста и как давно они проводились?
- Как реализованы ограничения и лимиты:
- максимальный объём вывода/депозита;
- ежедневные лимиты, паузы при аномальной активности.
- Как устроен UX выхода:
- есть ли понятный интерфейс для отслеживания статуса;
- предупреждает ли dApp о времени ожидания и рисках.
Наличие официальной документации и прозрачных процессов апгрейда — важный индикатор зрелости протокола.
Как разработчику выбирать и интегрировать мосты
Если вы строите dApp на L2:
- Предпочитайте canonical bridge там, где это возможно, или крупные проверенные решения.
- Не «хардкодьте» единственный мост в архитектуру — оставляйте возможность переключения или поддержки нескольких вариантов.
- Следите за обновлениями протокола L2 и мостов:
- изменения контрактов;
- инциденты безопасности и меры, которые принял протокол.
- Информируйте пользователей:
- какой именно мост используется;
- какие есть ограничения, комиссии, время ожидания и риски.
Зрелая интеграция мостов — часть общей стратегии управления рисками для приложений на L2.