EVM — виртуальная машина Ethereum: детерминизм, байткод и газ

1) Что такое EVM простыми словами

EVM — это стековая (stack-based) машина, исполняющая байткод смарт-контрактов. Контракты компилируются из языков высокого уровня (чаще всего Solidity, реже Vyper, либо из промежуточного языка Yul) в набор инструкций (опкодов). Каждая инструкция стоит газ, а у транзакции есть лимит газа — он и ограничивает вычисления. Такой дизайн решает две задачи:

• предотвращает атаки типа «бесконечного цикла» — газ закончится;

• делает стоимость вычислений предсказуемой — каждая операция тарифицируется.

EVM — детерминирована и изолирована: она не может «выйти в интернет», запросить системное время или файл — все данные должны прийти через транзакцию (calldata) или из состояния блокчейна. Это позволяет всем узлам сети прийти к одному и тому же новому состоянию после выполнения блока.

3) Модель аккаунтов и мировое состояние

Ethereum использует account-based модель:

• EOA (Externally-Owned Account) — «кошелёк», управляемый приватным ключом; может инициировать транзакции.

• Контракт-аккаунт — имеет код и хранилище; не может инициировать транзакции сам, только реагирует на входящие сообщения/транзакции.

• Состояние — это отображение адрес → (nonce, balance, storageRoot, codeHash). Полный узел хранит это как модифицированное Patricia-дерево; именно хэш-корни делают состояние проверяемым. Подробнее см. состояние Ethereum.

Создание контракта:

CREATE — адрес = keccak256(rlp(sender, nonce))[12:].

CREATE2 — адрес = keccak256(0xff ++ deployer ++ salt ++ keccak256(init_code))[12:]. Это позволяет детерминированные адреса (важно для фабрик, мета-транзакций, адресов «на будущее»).

6) Эволюция опкодов и поведения EVM на хардфорках

Byzantium принесла критические опкоды:

• REVERT (аккуратный откат с данными);

• STATICCALL (жёсткое «только чтение»);

• новые предкомпилы для zk-криптографии (см. ниже).

Constantinople / Petersburg:

• CREATE2 (детерминированное развёртывание);

• уточнения SSTORE (дальше — в EIP-2200).

Istanbul:

• Репрайс SLOAD, BALANCE, EXTCODE* и пр. (EIP-1884);

• Вводится модель net gas metering для SSTORE (EIP-2200).

Berlin:

• Ввод «тёплых/холодных» доступов к адресам/слотам (EIP-2929): первый доступ дороже, последующие дешевле в рамках транзакции;

• Появляются access list-транзакции (EIP-2930): объявляете наперёд, чтобы снизить стоимость «холодного» доступа.

London:

• Сильное сокращение refunds (EIP-3529): нельзя «майнить рефанды» через массовые очищения слотов.

Shanghai:

• PUSH0 — теперь пуш «нуля» не требует 2-байтного PUSH1 0x00 (меньше байткода/газа);

• EIP-3860: лимит initcode = 49 152 байта и дополнительная тарификация за каждые 32 байта (важно для больших фабрик/прокси).

Dencun (Cancun-Deneb):

• Transient storage: TSTORE/TLOAD — сверхдешёвое временное хранилище внутри одной транзакции (идеально для «переноса состояния» между внутренними вызовами без записи в постоянное storage);

• MCOPY — быстрый memory-to-memory copy.

Shanghai также изменила SELFDESTRUCT:

• EIP-6780: SELFDESTRUCT больше не удаляет контракт и не очищает storage, если контракт не был создан в той же транзакции. По сути — возвращает эфир на адрес-бенефициар, но код/хранилище остаются (важно для миграций и безопасности).

Практика: не используйте SELFDESTRUCT как «кнопку удаления» — после EIP-6780 это не очистка состояния. Для «отключения» логики закладывайте флаги/роллинг-админа или апгрейдируемую архитектуру.

7) Предкомпилированные контракты (precompiles)

Ряд «тяжёлых» операций вынесен в фиксированные адреса 0x01–0x09. Чаще всего используются:

0x01 — ECRECOVER (восстановление адреса из подписи).

0x02 — SHA-256.

0x03 — RIPEMD-160.

0x04 — IDENTITY.

0x05 — модульное возведение в степень (MODEXP).

0x06/0x07/0x08 — операции над alt_bn128 (BN254): сложение, умножение, паринг — для zk-доказательств.

0x09 — BLAKE2f (компрессионная функция; используется редко).

Нюанс: набор и цена предкомпилов — часть консенсуса L1. На L2/парачейнах список может различаться. При портировании кода на «EVM-совместимые» сети проверяйте поддержку и цены предкомпилов.

8) Keccak-256, селекторы и ABI

В байткоде EVM используется Keccak-256 (исторически опкод называется SHA3, но это не NIST SHA-3). Отсюда ряд правил:

• Селектор функции — первые 4 байта keccak256(«foo(address,uint256)») из ABI-сигнатуры. Именно эти 4 байта стоят в начале calldata.

• Сигнатура события — topic[0] = keccak256(«Transfer(address,address,uint256)»).

• Маппинги/слоты — хеширование keccak256(key . slot).

Практика: всегда формируйте сигнатуры канонически (без пробелов, с точными типами), иначе селекторы/события не совпадут.

9) Безопасность: что чаще всего ломают в EVM

Реинэнтрантность (особенно вокруг call{value:…} и взаимодействия с внешними контрактами). Используйте checks-effects-interactions, ReentrancyGuard, избегайте логики в fallback/receive. Помните про «стипендию» 2300 газа — она защищала только «старый мир», сейчас её недостаточно.

