Smart-contract rollup хранит правила принятия L2-состояния в специальных контрактах Ethereum. Один проект разворачивает verifier для ZK-доказательств, другой – dispute protocol для fraud proofs, третий добавляет собственную виртуальную машину и комитет обновлений. Ethereum исполняет эти контракты, но не предоставляет им единую встроенную функцию проверки обычного Ethereum-исполнения.
Native rollup – исследовательская модель, в которой базовый протокол Ethereum предоставляет стандартизированную функцию проверки изменения состояния. Draft EIP-8079 предлагает precompile EXECUTE: rollup передаёт ему данные перехода состояния, а инфраструктура L1 подтверждает, что результат соответствует правилам Ethereum. На сентябрь 2026 года это проект спецификации, а не доступная функция mainnet.
Как работает нынешний smart-contract rollup
У rollup есть контракт или набор контрактов в Ethereum. Они хранят принятые корни состояния, обрабатывают депозиты и выводы, проверяют доказательства и определяют, кто может предложить новый блок. Пользователь доверяет коду этих контрактов и правилам их обновления.
В ZK-rollup внешний prover исполняет пакет и создаёт криптографическое доказательство. Специализированный verifier contract проверяет доказательство и принимает новый корень. В optimistic rollup результат считается допустимым, пока участник не оспорит его и не докажет ошибку через интерактивную игру или одноступенчатую проверку.
Оба варианта способны наследовать безопасность Ethereum, но требуют отдельной реализации. Ошибка verifier, dispute game, bridge или upgrade-механизма становится ошибкой конкретного L2. Этапы от быстрого подтверждения до расчёта разобраны в статье о финальности Ethereum L2.
Что предлагает EXECUTE precompile
EIP-8079 предлагает открыть функцию изменения состояния Ethereum как встроенный precompile. Упрощённо вызов получает описание цепочки, блок и anchor, проверяет допустимость перехода и возвращает новый результат. Rollup может использовать его вместо собственного verifier для стандартного Ethereum-исполнения.
Проверка становится частью клиентского протокола L1. Все валидаторы Ethereum должны одинаково понимать EXECUTE, учитывать его стоимость и отвергать L1-блок с неверным результатом. Это похоже на общее встроенное оборудование вместо уникальной проверочной машины в каждом контракте.
Точная реализация ещё не завершена. В draft остаются параметры без окончательных значений, а вариант proof-carrying transactions зависит от будущего дизайна ZK L1. Поэтому нельзя обещать конкретную цену, лимит, срок внедрения или форму доказательства.
Почему такой rollup называют native
Название относится к верификации исполнения: L2 повторно использует нативные правила и проверяющую инфраструктуру Ethereum. Если rollup следует той же функции изменения состояния EVM, ему не нужно поддерживать отдельную криптографическую схему для доказательства каждого обновления этих правил.
Это не означает, что L2 становится частью состояния Ethereum наравне с обычным аккаунтом. У rollup остаётся собственный state root, история блоков, газовая экономика, мост и набор пользователей. Транзакции по-прежнему пакетируются, а данные должны быть доступны для восстановления.
Слово native также не гарантирует отсутствие управляющих ключей. Контракт вокруг EXECUTE может определять допустимого proposer, паузу, газовый токен, anchor, сбор комиссии и правила обновления. Проверяется стандартный переход EVM, но политика цепочки остаётся программируемой.
Что упрощается по сравнению с контрактным rollup
Единая проверка. Rollups не обязаны создавать отдельный verifier для одной и той же версии Ethereum-исполнения. Сокращается объём уникального кода и поверхность ошибок.
Обновления EVM. При корректном дизайне L2 может следовать обновлениям функции изменения состояния вместе с Ethereum, а не ждать нового proof circuit, аудита verifier и управленческого решения. Это уменьшает период, когда L2 отстаёт от L1.
Клиентское разнообразие. Результат проверяют разные реализации Ethereum-клиентов, а не только один L2-клиент или одна prover-система. Независимые реализации способны обнаруживать расхождения.
Инфраструктура проекта. Команда может меньше ресурсов тратить на поддержку доказательства эквивалентной EVM и больше – на интерфейс, sequencing, данные и приложения.
Какие ограничения появляются
Стандартизация работает лучше всего для эквивалентного Ethereum-исполнения. Собственные opcodes, precompiles и типы транзакций могут не поддерживаться общей функцией. Чем сильнее L2 изменяет EVM, тем больше ему требуется отдельный путь проверки.
EIP допускает программируемую оболочку. Например, контракт может ограничить proposer, выбрать based sequencing или отдельную сеть sequencers, задать gas limit и направить base fee в казначейство. Но произвольная логика внутри каждой L2-транзакции уже не обязана совпадать со стандартной функцией изменения состояния.
Проект может сочетать два пути: обычное EVM-исполнение проверять нативно, а специальные операции – собственным verifier. Это сохраняет гибкость, но возвращает часть сложности и создаёт границу между двумя режимами.
Re-execution и ZK-проверка
Простейшая модель заставляет валидаторов L1 повторно исполнить предоставленный trace. Она даёт прямую проверку, но конкурирует за вычислительный ресурс Ethereum. Если многие rollups попытаются нативно проверить большие пакеты, протоколу понадобится отдельное ценообразование и общий лимит.
Другой путь – proof-carrying transaction, где отправитель прикладывает доказательство, а L1 проверяет его дешевле полного повторного исполнения. Для этого Ethereum должен иметь подходящую встроенную ZK-инфраструктуру. В EIP этот раздел пока зависит от будущего дизайна.
Native rollup поэтому не является синонимом ZK-rollup. Он может использовать нативную проверку в optimistic споре, прямое повторное исполнение или будущую ZK-схему. Optimistic и ZK описывают способ доказательства, native – место и стандарт проверки функции изменения состояния.
Native и based – разные свойства
Based rollup передаёт упорядочивание L2-блоков базовой сети. Native rollup передаёт базовому протоколу проверку стандартного исполнения. Один вопрос звучит «кто задаёт порядок», другой – «кто и по каким правилам проверяет результат».
Rollup может быть based, но проверять состояние собственным контрактом. Он также может использовать EXECUTE, сохраняя централизованный sequencer для быстрых подтверждений. Комбинация обоих свойств возможна, но не обязательна. Модель порядка подробно описана в статье о based rollup.
Данные и мост не становятся нативными автоматически
EXECUTE доказывает корректный переход только для предоставленного входа. Пользователям всё равно нужны исходные транзакции или данные, чтобы независимо восстановить состояние. Rollup должен публиковать их в Ethereum или явно принимать риск внешнего DA.
Мост остаётся контрактной системой, которая блокирует активы L1, создаёт представление L2 и обрабатывает вывод. Его сообщения, задержки, pause-функции и обновления не исчезают. Нативная проверка может упростить принятие state root, но не исправляет ошибку бизнес-логики моста.
Sequencer, mempool и preconfirmation также остаются отдельными. Быстрая подпись оператора не превращается в финальность только потому, что позднее состояние будет проверено через общий precompile.
Эквивалентность и обновления
Сильное преимущество native-подхода – возможность автоматически следовать EVM. Приложение получает новые правила Ethereum без длительного воспроизведения в другом zkEVM. Но автоматизм безопасен только при ясной привязке версии и достаточном времени для пользователей выйти перед несовместимым изменением.
Rollup с собственной виртуальной машиной может сознательно выбрать иной набор функций. Например, Type 1 zkEVM стремится к максимальной эквивалентности, но доказательная система всё равно остаётся отдельной. Практические компромиссы можно сопоставить с архитектурой Taiko и обзором zkEVM Linea.
Основные риски native rollup
- Незавершённая спецификация. EIP-8079 имеет статус draft, а ключевые параметры и тесты ещё формируются.
- Нагрузка на L1. Повторное исполнение L2-пакетов может увеличить требования к валидаторам Ethereum.
- Ценообразование. Слишком дешёвый EXECUTE создаёт DoS-риск, слишком дорогой делает модель неконкурентной.
- Общая ошибка. Баг в нативной функции способен одновременно затронуть много rollups.
- Ограничение кастомизации. Нестандартные opcodes и транзакции требуют отдельного verifier или отказа от полной нативности.
- Версионность. Автоматическое следование L1 может конфликтовать с приложениями и правилами governance L2.
- Сохраняющиеся контракты. Мост, политика proposer, газовый токен и admin-права остаются источниками ошибок.
- Данные и sequencing. Нативная проверка не гарантирует доступность данных, быстрое включение или отсутствие цензуры.
Итог
Smart-contract rollup самостоятельно реализует в Ethereum правила принятия своего состояния, включая verifier или dispute protocol. Native rollup предлагает вынести проверку стандартного Ethereum-исполнения в общий precompile L1. Это может сократить уникальный код, упростить обновления EVM и использовать разнообразие Ethereum-клиентов. Но EIP-8079 пока остаётся draft, а sequencing, данные, мост, governance и кастомная логика не исчезают. Native – это более встроенная верификация, а не автоматическая гарантия полной безопасности L2.
