L1, L2, rollups и sidechains: где реально исполняется транзакция

Фраза «транзакция прошла в Ethereum L2» скрывает сразу несколько разных систем. Пользователь подписывает операцию в одной execution environment, sequencer может упорядочить её за миллисекунды, данные публикуются отдельно, а окончательная экономическая защита приходит только после того, как L1 принимает нужный batch, proof или dispute result. Поэтому L2 нельзя понимать как «Ethereum, только быстрее». Это отдельный протокол, который часть работы выносит за пределы L1, но пытается сохранить критические гарантии базового слоя.

L1 и L2 — это не просто два этажа одной программы

Layer 1 — базовая blockchain-система: consensus, validators, canonical history, data availability и правила финального settlement. Для Ethereum это Mainnet. Layer 2 — отдельный execution-протокол, который обрабатывает пользовательские операции вне L1 и затем привязывает результат к базовому слою.

Ключевой вопрос не «какая сеть быстрее», а какие функции выполняет каждый слой. Если вынести execution на L2, кто проверяет корректность state transition? Где лежат данные, необходимые независимому участнику? Кто может восстановить состояние, если sequencer исчез? Когда withdrawal становится окончательным на L1? Ответы на эти вопросы и определяют security model.

Три функции, которые полезно разделять

Удобно раскладывать архитектуру на execution, data availability и settlement. Execution отвечает за вычисление нового состояния. Data availability — за то, чтобы данные, необходимые для проверки или восстановления состояния, были доступны независимым участникам. Settlement — за окончательное разрешение спора и фиксацию результата в более защищённой системе.

• **Execution:** где выполняются EVM/opcodes и изменяется состояние L2.
• **Data availability:** где публикуются transaction data или данные, достаточные для восстановления rollup state.
• **Settlement:** где принимается proof, разрешается fraud dispute и закрепляется итоговый state root.

Почему эта декомпозиция важнее маркетингового TPS

Две сети могут показывать похожий throughput, но иметь совершенно разные assumptions. Одна публикует данные в Ethereum blobs и принимает proofs на Mainnet. Другая хранит данные у отдельного committee. Третья вообще имеет собственный validator set и лишь использует bridge к Ethereum. Число transactions per second не показывает эту разницу.

Rollup: execution вынесен, но проверяемость привязана к L1

Rollup выполняет пользовательские транзакции вне Ethereum Mainnet, собирает их в batches и публикует на L1 необходимые данные и commitments. Экономия возникает потому, что сотни или тысячи операций делят стоимость одной публикации и потому, что L1 не переисполняет каждую L2-транзакцию обычным способом.

Но слово «rollup» не означает, что L1 ничего не знает о происходящем. Наоборот, основная идея — оставить на базовом слое достаточно информации и логики, чтобы L2 не мог произвольно переписать состояние без обнаружения или отклонения.

Что делает sequencer

Sequencer принимает L2-transactions, задаёт их порядок и обычно быстро выдаёт пользователю предварительное подтверждение. В большинстве production rollups этот компонент пока намного более централизован, чем Ethereum validator set. Это важный operational trade-off: UX выигрывает в latency, но появляется отдельный субъект, который может остановиться, задерживать или цензурировать операции.

Sequencer не должен иметь право создавать валидный state transition из ничего. Его власть ограничивается протоколом: published batches, forced inclusion mechanisms, proof system и settlement contract определяют, сможет ли некорректный state стать окончательным.

Soft confirmation и L1 finality — разные вещи

Кошелёк может показать успех сразу после того, как sequencer принял transaction. Для UX это полезно, но такое подтверждение ещё не равно L1 settlement. Между ними может быть batch publication, proof generation, challenge period и включение соответствующей L1 transaction в finalized Ethereum history.

Чем быстрее выглядит интерфейс L2, тем важнее спрашивать: что именно уже произошло — sequencer acceptance, L2 block inclusion, data publication, proof verification или L1 finality?

Optimistic rollup: корректность предполагается, пока никто не доказал обратное

Optimistic rollup исполняет transactions offchain и публикует результаты и transaction data в Ethereum. Он не прикладывает validity proof к каждому batch. Вместо этого state update считается допустимым, если в установленное challenge window никто не предъявил корректное доказательство ошибки.

Это и есть «optimistic»: система оптимистично принимает offchain computation, но оставляет возможность оспорить ложный transition. Для этого независимому challenger нужны данные. Поэтому data availability — не второстепенная деталь, а часть fraud-proof security.

Fraud proof и challenge period

Если оператор опубликовал неправильный результат, другой участник может инициировать dispute. Конкретная механика зависит от протокола: single-round, interactive proof, fault-proof VM и другие конструкции. В конце L1 должен получить достаточно информации, чтобы определить, какой transition допустим.

Challenge period создаёт характерный withdrawal UX. Быстро получить «L2 success» можно почти сразу, но canonical withdrawal через native bridge может ждать до завершения dispute window. Liquidity providers способны ускорить пользовательский выход, но тогда пользователь меняет protocol delay на контрагентский/liquidity assumption.

Почему fraud proof бессилен без данных

