Распакоука нового поколения Ethereum L2 (III): Нативные Rollups

Перевод

За последние два года Ethereum полностью принял стратегию "rollup-centric", сосредоточившись на масштабировании через rollups. Этот подход включает:

Блокировку ETH в бридж-контрактах.
Выполнение транзакций off-chain.
Использование доказательств — fraud proofs или zero-knowledge proofs (ZKPs) — для проверки состояния Layer 2 (L2) и обработки выводов средств.

Однако существует серьёзная проблема: Ethereum не поддерживает нативную валидацию исполнения EVM, из-за чего rollups вынуждены самостоятельно разрабатывать и внедрять собственные системы доказательств на уровне L1 для подтверждения переходов состояния.

Кроме того, Ethereum регулярно проходит хардфорки, изменяя архитектуру EVM. Это означает, что команды rollups должны самостоятельно поддерживать и обновлять свои кастомные реализации, что часто требует:

Создания совета безопасности.
Внедрения системы голосования на основе токенов для управления обновлениями бридж-контрактов и механизмов доказательств.

В предыдущих статьях мы уже рассматривали based rollups и booster rollups. Теперь мы углубимся в концепцию нативных rollups.

Based, Booster, Native… В чём разница?

Существует большая путаница в определениях based rollups, booster rollups и native rollups. В предыдущих выпусках мы уже рассмотрели based rollups и booster rollups, поэтому перед прочтением этой статьи рекомендуется ознакомиться с ними. Однако здесь мы быстро напомним основные различия между этими тремя типами.

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

Booster Rollups масштабируют выполнение и хранение, имитируя обработку L1 на L2, что позволяет приложениям расти без необходимости повторного развертывания. Хотя этот подход обеспечивает масштабируемость, он добавляет дополнительную сложность по сравнению с традиционными rollups, требуя более сложной инженерной работы для разработки и поддержки.

Native Rollups используют собственную функцию перехода состояния L1 (STF) в прикладном слое в качестве верификатора для переходов состояния. Однако, несмотря на то, что Optimism, Arbitrum и другие rollups работают в EVM-эквивалентных средах, они часто включают пользовательские модификации, которые могут быть сложными или даже невозможными для реализации непосредственно в Ethereum.

Ранее native rollups были известны как enshrined rollups, и они подробно обсуждались в различных статьях. Также термин "canonical rollup" кратко использовался @apolynya. Однако в конечном итоге "enshrined" был заменён на "native", чтобы подчеркнуть, что существующие EVM-эквивалентные rollups могут потенциально обновиться до этой модели. Термин "native" был предложен @danrobinson и анонимным участником сообщества Lido.

Как работают нативные rollups?

Концепция нативных rollups предполагает введение EXECUTE precompile — специальной предкомпиляции, которая будет выполнять роль верификатора переходов состояния rollup'ов.

🔹 Что это даёт? Rollup-команды смогут использовать EXECUTE precompile внутри своих контрактов верификаторов, что позволит им:

Базировать proof-системы на встроенной валидации Ethereum.
Наследовать механизм проверки Ethereum без необходимости разрабатывать кастомные схемы.

Поскольку этот механизм напоминает концепцию "EVM в EVM", его обновления будут синхронизироваться с хардфорками Ethereum, проходя через процесс социального консенсуса. Это значит, что любые изменения в EVM автоматически отразятся в EXECUTE precompile, позволяя rollup'ам:

✅ Использовать нативную валидацию Ethereum.
✅ Избавиться от сложного управления (без мультисигов, советов безопасности и токеновых голосований).
✅ Повысить уровень безопасности для пользователей.

Как работает EXECUTE precompile?

🔹 Функция: верифицирует переходы состояния EVM для rollup'ов, используя нативную инфраструктуру Ethereum на уровне приложения.
🔹 Валидация осуществляется через:

pre_state_root (корневое состояние до транзакции).
post_state_root (корневое состояние после транзакции).
trace (трассировка выполнения).
gas_used (использованный газ).
🔹 Опирается на EIP-1559-подобный механизм ценообразования газа.

Rollup-валидаторы могут гарантировать корректность переходов состояния двумя способами:

Переисполняя транзакции (re-execution).
Используя SNARK-доказательства, если rollup требует большей масштабируемости.

Для снижения рисков централизации (например, конкуренции за MEV-доказательства) внедряется задержка в один слот.

Как это улучшает rollups?

🔹 Облегчает разработку за счёт trustless-proof-систем.
🔹 Возможность построения “ультразвуковых rollups” (если использовать вместе с based rollup-дизайном, где и упорядочивание, и доказательства обрабатываются внутри Ethereum).
🔹 Улучшает композиционность (возможен real-time settlement).
🔹 Стимулирует создание более безопасных rollup-архитектур.

Предлагаемая предкомпиляция ведёт себя аналогично EVM, повторно исполняя rollup-транзакции для проверки их корректности. Однако это противоречит ключевому преимуществу rollups — их off-chain выполнению с отправкой в Ethereum только доказательств корректности.

По сути, precompile дублирует механизм Ethereum, не разгружая L1 от вычислительной нагрузки.

Почему выбран EVM-подобный верификатор, а не zk-верификатор?

Причина в незрелости ZK-технологии.

