Риски L2 — это специфический набор угроз и допущений безопасности, которые появляются при использовании Layer 2-решений поверх Ethereum.
На маркетинговых слайдах L2 часто описывают как «тот же Ethereum, но быстрее и дешевле». На практике модель доверия меняется: кроме безопасности L1, пользователю приходится учитывать риски:
- смарт-контрактов и архитектуры rollup’а;
- sequencer’ов и операторов L2;
- мостов между L1 и L2;
- конкретного типа rollup (optimistic vs ZK) и настроек протокола.
На этой странице — обзор ключевых категорий рисков L2 и то, как их читать в документации проектов.
Базовая модель доверия L2 над Ethereum
Классический L2-rollup опирается на Ethereum как на:
- слой консенсуса и финализации;
- место хранения данных (для rollup-режима);
- среду исполнения смарт-контрактов на L1, которые принимают доказательства и управляют состоянием L2.
При этом поверх L1 добавляются новые сущности:
- Sequencer — упорядочивает и исполняет транзакции в L2;
- Prover / Validity-система — в ZK-rollup’ах строит validity proof;
- Challenge-механизм — в optimistic-rollup’ах проверяет корректность состояния через fraud proofs;
- Мосты — контракты/сервисы, связывающие L1 и L2 (депозиты/выводы, сообщения).
Риски L2 — это, грубо говоря, риски всех этих новых слоёв, плюс взаимодействия между ними.
Риски смарт-контрактов и протокольной логики L2
Любой rollup — это набор смарт-контрактов на L1 и L2:
- контракты мостов;
- менеджеры состояния (state root, очереди вывести/депозитов);
- логика challenge- и proof-механизмов;
- вспомогательные модули (governance, апгрейды, лимиты и т.п.).
Ключевые моменты:
- Сложность логики.
Rollup — это не один контракт, а связка нескольких систем (мост, очередь, доказательства, админский слой). Чем она сложнее, тем больше атакующей поверхности.
- Апгрейдируемость.
Многие L2 имеют апгрейдируемые контракты:
- мультисиг или DAO может менять логику;
- возможен «admin override» для аварийных сценариев.
Это удобно для быстрого реагирования, но добавляет централизованный доверенный слой.
- Взаимодействие с DeFi.
Ошибки в контрактах rollup’а могут каскадно затронуть:
- мосты;
- DeFi-протоколы внутри L2;
- LST/LRT и другие деривативы, завязанные на L2.
При анализе конкретного L2 полезно смотреть:
- есть ли публичные аудиты ключевых контрактов;
- кто имеет право апгрейда и в каком режиме (мультисиг, DAO, timelock);
- есть ли «аварийная кнопка» паузы мостов и какие у неё ограничения.
Риски sequencer’а и операторов L2
Почти все L2 на ранних этапах имеют централизованный sequencer:
- это один (или небольшой набор) операторов, которые:
- принимают транзакции пользователей;
- упорядочивают их;
- формируют блоки L2;
- публикуют данные/доказательства на L1.
Отсюда вытекают риски:
- Централизация и цензура.
Один оператор может:
- задерживать транзакции;
- давать приоритет «своим» операциям (MEV);
- блокировать отдельные адреса или типы транзакций.
- Downtime и недоступность.
Если sequencer недоступен:
- L2 «замирает» для обычного пользователя;
- в идеале у пользователей остаётся «escape hatch» — возможность принудительно вывести средства через L1, но это не всегда удобно и быстро.
- MEV и порядок транзакций.
Централизованный sequencer по умолчанию «видит» все транзакции и может:
- делать фронт-ран и сэндвич-атаки;
- продавать приоритет/слоты.
При чтении документации L2 важно смотреть:
- есть ли планы и сроки децентрализации sequencer’а;
- реализованы ли механизмы «forced inclusion» (когда пользователь может заставить включить свою транзакцию через L1);
- как протокол относится к MEV и какие инструменты защиты/распределения предусмотрены.
Data Availability (DA) и validium-риски
Отдельный класс рисков связан с тем, где и как хранятся данные L2.
- Rollup-режим.
Все необходимые данные (или их достаточный минимум) публикуются на L1. Любой может восстановить состояние L2, даже если все узлы L2 исчезнут.
Риск DA в этом режиме сводится к:
- корректности внедрения схем сжатия;
- возможным багам в коде, работающем с blob-данными и т.п.
- Validium / off-chain DA.
Данные хранятся вне L1:
- у DA-комитета;
- в специализированных сетях;
- у централизованного провайдера.
При этом на L1 попадает только validity proof корректности перехода состояния. Если DA-слой не выдаёт данные, пользователи не могут восстановить состояние и доказать свои права.
Рисковый сценарий validium:
- оператор DA или большинство из них перестают публиковать данные;
- средства формально «есть», но пользователи не могут просчитать состояние и доказать его где-либо ещё.
При анализе L2 стоит понять:
- работает ли сеть как полноценный rollup или как validium / гибрид;
- кто контролирует DA-слой;
- есть ли механизмы выхода при отказе DA (например, принудительное закрытие с использованием последних доступных данных).
Риски мостов между L1 и L2
Даже если сам L2 формально безопасен, мосты могут быть слабым местом.
Ключевые типы мостов:
- Канонический мост rollup’а.
Это контракт/система, встроенная в архитектуру L2:
- депозиты переводят активы из L1 в L2;
- выводы оформляются через состояния rollup’а и подтверждаются на L1.
Риски:
- баги в логике;
- зависимость от админских ключей и апгрейдов;
- UX-задержки (особенно в optimistic-rollup’ах с challenge-периодом).
- Сторонние (3rd-party) мосты.
Они часто дают быстрый вывод, но:
- полагаются на собственные доверенные предположения (валидаторы, ликвидность провайдера, оракулы);
- могут иметь отдельные смарт-контрактные риски и устаревшие версии протокола;
- добавляют риск расхождения состояний между разными мостами и «обёртками» одного и того же актива.
Подробнее о мостах — в обзоре мостов Ethereum↔L2 и кросс-чейн мостах.
Специфические риски optimistic и ZK-rollup’ов
Риски зависят и от типа rollup (см. optimistic vs ZK-rollup’ы).
- Optimistic-rollup’ы (optimistic rollup):
- зависят от наблюдателей, которые должны успеть заметить и оспорить некорректное состояние;
- имеют challenge-период (обычно несколько дней), в течение которого:
- выводы могут считаться небезопасными;
- возможны споры и откаты;
- уязвимы к ошибкам/атакам в механизме fraud proof:
- если споры не работают или наблюдателей мало, некорректное состояние может закрепиться.
- ZK-rollup’ы (ZK-rollup):
- зависят от корректности cryptographic stack:
- схемы доказательств;
- реализаций prover/verifier;
- возможного trusted setup;
- часто требуют мощной инфраструктуры prover’ов, что в начале усиливает централизацию.
В обоих случаях нужно смотреть:
- публикуются ли спецификации proof/споров;
- есть ли независимые аудиты и формальные проверки;
- как протокол планирует эволюцию этих механизмов.
Пользовательские и UX-риски L2
С точки зрения конечного пользователя многие инциденты связаны не с «глубокими» багами, а с:
- ошибкой сети.
Отправка активов на:
- неправильный L2 (похожий RPC, такой же токен);
- неправильный мост или контракт.
- Фейковые токены и dApp.
В новые L2 быстро приходят:
- поддельные токены, имитирующие известные активы;
- сайты-клоны, использующие схожие интерфейсы.
- Газ и комиссии.
В разных L2 используются разные токены газа (ETH, собственные токены, gas-sponsorship-схемы). Ошибки в понимании:
- может вести к зависшим транзакциям;
- усложняет оценку реальной стоимости операций.
- Непрозрачный UX мостов.
Пользователь видит «быстрый вывод», но:
- не всегда понимает, что это сторонний мост;
- не знает, какие риски и комиссии он принимает.
Здесь основная защита — внимательность и проверка адресов/документации, но L2-проекты тоже несут ответственность за понятный UX и метки в интерфейсах.
Governance, апгрейды и «социальные» риски
Наконец, есть слой рисков, связанных не столько с кодом, сколько с управлением:
- Admin-ключи и мультисиги.
Кто может:
- менять параметры rollup’а;
- паузить мосты;
- выкатывать новый код без длительного timelock?
- DAO и голосования.
Если управление формально децентрализовано, но:
- голосующая власть сконцентрирована у команды/инвесторов;
- кворум низкий;
- нет прозрачных процедур — это всё равно уязвимость.
- Социальный слой и «L1 vs L2» при форках.
В стресс-сценариях (крупные инциденты, хардфорки, регуляторное давление) встаёт вопрос:
- чьи правила считать «каноническими»;
- кто принимает решение о «правильной» ветке L2;
- как это соотносится с социальным консенсусом Ethereum.
Чтение разделов «assumptions», «trust model», «governance» в документации L2 — важная часть оценки рисков наряду с аудиторскими отчётами.