Модель рисков L2 — это способ разложить безопасность любого Layer-2 над Ethereum на понятные блоки: кто управляет порядком транзакций, где хранятся данные, как устроены мосты, кто может менять протокол и что происходит в аварийном режиме.
Даже если L2 наследует безопасность Ethereum (ETH) на уровне теории, на практике каждая реализация добавляет свои допущения и точки отказа. Эта статья помогает структурировать риски и использовать единый чек-лист для оценки разных L2-роллапов.
Основные компоненты риска L2
Для любого L2-роллапа можно выделить несколько ключевых доменов риска:
- Секвенсер и порядок транзакций.
Кто упорядочивает транзакции, как устроены цензура, отказоустойчивость и MEV.
- Доступность данных (DA).
Где хранятся данные L2: в calldata Ethereum, блобах EIP-4844, внешнем DA-слое и насколько реально восстановить состояние (см. Data Availability).
- Доказательства корректности.
Как работают fraud/validity-proof’ы, есть ли trusted setup, как обновляются proving-системы.
- Мосты и интероперабельность.
Как устроены депозиты/выводы и кросс-чейн-маршруты (см. кросс-чейн мосты).
- Управление и апгрейды.
Кто может менять контракты L2, параметры, лимиты и что это значит для пользователей.
- Инфраструктура и UX.
RPC-узлы, обозреватели, кошельки, ошибки интеграций — всё, что влияет на практическую безопасность.
Ниже — краткий разбор каждого блока с вопросами, которые стоит задавать перед тем, как заносить ликвидность в L2.
Риск секвенсера
Секвенсер — сердце L2: он принимает транзакции, упорядочивает их и отправляет батчи в L1 или DA-слой. Основные риски:
- Централизация и цензура.
Если секвенсер один или их мало, он может:
- выбирать, какие транзакции включать, а какие игнорировать;
- отдавать приоритет своим операциям и партнёрам (MEV).
- Отказ и остановка.
Падение секвенсера = UX-катастрофа:
- транзакции не включаются;
- кошельки и dApp’ы «висят» в ожидании подтверждений.
- Манипуляции MEV.
Порядок транзакций можно оптимизировать в пользу секвенсера (сэндвич-атаки, арбитраж и т.д.). Это не всегда приводит к краже средств, но влияет на честность рынка.
Что снижает риск:
- планы перехода к децентрализованному секвенсингу или использованию shared sequencers;
- прозрачная политика MEV (например, через proposer-builder separation или аукционы);
- документированный механизм выхода при цензуре (escape hatch).
Полезные вопросы:
- Сколько у L2 секвенсеров сейчас и как ими управляют?
- Что происходит, если текущий оператор перестаёт работать или начинает цензурировать?
- Есть ли технически реализованный путь «пробить» транзакцию мимо секвенсера через L1?
Риск доступности данных (DA)
Даже самый честный секвенсер не спасёт, если данные L2 недоступны: пользователи не смогут проверить состояние и безопасно выйти. Варианты:
- Полные данные в Ethereum (calldata).
Наиболее надёжная, но дорогая модель: все данные L2 хранятся в основной цепи.
- Блобы данных EIP-4844 и danksharding.
Дешевле и масштабируемее за счёт специальных «блобов» (EIP-4844 и данктшардинг), KZG-коммитментов и выборочного доступа к данным (см. KZG-коммитменты).
- Внешние DA-слои.
Например, сторонний DA-чейн: данные L2 публикуются не в Ethereum, а в отдельном слое.
Риски:
- DA-атаки.
Данные не публикуются или публикуются частично — невозможно проверить доказательства и сделать честный выход.
- Изменение DA-политики.
Протокол без timelock может внезапно сменить DA-слой или параметры хранения.
- Композиционные риски.
При использовании внешнего DA безопасность L2 = безопасность Ethereum × безопасность DA-слоя.
Вопросы к L2:
- Где хранятся данные L2 и как долго они доступны?
- Что будет, если внешний DA-слой перестанет работать или изменит правила?
- Можно ли восстановить состояние только по данным, доступным в Ethereum?
Риски доказательств и протокола
Для роллапов критична корректность механизма доказательств:
- Optimistic-роллапы.
Риск в том, что:
- окно оспаривания недостаточно широкое;
- нет мотивированных участников, готовых подавать fraud-proof’ы;
- есть баги в логике проверки спорных доказательств.
- zk-роллапы.
Риски связаны с:
- ошибками в proving-системе или реализациях;
- trusted setup (если он есть) и его компрометацией;
- возможностью «тихих» апгрейдов proving-ключей.
Вопросы:
- Какой тип роллапа используется (optimistic, zk) и как устроены доказательства?
- Есть ли публичные аудиты proving-системы и контракта верификации в L1?
- Как обновляются ключи и параметры доказательств, какие timelock и процедуры?
Риски мостов и маршрутов ликвидности
Перевод в L2 почти всегда проходит через мост. Даже если сам L2 спроектирован хорошо, слабый мост создаёт отдельный слой риска (подробно в Bridge Risks):
- кастодиальные и мультисиг-мосты с высокой концентрацией средств;
- сложные k-хоп маршруты через несколько кросс-чейн мостов;
- слабый учёт обеспечения wrapped-активов.
Особенно важно различать:
- канонический мост L1↔конкретный L2;
- сторонние мосты и агрегаторы маршрутов;
- мосты в сайдчейны, которые называют себя L2, но по факту имеют другую модель безопасности (см. L2 vs сайдчейны).
Вопросы:
- Какой мост считается «официальным» для этого L2?
- Как устроен контроль над активами в мосте и какие лимиты действуют?
- Есть ли публичный учёт обеспечения wrapped-токенов и реакция на инциденты?
Риски управления и апгрейдов
Даже идеальный код можно сломать неудачным апгрейдом. Модель управления L2 и его контрактами в Ethereum — отдельный блок риска:
- Админ-ключи и мультисиги.
Кто может:
- менять логику протокола;
- переключать DA-слой;
- ставить мосты и L2 «на паузу»?
- Timelock.
Есть ли задержка между объявлением апгрейда и его активацией, чтобы пользователи успевали реагировать?
- Роли и разделение полномочий.
Разделены ли права на изменение параметров, апгрейд логики и доступ к казначейству?
Хорошей практикой считается прозрачная governance-модель, где крупные изменения видны заранее и сопровождаются аудитами.
Вопросы:
- Какой орган управляет протоколом (DAO, компания, гибрид)?
- Как выглядят полномочия и timelock на критичные изменения?
- Есть ли публичная история апгрейдов и разбор инцидентов?
Чек-лист оценки L2 для пользователя и команды dApp
Краткий набор вопросов, который можно использовать как чек-лист:
- Якорь в Ethereum.
Как именно L2 наследует безопасность Ethereum и можно ли восстановить состояние из данных L1?
- Секвенсер.
Сколько операторов, как устроена их смена и что происходит при отказе?
- DA-модель.
Где хранятся данные, какая роль у EIP-4844 и внешних DA-слоёв?
- Мосты.
Какой мост используется, как устроены лимиты, учёт обеспечения и реакция на инциденты?
- Апгрейды.
Кто и как быстро может менять протокол, есть ли timelock и публичные обсуждения?
- Документация по рискам.
Есть ли у проекта отдельный раздел, описывающий риски, сценарии отказа и процедуры для пользователей?
Для крупных сумм и системно важных интеграций (DeFi, стейкинг, инфраструктура) имеет смысл формально фиксировать ответы на эти вопросы и периодически пересматривать их, по мере развития L2 и появления новых функций (например, shared sequencers или новых DA-слоёв).