Оптимизация газа в EVM — это про простую вещь: какие операции в Ethereum реально “дорогие” и как писать код так, чтобы не переплачивать за storage, лишние вычисления и внешние вызовы. В 2025+ это особенно важно для DeFi и L2: в L1 комиссия чувствительнее, а в L2 вы всё равно платите за выполнение и (часто) за данные. Поэтому “дешевле сеть” не отменяет того, что плохой код может сделать операцию дорогой и медленной.

База по терминам: газ в Ethereum, комиссии. Углублённо: паттерны оптимизации газа, опкоды EVM.

1) Что в EVM “дорого” и почему

1.1 Storage дороже всего

Чтение и особенно запись в storage стоят дорого, потому что storage — это часть состояния блокчейна, которое должны хранить и обслуживать все узлы. Поэтому любое “лишнее состояние” в контракте — это системная стоимость.

1.2 Внешние вызовы добавляют стоимость и риск

Каждый внешний вызов (вызов токена, DEX, оракула, другого контракта) — это дополнительные операции, потенциальные revert-сценарии, а иногда и расширение поверхности атаки (например, reentrancy). Часто оптимизация газа совпадает с упрощением архитектуры.

1.3 Данные (calldata) и память (memory) — дешевле storage, но тоже имеют цену

Параметры функций, массивы, строки, ABI-кодирование — всё это создаёт накладные расходы. Для публичных функций особенно важно, где вы держите данные: calldata или memory.

2) Практичные паттерны оптимизации газа (то, что чаще всего даёт эффект)

2.1 Кэшируйте чтения из storage в локальные переменные

Если вы несколько раз читаете одну и ту же переменную из storage — разумно прочитать один раз и работать с локальной копией. Это особенно заметно в циклах и сложных функциях.

2.2 Минимизируйте записи в storage (SSTORE)

• не пишите в storage “на каждый чих” — собирайте обновления и записывайте один раз;
• если значение не нужно хранить навсегда — возможно, достаточно события;
• не обновляйте storage, если значение не изменилось (проверка перед записью иногда окупается).

2.3 Используйте calldata для входных массивов и строк

Если функция внешняя и вы не меняете входные данные, используйте calldata вместо memory. Это уменьшает копирование данных.

2.4 Упаковка (packing) типов — осторожно, но полезно

Мелкие типы (uint128/uint64/bool) могут быть упакованы в один слот, если стоят рядом. Это снижает количество storage-слотов и экономит на хранении. Но есть важная оговорка: если контракт апгрейдируемый, упаковка повышает риск ошибок storage layout при изменениях. Для upgradeable контрактов оптимизация через packing должна быть осознанной и проверяемой.

2.5 События вместо хранения “истории”

Хранить логику истории в storage дорого. Если вам нужно, чтобы фронтенд/индексатор видел факт, используйте events. Храните в storage только то, что нужно для дальнейших вычислений на цепочке.

2.6 Сокращайте циклы и избегайте unbounded loops

Циклы по динамическим массивам в storage могут стать непредсказуемо дорогими. В худшем случае функция станет невыполнимой при росте массива. Лучше проектировать логику так, чтобы:

• обработка шла порциями (batch),
• или использовались маппинги и индексы,
• или тяжёлые вычисления выносились в off-chain и подтверждались доказуемым образом (если это уместно).

2.7 Объединяйте операции (batch) там, где это логично

Если пользователь часто делает несколько шагов подряд, можно дать “батч”-функцию, которая выполняет серию действий за одну транзакцию. Это экономит на постоянных накладных расходах (call overhead) и иногда упрощает UX. Но батчи увеличивают сложность и требуют хороших тестов.

3) Частые ошибки “оптимизации”, которые делают только хуже

3.1 “Микрооптимизации” вместо архитектуры

Самая частая ошибка — тратить время на мелочи (типы, инкременты, трюки), когда основной расход — лишние SSTORE или внешние вызовы. Сначала оптимизируют структуру состояния и количество записей, и только потом — микродетали.

3.2 Экономия газа ценой безопасности

Оптимизация не должна ломать безопасность: например, сокращение проверок доступа, упрощение логики внешних вызовов без защиты от reentrancy, или попытки “сэкономить” на валидности входных данных. В безопасности стоимость ошибки обычно на порядки выше, чем экономия газа.

3.3 Агрессивный packing в апгрейдируемых контрактах

Если вы используете прокси-апгрейды, любое изменение layout может убить контракт. Слишком плотная упаковка мелких типов усложняет безопасные изменения и повышает вероятность storage collision. Иногда “чуть дороже, но стабильнее” — правильный выбор.

3.4 Хранение всего “на всякий случай”

Новички часто пишут в storage всё подряд: прошлые цены, историю транзакций, списки всех участников. В итоге функция дорожает, массивы растут, и через год контракт становится непригодным для использования из-за газ-лимитов. Историю обычно лучше вести через events и индексацию.

4) Быстрый ориентир: где искать экономию в типовых контрактах

5) Чек-лист перед деплоем: “дёшево и безопасно”

• Сократил записи в storage: нет лишнего состояния, нет “истории” в storage.
• Кэшировал чтения из storage в пределах функции, особенно в циклах.
• Использую calldata для входных массивов/строк в external-функциях.
• Нет unbounded loops: рост данных не делает функцию невыполнимой.
• События используются разумно для логов и “истории”.
• Безопасность не урезана: проверки доступа, reentrancy-защита, проверки входных данных на месте.
• Профилировал газ на типовых сценариях и сравнил до/после изменения.

FAQ

Полезные ссылки

• Шаблоны оптимизации газа
• Опкоды EVM и связь с газом
• Storage layout и почему он важен для апгрейдов
• Аудит смарт-контрактов: что проверяют