EVM-эквивалентность (EVM-equivalence) — это свойство сети (обычно L2-роллапа), при котором её исполнительная среда повторяет поведение EVM максимально точно на уровне байткода, опкодов, газа и предкомпилов. Идея в том, что клиент Ethereum L1 мог бы, по сути, выполнить блоки такой сети без изменений логики EVM.
Чаще всего термин используется в контексте L2: одни решения называют себя *EVM-compatible*, другие — *EVM-equivalent*. Для разработчиков и протоколов эта разница важна: от неё зависят переносимость кода, инструменты и тонкие детали безопасности.
Что такое EVM-эквивалентность
Под EVM-эквивалентностью обычно подразумевают:
- тот же набор опкодов и та же семантика их выполнения;
- те же правила по газу (стоимость опкодов, учёт памяти, storage, «тёплых»/«холодных» доступов);
- тот же набор предкомпилированных контрактов (precompiles) с тем же поведением и газ-формулами;
- такое же поведение по стеку, памяти, storage, ограничениям по глубине стека и рекурсии;
- предсказуемое соответствие полей блока/контекста (timestamp, basefee, chainid и т.д.).
Другими словами, байткод, который валиден и корректно работает на Ethereum L1, должен вести себя идентично на EVM-equivalent L2 (с учётом разницы в окружении: номер сети, адреса системных контрактов, параметры L2-специфичных протоколов).
EVM-equivalent vs EVM-compatible vs EVM-like
Обычно различают три уровня близости к EVM:
- EVM-equivalent
- цель — воспроизвести EVM «по жёлтой бумаге» (Yellow Paper);
- любой контракт, скомпилированный под Ethereum, работает без изменений;
- инструменты низкого уровня (дебаггеры, трейсеры, формальная верификация) могут использовать те же предположения, что и для L1.
- EVM-compatible
- сеть поддерживает Solidity / Vyper и большую часть экосистемы инструментов;
- но могут отличаться:
- набор precompiles;
- стоимость газа;
- поведение отдельных опкодов или ограничения;
- некоторые поля контекста;
- переносимость кода обычно высокая, но возможны “подводные камни” в оптимизациях и криптопротоколах.
- EVM-like / EVM-inspired
- архитектура напоминает EVM, но:
- другие типы транзакций;
- другие системные вызовы;
- нестандартные расширения (например, дополнительные регистры, параллельное исполнение, иной формат блоков);
- требуются более заметные изменения в инструментах и коде.
Маркетинг часто сглаживает грань между этими терминами, поэтому разработчику важно смотреть на конкретные детали реализации, а не только на словам «совместимый».
Почему EVM-эквивалентность важна для L2
Для L2-роллапов (см. обзор L2-rollups и Layer2) ставка на EVM-equivalence даёт несколько преимуществ:
- Максимальная совместимость с существующим стеком
Hardhat, Foundry, Truffle, OpenZeppelin, аудитные тулзы, формальные проверки — всё это можно использовать «как есть», без форков и костылей.
- Простота миграции протоколов
DeFi-, NFT-, инфраструктурные протоколы могут переносить свои контракты практически без переписывания логики и без глубокого ре-дизайна.
- Проще безопасность и аудит
Аудиторы уже знают поведение L1-EVM. Если L2 строго ему соответствует, меньше «сюрпризов» из-за необычной семантики или нестандартных precompiles.
- Прозрачность для пользователей и экосистемы
Если L2 ведёт себя как «ещё одна EVM-среда», пользователям и кошелькам проще поддерживать её наряду с другими сетями.
Требования к EVM-equivalent сети
Чтобы сеть можно было честно называть EVM-equivalent, она должна соблюсти ряд технических требований:
- Полное покрытие опкодов
Все стандартизованные опкоды должны:
- существовать;
- иметь ту же семантику (включая пограничные случаи и поведение при ошибках).
- Совместимая модель газа
Стоимость:
- арифметических операций;
- операций памяти (MLOAD/MSTORE и расширение памяти);
- операций storage (SLOAD/SSTORE, warm/cold доступы);
- precompiles
— должна соответствовать L1-модели, либо иметь документированные и предсказуемые отличия.
- Те же precompiles
Наличие и поведение предкомпилов (ecRecover, SHA256, RIPEMD160, alt_bn128, BLAKE2, KZG и т.д.) — критично для криптопротоколов. Любое отличие должно быть явно описано.
- Совместимая модель состояния и DA
Хотя слой Data Availability может быть реализован иначе (см. решения DA для L2), для контракта модель account-based и Merkle/PATRICIA-структуры должны выглядеть привычно.
- Предсказуемый контекст блока
Параметры block.timestamp, block.number, block.chainid, basefee, лимиты газа блока и прочие поля должны вести себя либо так же, как на L1, либо чётко документированно отличаться.
Зачем некоторым L2 достаточно EVM-совместимости, а не эквивалентности
Не все L2 стремятся к строгой эквивалентности. Причины:
- Оптимизация под zk-доказательства или высокую пропускную способность
Для zk-rollup’ов иногда выгодно слегка изменить семантику или добавить специальные precompiles, чтобы ускорить генерацию доказательств и снизить стоимость.
- Новые функции протокола
Некоторые сети вводят расширения:
- дополнительные системные контракты;
- новые типы транзакций;
- особые модели комиссий или приоритизации транзакций.
- Упрощение реализации
Строгая эквивалентность к полноценному L1-EVM может усложнять реализацию L2. В некоторых случаях разработчики выбирают «чуть упростить» EVM ради меньшей сложности кода.
Для dApp’а это означает, что:
- обычный Solidity-код, как правило, будет работать;
- но низкоуровневые допущения (о газе, precompiles, лимитах) нужно проверить отдельно.
На что смотреть разработчику при выборе L2
Если протокол завязан на детали EVM, полезно пройтись по чек-листу:
- Требуется ли строгая эквивалентность (например, для сложных DeFi-протоколов, формальной верификации, кастомных VM-интеграций)?
- Совпадают ли газ-модели с L1 или протокол чувствителен к стоимости отдельных операций?
- Используете ли вы специфические precompiles (pairing, KZG, BLAKE2) и как они реализованы в целевой сети?
- Есть ли отличия в контексте блока (например, упрощённый или синтетический block.timestamp)?
- Поддерживаются ли ваши любимые инструменты без форков или требуются адаптации?
Чем ближе сеть к EVM-equivalent, тем меньше «сюрпризов» при миграции и тем проще сопровождать код.