Даже широко используемые zkVMs демонстрируют уязвимости.
Технология ZKP развивается слишком быстро, и жёсткое закрепление конкретных zk-верификаторов на уровне Ethereum несёт риски и ограничивает гибкость.

Ethereum делает ставку на разнообразие и нейтральность, позволяя экспериментировать с разными zk-клиентами без привязки к единому верификатору.

Но это не означает, что precompile бесполезен.

🔹 Ethereum оставляет zk-верификаторы off-chain ради безопасности, но использует precompile для проверки zk-доказательств, отправленных rollups.
🔹 Вместо полной эмуляции всех rollup-транзакций, Ethereum проверяет zk-proofs, сохраняя гарантии безопасности и стремясь к масштабируемости исполнения.

Какие преимущества у нативных rollups?

1️⃣ Упрощение кода и разработки

Fraud proofs и SNARK-проверки становятся проще.
Меньше кода = меньше багов.
Не нужны отдельные proving-сети или security-советы.

2️⃣ Снижение затрат на верификацию

Верификация SNARK'ов on-chain дорога, поэтому zk-rollups реже фиксируют транзакции, экономя на комиссии.
EXECUTE precompile снижает затраты, объединяя несколько доказательств с помощью SNARK-рекурсии.
Rollups смогут верифицировать транзакции эффективнее, удешевляя off-chain проверки.

3️⃣ Более безопасный и permissionless sequencing

Классические rollups часто используют централизованный sequencing для предотвращения атак.
Нативное исполнение через precompile позволяет создать более безопасный и децентрализованный sequencing.
Rollups смогут унаследовать не только безопасность L1, но и его ликвидность, так как транзакции валидируются внутри Ethereum.

4️⃣ Автоматическая синхронизация с Ethereum

Многие rollups совместимы с EVM, но почти ни один не является EVM-эквивалентным.
Обновления в Ethereum часто требуют голосования или ручного обновления rollups, что создаёт риски.
Нативные rollups обновляются автоматически вместе с Ethereum, устраняя необходимость в governance.

5️⃣ Снижение давления на ZK-доказательства

Достижение ультранизкой задержки доказательств (100 мс) — сложная инженерная задача.
В нативных rollups можно расширить время формирования доказательства до одного слота, снизив нагрузку.
Это улучшает надёжность и интеграцию с L1.

Станут ли все rollups нативными?

Все существующие rollup-стэки, такие как OP Stack и Arbitrum Orbit Stack, потенциально могут стать нативными rollups, унаследовав безопасность Ethereum напрямую.

Этот переход принесёт двойную выгоду:

Пользователям — более высокий уровень безопасности.
Командам rollup'ов — отсутствие необходимости управлять security-советами.

При этом команды rollup'ов смогут конкурировать в создании эффективных слоев упорядочивания транзакций, продолжая зарабатывать на комиссиях sequencer'ов и MEV.

Однако не все rollups перейдут на нативную модель.

Какие rollups несовместимы с нативным подходом?

Некоторые функции L2 несовместимы с нативными rollups, например:

Уникальные типы транзакций.
Отличные методы расчёта газа.
Предкомпиляции, отсутствующие в основной сети Ethereum.

Разнообразие виртуальных машин (VMs) среди L2 rollups делает экосистему Ethereum более гибкой. Например:

@EclipseFND использует SVM rollup.
@movementlabsxyz использует MoveVM rollup.
@Starknet использует CairoVM rollup.

Три категории rollups в будущем

По мнению @doganeth_en, будущие rollups разделятся на три типа:

1️⃣ Enterprise rollups

Ориентированы на корпоративное управление, секвенирование и владение инфраструктурой.
Идеальны для компаний, желающих Web2-подход к контролю за порядком транзакций и выполнением операций.

2️⃣ Производительные rollups

Используют settlement в Ethereum, но альтернативные решения для доступности данных (DA), например:

@megaeth_labs, использующий @eigen_da.

Менее децентрализованные, но повышают полезность $ETH, жертвуя частью функций Ethereum.

3️⃣ Нативные rollups

Полностью интегрированы с инфраструктурой Ethereum.
Обеспечивают:

Уровень децентрализации Ethereum.
Общее исполнение с прямым доступом к состоянию.
Дешёвую верификацию ZK-доказательств off-chain.

Поддерживают экономику Ethereum и могут разделять доходы с L1, но их устойчивость зависит от рыночных стимулов.

Заключение

Нативные rollups — это ключевой шаг в rollup-ориентированной стратегии Ethereum.

Введение EXECUTE precompile упрощает управление rollup'ами, устраняя:

Мультисиги.
Security-советы.
Голосования на основе токенов.

Это не только повышает безопасность, но и улучшает масштабируемость за счёт офчейн ZK-доказательств, сочетая минимизацию доверия и масштабируемость.

Тем не менее, переход к нативной модели может стать сложным для rollup'ов с кастомизированными версиями EVM.

Но в целом нативные rollups позволяют объединить безопасность Ethereum с гибкостью rollup-дизайна, снижая фрагментацию и делая экосистему более целостной и устойчивой.

Не пропустите части I и II нашей серии Rollups 2.0, посвящённые based и booster rollups.

В следующем выпуске мы рассмотрим gigagas rollups и их потенциал для нового уровня масштабируемости Ethereum. 🚀