DELEGATECALL и прокси: при ошибках в инициализации/слотах хранения возможны критические уязвимости. Всегда фиксируйте storage layout и используйте проверенные шаблоны (UUPS/Transparent).

Неучёт gas repricing: жёстко захардкоженные лимиты газа к внешним вызовам/петлям могут ломаться после репрайсов.

SELFDESTRUCT после EIP-6780: не рассчитывайте на очистку состояния; прорабатывайте «деактивацию» логики флагами.

CREATE2-коллизии и «подмена кода»: адрес заранее известен — подписывайте данные и проверяйте «код по адресу после деплоя», если от этого зависит безопасность.

См. Reentrancy, Delegatecall, Create2 Risks (перспективные статьи).

10) Совместимость/эквивалентность EVM на L2

Термины:

• EVM-совместимость — «код исполняется», но поведение/цены/предкомпилы могут отличаться.

• EVM-эквивалентность — цельная гарантия: «то же поведение байткода и опкодов», минимальные дельты по газу/краевым случаям. Это снижает риски «сюрпризов» при миграциях, важнее всего для аудита.

• В мире L2 (Optimism/OP Stack, Arbitrum, zkEVM-решения) проекты стремятся к эквивалентности, но детали критичны: сравнивайте поддержку новых опкодов (PUSH0/MCOPY/TSTORE), предкомпилов и лимитов.

11) Практика для разработчиков: короткая «шпаргалка»

Оптимизация газа:

• Минимизируйте SSTORE (батчи, флаги-битпак, инкрементальные обновления).

• Используйте PUSH0, MCOPY, transient storage (TSTORE/TLOAD) там, где допустимо.

• Предзаявляйте access list (тип-1/тип-3 транзакции) при массовых внешних чтениях.

Структуры данных:

• Хеш-ключи маппингов и структуры в слотах документируйте в Storage Layout.

• Для больших массивов — думайте о event-логах вместо постоянного storage, если данные не нужны в EVM-логике.

CREATE2:

• Храните salt и init_code_hash для воспроизводимости.

• Проверяйте «что по адресу уже есть код» перед деплоем (защита от подмен).

Логи/индексация:

• Используйте indexed для полей-фильтров; помните лимит «до 3 indexed» у неанонимных событий.

Обновления сети:

• Отслеживайте, как новые EIP-ы меняют газ/поведение (SSTORE, SELFDESTRUCT, новые опкоды).

• Не полагайтесь на «магические числа газа» — используйте безопасные паттерны.

12) Частые вопросы (FAQ)

EVM использует SHA-3? Исторически опкод назван SHA3, но в EVM используется Keccak-256 (пред-NIST версия), а не финальный NIST SHA-3. Для селекторов/событий берётся именно Keccak-256.

Сколько «памяти» у контракта? Память динамична и очищается после вызова. Постоянные данные — только в storage, который дорог по газу.

Почему мой контракт «не удаляется» через SELFDESTRUCT? Потому что после EIP-6780 удаление/очистка состояния фактически отключены (кроме случая «создан и тут же удалён в одной транзакции»).

Можно ли обойти лимит размера кода? Есть лимит размера развернутого кода (по EIP-170) и initcode (EIP-3860). Обходят архитектурой (разбиение на модули/библиотеки, прокси, апгрейды), оптимизируют компиляцию, используют PUSH0/MCOPY.

13) Перспективы и «куда движется EVM»

• EOF (EVM Object Format) — модульность и структурированный формат кода (пакеты, секции), уменьшение неоднозначностей исполнения и новые оптимизации. Следим за включением в будущие апгрейды L1 и поддержкой на L2.

• Новые EIP-ы по лимитам кода — обсуждаются поднятия/метризация лимита развернутого кода сверх 24 576 байт; проверяйте актуальный статус перед релизами.

• Account Abstraction — влияет на типы транзакций, но не меняет базовую модель EVM; важно для UX и газовой экономики.

14) Перелинковка по нашей вики (что читать далее)

Газ в Ethereum — полная таблица цен, base fee/priority fee, calldata-pricing.

ABI и кодирование — как кодируется calldata/returndata, динамические типы.

Keccak-256 — разница с SHA-3, практические советы.

Solidity и Vyper — языки для EVM.

Yul/Yul+ — промежуточный язык, инлайн-ассемблер.

Селекторы функций и события — 4-байтовые метод-ID и topic[0].

Реинэнтрантность и DELEGATECALL-риски — ключевые векторы атак.

CREATE2 и детерминированные адреса — фабрики, «адреса-заглушки».

Предкомпилы EVM — назначение и цена на L1/L2.

EVM-эквивалентность на L2 — чем отличается от «совместимости».

Памятка по storage-layout в Solidity · Шаблоны оптимизации газа · EOF: формат объектов EVM · SELFDESTRUCT после EIP-6780.

15) Мини-глоссарий

Word (слово) — 32 байта; базовая единица для большинства операций EVM.

Warm/Cold — тёплый/холодный доступ к адресу/слоту в рамках одной транзакции; первый доступ дороже (Berlin).

Transient storage — временное «хранилище» уровня транзакции (TSTORE/TLOAD), не сохраняется в состоянии.

Precompile — «вшитые» по адресам контракты для дорогих криптоопераций.

Access list — список адресов/слотов, объявленных заранее, чтобы удешевить «холодные» доступы.