Нельзя доказать неправильное execution, если честный участник не имеет transaction inputs или данных для восстановления state. Поэтому optimistic rollups публикуют данные в Ethereum calldata или blobs. Ethereum.org прямо подчёркивает: onchain data availability позволяет другим воспроизвести состояние и сформировать challenge.

ZK rollup: validity proof заменяет ожидание спора

ZK rollup тоже выполняет transactions вне Mainnet, но вместе с state update предоставляет cryptographic validity proof. L1 verifier проверяет доказательство того, что новый state получен корректным применением правил L2 к предыдущему состоянию.

Это принципиально другой security path. Вместо «считаем верным, пока не оспорено» используется «принимаем state transition после проверки proof». В результате нет того же challenge period для корректности computation.

Proof не означает, что все данные можно выбросить

Validity proof подтверждает корректность перехода, но пользователям всё ещё нужны данные, чтобы знать своё состояние, строить новые transactions и иметь возможность самостоятельно восстановить chain state. Поэтому классический ZK rollup публикует data availability на L1.

Если validity proof проверяется на Ethereum, а данные хранятся вне L1, архитектуру часто относят уже к validium-подобной модели. Computation correctness остаётся криптографически защищённой, но user exit и state reconstruction начинают зависеть от внешней доступности данных.

Почему ZK не всегда означает privacy

Термин zero-knowledge исторически связан с proofs, которые могут скрывать witness, но ZK rollup может использовать validity proofs просто для scalability и публиковать достаточно данных для прозрачного восстановления состояния. Поэтому «ZK = приватная сеть» — неверное упрощение.

Data availability: самый недооценённый слой rollup security

Пользователь может легко принять proof за всю безопасность системы. Но proof отвечает только на конкретный математический вопрос. Если state transition корректен, это ещё не означает, что данные доступны всем участникам для продолжения работы сети.

Ethereum после EIP-4844 предоставляет blob space, предназначенный прежде всего для L2 data. Rollup может публиковать compressed transaction data в blobs дешевле, чем постоянный calldata. Протокол Ethereum гарантирует доступность blob data в ограниченном окне, после чего долгосрочное хранение становится задачей экосистемы.

Calldata и blobs решают похожую задачу по-разному

Calldata становится частью обычной Ethereum history и остаётся доступной вместе с chain data. Blobs дешевле для rollups и имеют отдельный fee market, но не предназначены для вечного хранения внутри execution state. Для fraud-proof systems важно, чтобы challenge мог быть сформирован, пока data availability гарантирована protocol window.

Data availability committee меняет trust model

Если L2 публикует state commitments на Ethereum, но transaction data держит отдельный committee, пользователь получает более дешёвую публикацию, но дополнительную assumption. Committee может не суметь или отказаться раскрыть данные. Validity proof при этом способен доказать корректность уже принятого state, но не обязан решить проблему дальнейшего доступа к состоянию.

Sidechain — это не L2 в строгом смысле

Sidechain имеет собственный consensus и validator set. Она может быть соединена с Ethereum bridge, использовать EVM и даже выглядеть в кошельке почти так же, как rollup. Но её безопасность не наследуется автоматически от Ethereum validator set.

Если sidechain validators согласятся на некорректную историю по собственным правилам, Ethereum Mainnet обычно не имеет встроенного fraud/validity mechanism, который автоматически отклонит эту историю. Bridge contract может доверять signatures или multisig другого набора участников.

Rollup и sidechain различаются источником окончательной безопасности

Sidechain может быть быстрой и полезной, но называть её «такой же L2» только из-за bridge и EVM — значит скрыть главное: кто имеет право окончательно сказать, какой state правильный.

Bridge между L1 и L2 — часть security boundary

Чтобы актив оказался на rollup, L1 bridge contract обычно блокирует или учитывает актив на Ethereum, а L2 отражает соответствующий баланс. Обратный withdrawal должен доказать L1-contract, что пользователь имеет право получить актив обратно.

Для canonical bridge эта логика тесно связана с rollup settlement. Если bridge принимает state root, который прошёл предусмотренный proof/dispute process, он может выпускать средства по правилам протокола. Third-party bridge добавляет собственный trust layer: liquidity providers, multisig, message validators или отдельную verification system.

Forced inclusion и escape hatch

Если sequencer цензурирует пользователя, зрелый rollup design старается оставить путь через L1. Пользователь отправляет operation напрямую в contract или инициирует forced transaction/withdrawal mechanism. Конкретные детали различаются, но смысл один: sequencer не должен быть единственной точкой, способной навсегда запереть средства.

Почему наличие escape hatch нужно проверять на практике

Схема в whitepaper и production state могут отличаться. Механизм может существовать технически, но зависеть от paused contract, upgrade admin, proof system или ещё не активированного fault-proof component. Поэтому оценивать нужно фактическую версию contracts и governance, а не только архитектурный термин.

Финальность L2 — это timeline, а не один timestamp

Для обычного пользователя «финально» часто означает «можно продолжать работу в приложении». Для bridge operator — «можно безопасно выпустить актив на L1». Для protocol engineer — «L1 finalized block уже содержит accepted proof или необратимо завершённый dispute path».

Полезно мыслить стадиями:

1. Wallet подписал L2 transaction.
2. Sequencer принял и упорядочил её.
3. Transaction вошла в L2 block/batch.
4. Batch data/commitment опубликованы на L1.
5. Fraud window завершился или validity proof принят.
6. Соответствующая L1 transaction достигла требуемой finality.

Одна и та же transaction может быть «успешной» на стадии 2 для UI и всё ещё не подходить для крупного irreversible withdrawal на стадии 3.

Кто на самом деле может остановить L2

Rollup наследует часть безопасности Ethereum, но availability самого сервиса может зависеть от меньшего набора компонентов. Sequencer outage способен остановить нормальный UX. Prover outage может задержать ZK settlement. Fault-proof infrastructure может быть критична для optimistic dispute path. Upgrade keys могут менять contracts.

Поэтому security review L2 должен включать не только proof type. Нужно смотреть:

• сколько sequencers и как устроен failover;
• кто контролирует upgrade keys и emergency pause;
• где публикуется data availability;
• активны ли permissionless proofs/challenges;
• есть ли forced inclusion/withdrawal;
• как долго занимает canonical exit;
• зависит ли bridge от отдельного multisig или validator set.

Как читать L2 explorer без самообмана

L2 explorer показывает block number, transaction status, gas и contract events, но пользователь должен понимать, какой слой он наблюдает. L2 block number не равен Ethereum block number. L2 timestamp не доказывает, что batch уже опубликован в L1. «Success» означает успешное execution по правилам L2, а не завершившийся withdrawal settlement.

Хорошая проверка критичной transaction идёт в обе стороны: сначала L2 explorer подтверждает execution, затем L1 data/rollup explorer показывает batch, state root, proof или challenge status. Для крупного bridge transfer это гораздо информативнее одной зелёной галочки.

Где реально исполняется транзакция

В rollup пользовательская smart-contract transaction обычно исполняется в L2 VM, а не внутри Ethereum Mainnet EVM как обычная L1 transaction. Ethereum получает агрегированные commitments, data и proof/dispute-related messages. То есть L1 защищает результат не обязательно повторным execution каждой пользовательской операции, а проверкой более компактного protocol evidence.

Именно поэтому scaling работает: дорогое per-user execution вынесено, а L1 занимается consensus, DA и settlement для агрегированных результатов.

Что остаётся на L1

На L1 остаются rollup contracts, deposits/withdrawals, state commitments, proofs или dispute logic и опубликованные data/blobs. Там же существует окончательная база для bridge accounting и recovery mechanisms.

Что остаётся на L2

На L2 живут user accounts, contracts, local blocks, transaction ordering, execution receipts и application state. Для developer experience это может выглядеть как ещё одна EVM chain, но economic finality строится через связь с L1.

Главный вывод

L2 — не магический accelerator поверх Ethereum. Это архитектурное разделение обязанностей. Execution уходит в более дешёвую среду, data availability обеспечивает возможность независимой проверки и восстановления, а settlement возвращает спор или validity proof в базовый слой.

Optimistic rollup делает ставку на доступность данных и возможность доказать ошибку. ZK rollup делает ставку на validity proof, но всё равно нуждается в data availability для полноценной permissionless state reconstruction. Sidechain использует собственный consensus и поэтому имеет другой security root.

Пользователю полезнее всего перестать спрашивать только «сколько TPS у L2» и начать задавать четыре вопроса: где исполняется transaction, где лежат данные, кто может оспорить или доказать state transition и какой механизм позволяет забрать средства, если sequencer исчезнет.

FAQ

L2-транзакция выполняется на Ethereum Mainnet?

Обычно нет. User execution происходит в L2 VM. Ethereum получает data/commitments и проверяет fraud/fault proof или validity proof согласно architecture конкретного rollup.

Почему optimistic withdrawal может занимать дольше ZK withdrawal?

Optimistic design должен дать участникам время оспорить неправильный state update. ZK rollup может завершать correctness path после проверки validity proof, хотя реальная задержка всё равно зависит от batch/proof/L1 publication pipeline.

Sequencer может украсть средства?

В правильно спроектированном rollup sequencer не должен иметь возможность самостоятельно сделать invalid state окончательным. Но он может влиять на ordering, latency и censorship, а конкретные upgrade/bridge assumptions нужно проверять отдельно.

Sidechain и L2 — одно и то же?

Нет. Sidechain обычно имеет собственный validator consensus и не наследует Ethereum settlement security так же, как rollup. Bridge соединяет системы, но не превращает sidechain автоматически в rollup.

Что такое data availability простыми словами?

Это гарантия, что данные, необходимые для проверки и восстановления состояния, доступны независимым участникам. Без них proof/dispute system может оказаться недостаточной для permissionless recovery.

Почему L2 fee ниже, если данные всё равно публикуются в Ethereum?

Потому что много L2-transactions агрегируются, данные сжимаются и публикуются в более эффективной форме, включая blobs. Стоимость L1 publication делится между большим числом пользователей.

Материал носит образовательный характер и не является финансовой рекомендацией или торговым сигналом.