Методы оптимизации газа

Что такое методы оптимизации газа?

Методы оптимизации газа — это способы сократить вычислительные ресурсы и объем данных блокчейна, необходимые для транзакции с криптовалютой или смарт-контракта.

В Ethereum и других сетях, совместимых с EVM, каждая операция Ethereum Virtual Machine имеет стоимость в газе.

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

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

Базовая формула: комиссия за транзакцию = списанный газ × эффективная цена газа.

Оптимизация газа сокращает часть этой формулы, отвечающую за объем списанного газа.

Она напрямую не влияет на рыночную цену единицы газа, которая меняется в зависимости от спроса на пространство в блоках.

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

Однако оптимизация газа ни в коем случае не должна ослаблять контроль доступа, безопасность арифметических операций, защиту от повторного входа, точность учета или другие свойства безопасности.

Как правило, лучшая оптимизация — более простая конструкция, выполняющая меньше операций, а не сложный код, написанный только ради экономии нескольких единиц газа.

Почему оптимизация газа важна в криптовалютах

Каждая избыточная операция в блокчейне создает расходы для человека или приложения, отправляющего транзакцию.

Небольшая разница может показаться несущественной для одной транзакции, но стать значительной, когда смарт-контракт обрабатывает тысячи или миллионы операций.

Снижение расхода газа может сделать более доступными переводы токенов, операции в децентрализованных финансах, действия с NFT, голосование по вопросам управления и блокчейн-игры.

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

Оптимизация газа особенно важна для приложений, выполняющих повторяющиеся циклы, обновляющих множество балансов, создающих новые контракты или вызывающих несколько внешних систем в одной транзакции.

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

Оптимизация газа не гарантирует низкую стоимость транзакции в национальной валюте: цена газа и рыночная цена нативной криптовалюты все равно могут вырасти.

Она сокращает объем сетевых вычислений, за которые должен платить пользователь.

Определите, на что расходуется газ

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

Постоянное хранилище обычно относится к самым дорогим ресурсам, поскольку соответствующие данные должны оставаться частью состояния блокчейна.

Память используется для временных данных в рамках одного выполнения и обычно обходится дешевле постоянного хранилища, хотя ее стоимость растет по мере расширения выделенной области.

Calldata содержит входные данные транзакции или внешней функции и не становится изменяемой памятью контракта, пока данные не будут скопированы.

Развертывание контракта требует газа для выполнения кода инициализации и сохранения результирующего исполняемого байткода.

Вызовы внешних контрактов создают дополнительные расходы на доступ к аккаунтам, кодирование аргументов, обработку возвращаемых данных и работу вызываемого контракта.

На общий расход газа также могут существенно влиять криптографические вычисления, журналы событий, создание контрактов и длинные циклы.

В официальной документации Ethereum о газе объясняется, что газ измеряет вычислительные ресурсы, необходимые для транзакций и операций EVM.

Измеряйте расход газа до оптимизации

Оптимизацию газа следует начинать с измерений, а не с предположений.

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

Тесты должны охватывать реалистичные размеры транзакций, обычное поведение пользователей, максимально допустимые входные данные, сценарии отказа и нестандартные состояния блокчейна.

Функция, недорогая при одном элементе массива, может стать небезопасной или слишком дорогой при тысяче элементов.

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

Трассировки выполнения показывают, какие опкоды, слоты хранилища, внутренние и внешние вызовы требуют больше всего газа.

Компилятор Solidity может предоставлять оценки газа, описанные в его документации, однако некоторые оценки недоступны или ненадежны, если выполнение зависит от динамических циклов или поведения внешних контрактов.

Более реалистичные измерения можно получить при тестировании в локальном блокчейне или действующей общедоступной тестовой сети.

Разработчикам следует оптимизировать дорогие пути, которыми действительно пользуются, а не тратить время на редко вызываемый код.

Используйте актуальную версию компилятора Solidity

Новые версии компилятора Solidity часто содержат улучшения генерации кода, исправления оптимизатора, поддержку новых инструкций EVM и исправления уязвимостей.

Согласно официальному сайту Solidity, в июле 2026 года последней выпущенной версией компилятора была 0.8.36.

Перед выбором компилятора для промышленной среды разработчикам следует проверить официальный сайт Solidity и список известных ошибок компилятора.

Выбранную версию следует зафиксировать в конфигурации сборки, чтобы все разработчики, системы тестирования и конвейеры развертывания создавали одинаковый байткод.

Если использовать широкое ограничение pragma без контроля фактической среды сборки, разные версии компилятора могут генерировать разный код.

Даже новый компилятор необходимо тщательно протестировать: оптимизации и изменения языка могут повлиять на байткод, стоимость развертывания и поведение контракта.

Включите и настройте оптимизатор Solidity

Оптимизатор Solidity упрощает выражения, удаляет лишние операции, объединяет повторяющиеся вычисления и может уменьшить как размер байткода при развертывании, так и расход газа при выполнении.

В документации оптимизатора Solidity объясняется, что оптимизация может уменьшить размер кода и стоимость выполнения.

Параметр runs показывает, как часто разработчик ожидает выполнять развернутый код.

При низком значении runs обычно больше внимания уделяется уменьшению размера байткода при развертывании.

При высоком значении runs компилятор обычно может создать более крупный код, развертывание которого дороже, но повторное выполнение дешевле.

Универсального оптимального значения runs для всех криптовалютных контрактов не существует.

Контракт, который развертывают много раз, но вызывают редко, может требовать других настроек, чем контракт, рассчитанный на миллионы транзакций.

Разработчикам следует сравнить несколько конфигураций на реальных тестах и оценить общую стоимость жизненного цикла, а не только развертывания или выполнения.

Конвейер компиляции via-IR может применять другие оптимизации, чем старый конвейер, однако его смену следует считать существенным изменением сборки и полностью тестировать.

Сократите количество записей в постоянное хранилище

Записи в постоянное хранилище часто дают наибольшую возможность снизить расход газа.

Контракту не следует хранить сведения, которые можно безопасно рассчитать на основе существующего состояния или получить от пользователя по мере необходимости.

Не следует повторно записывать одно и то же значение, если контракт может заранее определить, что изменений не требуется.

Контракт, обновляющий пять отдельных переменных состояния, может обходиться дороже более простой модели учета с меньшим количеством записей.

Разработчикам также следует учитывать, должны ли другие смарт-контракты иметь доступ к информации или она нужна только внешним приложениям.

Данные, влияющие на будущее выполнение контракта, обычно следует хранить в постоянном хранилище.

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

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

Контрактам следует удалять устаревшее состояние по обоснованным причинам проектирования, а не создавать лишние данные в надежде получить возврат позднее.

Кэшируйте повторные чтения из хранилища

Повторное чтение слота хранилища обходится дороже, чем чтение один раз с последующим использованием локального значения, если состояние не должно меняться между чтениями.

В Ethereum различаются холодный и теплый доступ к состоянию согласно EIP-2929.

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

Последующие обращения к тому же слоту в рамках транзакции являются теплыми и стоят меньше.

Даже чтение из теплого хранилища может обходиться дороже, чем использование уже доступного функции значения стека или памяти.

Функция часто может скопировать часто используемую переменную состояния в локальную переменную, выполнить расчеты и один раз записать итоговый результат.

Этот способ нельзя применять, если внешний вызов может изменить соответствующее состояние или кэшированное значение может устареть.

При кэшировании состояния вокруг внешних вызовов разработчикам следует придерживаться принципа «проверки — эффекты — взаимодействия» и тщательно анализировать риск повторного входа.

Аккуратно упаковывайте переменные состояния

Хранилище Ethereum организовано в слоты размером 32 байта.

Несколько переменных небольших типов значений могут занимать один слот, если это допускают их порядок и общий размер.

Например, несколько целочисленных значений меньшего размера или булевых значений могут занимать один слот вместо нескольких.

В документации Solidity о структуре хранилища объясняется, как порядок переменных, структуры, массивы, наследование и упаковка влияют на распределение слотов.

Таким образом, порядок переменных может менять количество слотов, необходимых контракту.

Однако использование целого типа наименьшего возможного размера не всегда обходится дешевле.

EVM обычно выполняет арифметические операции со словами размером 256 бит, поэтому для целочисленных типов меньшего размера могут потребоваться дополнительные операции маскирования или преобразования.

Упаковка дает наиболее очевидный эффект, когда несколько упакованных значений часто читаются или записываются вместе.

Обновление только одного значения в упакованном слоте может потребовать чтения слота, изменения части слова и повторной записи объединенного значения.

Структура хранилища также влияет на совместимость обновляемых контрактов, поэтому после развертывания разработчикам не следует менять порядок существующих переменных состояния только ради экономии газа.

Используйте переменные constant и immutable

Значение, которое никогда не меняется после компиляции, обычно следует объявлять как

, если это допускает Solidity.

Значение, выбранное при создании контракта и зафиксированное после этого, можно объявить как

.

Для констант и неизменяемых значений не требуется обычное обращение к постоянному хранилищу, поскольку их значения встраиваются в код или хранятся вместе с ним.

В официальной документации Solidity о переменных состояния объясняется, чем эти переменные отличаются от обычных переменных состояния.

Обычно так объявляют фиксированные параметры конфигурации, постоянные адреса, математические константы и ограничения, которые нельзя изменить после развертывания.

Не следует делать переменную неизменяемой, если приложению действительно нужно обновлять ее через управление сообществом или другой авторизованный процесс.

Если ради экономии газа убрать необходимую гибкость, позднее это может привести к более серьезной операционной проблеме.

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

Аргументы внешней функции, которые не нужно изменять, часто можно объявить с областью данных

.

Calldata доступна только для чтения и позволяет не копировать все входные данные в память в начале выполнения.

В рекомендациях Solidity по областям данных предлагается по возможности использовать calldata, поскольку она исключает копирование и не позволяет изменять данные.

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

Память подходит, если контракту нужно изменить данные или создать новое значение в памяти.

Не следует считать, что замена параметра функции с

на целое число меньшего размера автоматически уменьшит объем calldata.

Стандартное ABI-кодирование обычно размещает статические значения в словах по 32 байта, а для типов меньшего размера могут потребоваться преобразования или проверка данных.

Экономию газа следует подтверждать измерениями, а не выводить только из названия типа в исходном коде.

Сократите объем calldata транзакции

Каждый байт в calldata транзакции увеличивает ее базовую стоимость.

Ненужные массивы, повторяющиеся поля, длинные текстовые строки и неэффективное кодирование могут сделать транзакции пользователей дороже.

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

Также можно не отправлять сведения, которые контракт способен безопасно вывести из существующего состояния или адреса отправителя транзакции.

Сжатие может помочь в специализированных системах, но распаковка сама требует газа и может свести на нет ожидаемую экономию.

В обновлении Pectra активирован EIP-7623, который ввел повышенный минимальный уровень комиссии для транзакций с большими объемами данных.

Поэтому эффективность calldata особенно важна для транзакций с большим количеством данных и относительно небольшим объемом выполнения EVM.

Разработчикам следует сравнивать стоимость компактной calldata с дополнительными вычислениями, необходимыми для ее декодирования.

Используйте transient storage для состояния в пределах транзакции

Transient storage позволяет контрактам хранить значения, доступные при внутренних вызовах в рамках одной транзакции, но автоматически удаляемые после ее завершения.

Ethereum добавил опкоды

и в рамках EIP-1153.

Transient storage дешевле постоянного, поскольку его данные не становятся частью неизменяемого состояния блокчейна.

Один из распространенных вариантов использования — блокировка повторного входа, необходимая только во время выполнения одной транзакции.

В актуальных версиях Solidity поддерживаются переменные состояния временного хранения типа value, если контракты предназначены для EVM Cancun или более новой совместимой версии.

Не следует использовать transient storage для сведений, которые должны сохраниться до следующей транзакции.

Также необходимо тщательно разобраться в его поведении при обычных вызовах, delegate call и взаимодействии совместимых контрактов.

В документации Solidity о transient storage предупреждается, что временное состояние действует в пределах транзакции и имеет особые правила владения при разных типах вызовов.

Не следует заменять проверенный механизм безопасности transient storage, пока новая реализация не будет тщательно протестирована и проверена аудитом.

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

Пользовательские ошибки позволяют экономно возвращать структурированную информацию о сбое.

Длинная строка отката входит в байткод развернутого контракта и создает кодированные возвращаемые данные при возникновении ошибки.

Пользовательская ошибка использует четырехбайтовый селектор и объявленные параметры, что может сократить размер развертывания и стоимость сценария сбоя.

В документации Solidity о пользовательских ошибках они описаны как удобный и эффективный по расходу газа механизм.

Названия ошибок и параметры должны оставаться достаточно понятными, чтобы кошельки, разработчики и системы мониторинга могли диагностировать проблему.

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

Оптимизируйте циклы и обработку массивов

Циклы могут обходиться чрезвычайно дорого, если число итераций зависит от массива или коллекции в хранилище, которая может расти без строгого ограничения.

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

Если возможно, большие задачи следует разделять на ограниченные пакеты.

Иногда можно кэшировать длину массива в локальной переменной, чтобы не считывать ее из хранилища при каждой итерации.

Если это безопасно, значения из хранилища, используемые в каждой итерации, также можно кэшировать.

Разработчики могут использовать арифметику

для счетчика цикла только в том случае, если они могут доказать невозможность переполнения.

Современные компиляторы уже оптимизируют некоторые распространенные шаблоны циклов, поэтому перед применением ручных изменений следует провести сравнительное тестирование.

Обработка данных в нескольких транзакциях может повысить надежность, но контракт должен безопасно отслеживать прогресс и предотвращать пропуск, дублирование и нарушение порядка операций.

Избегайте избыточных внешних вызовов

Вызов другого контракта требует газа и подвергает транзакцию влиянию его поведения при выполнении.

Функции не следует повторно запрашивать одно и то же внешнее значение, если можно безопасно вызвать контракт один раз и использовать результат повторно.

Иногда несколько связанных действий можно объединить в один вызов контракта.

Однако пакетная обработка увеличивает объем работы, которая может завершиться неудачей одновременно, и может расширить calldata.

Внешние вызовы также могут создавать риск повторного входа, возвращать неожиданные данные, расходовать значительное количество газа или приводить к откату всей транзакции.

Экономия газа не должна быть поводом отказываться от проверки возвращаемых значений или безопасной обработки вызовов.

Разработчикам следует оценить, остается ли кэшированное внешнее значение актуальным в ходе выполнения и может ли внешняя система изменить его через обратный вызов.

Когда уместно, используйте события вместо хранилища

События записывают сведения в журналы транзакций, которые могут индексировать внешние приложения.

Часто это обходится дешевле, чем хранение той же информации в состоянии контракта.

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

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

Обычно смарт-контракты не могут получать исторические журналы при обычном выполнении EVM.

Системе, хранящей критически важные учетные данные только в событиях, понадобится внешняя служба для их восстановления, и она не сможет обеспечивать их соблюдение непосредственно в блокчейне.

Параметры событий также следует проектировать тщательно, поскольку индексированные темы и данные журнала имеют разные затраты газа и возможности поиска.

Уменьшите размер развертываемого контракта

При развертывании контракта взимается плата за выполнение кода инициализации и сохранение исполняемого байткода.

Неиспользуемые функции, дублированная логика, длинные строки отката и встроенные данные могут увеличить стоимость развертывания.

Разработчикам следует удалять неиспользуемый код и не подключать крупные библиотеки, если нужна лишь небольшая часть их функциональности.

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

Фабричные шаблоны и шаблоны клонов могут удешевить развертывание множества похожих экземпляров контракта за счет совместного использования кода реализации.

Шаблоны прокси позволяют выполнять обновления и повторные развертывания, но добавляют расходы на delegate call, а также создают серьезные сложности с расположением хранилища, управлением и безопасностью.

В Ethereum обычный размер исполняемого байткода после развертывания ограничен согласно EIP-170, а EIP-3860 устанавливает плату и ограничение на код инициализации.

Разделение кода только ради соблюдения ограничения размера может повысить стоимость вызовов, поэтому архитектуру следует оценивать с учетом всего жизненного цикла контракта.

Выберите подходящую версию EVM

Результат компиляции зависит от выбранной целевой версии EVM.

Компилятор, ориентированный на более новую версию EVM, может использовать инструкции, недоступные в старой сети.

Например, Shanghai добавило инструкцию

в рамках EIP-3855, позволяющую помещать нулевое значение с помощью более короткой и дешевой инструкции.

В обновлении Dencun появилась инструкция

по EIP-5656, обеспечивающая более эффективное копирование данных в памяти.

Современные компиляторы могут автоматически использовать такие инструкции, если настроены для совместимой сети.

Обычно разработчикам не следует вручную воспроизводить подобные оптимизации компилятора на ассемблере.

Контракт, скомпилированный для еще не активированного в целевой сети обновления протокола, может не развернуться или не выполниться.

Поэтому для каждой целевой сети в системе сборки следует установить правильную версию EVM.

Используйте списки доступа только после тестирования

Списки доступа позволяют указать аккаунты и ключи хранилища, к которым транзакция предположительно обратится.

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

Согласно EIP-2930, плата взимается за каждый включенный в список адрес и ключ хранилища.

Точный список доступа может снизить стоимость некоторых предсказуемых транзакций.

Неполный или ненужный список может увеличить общую комиссию, поскольку пользователь платит за элементы, которые дают недостаточную выгоду или не используются.

Составить список доступа бывает сложно, если точный путь выполнения зависит от меняющегося состояния блокчейна.

Разработчикам следует моделировать всю транзакцию со списком доступа и без него, а не считать, что предварительная загрузка состояния всегда дешевле.

Аккуратно объединяйте действия пользователей

Объединение нескольких действий в одну транзакцию позволяет избежать многократной оплаты начальных расходов за транзакцию.

Например, приложение может позволить пользователю согласовать действие и выполнить его в рамках единого скоординированного процесса.

В обновлении Pectra активирован EIP-7702, позволяющий аккаунтам с внешним управлением делегировать выполнение коду смарт-контрактов и поддерживать такие функции кошелька, как пакетная обработка и оплата газа за пользователя.

Пакетная обработка не всегда снижает все составляющие стоимости выполнения, поскольку каждое действие по-прежнему требует выполнения необходимых операций со смарт-контрактом.

Большой пакет может превысить практические лимиты газа, увеличить объем calldata или привести к откату всех действий из-за сбоя одного этапа.

В приложениях следует определить, допускается ли частичное выполнение и как сообщать о сбое отдельных действий.

Необходимо тщательно проверять авторизацию и делегированный код: системы пакетной обработки могут получить широкие полномочия в отношении активов пользователя.

Используйте сети Layer 2, когда это уместно

Оптимизация на уровне приложения сокращает количество расходуемых единиц газа, а сеть Layer 2 может снизить цену выполнения операций и обработки данных для пользователей.

Роллапы обрабатывают операции вне Ethereum Mainnet и публикуют в Ethereum данные или доказательства.

В обновлении Dencun введены транзакции с blob-данными по EIP-4844, предоставившие роллапам временный специализированный канал передачи данных.

Последующие обновления Pectra и Fusaka расширили возможности Ethereum по масштабированию и обеспечению доступности данных.

В актуальных рекомендациях Ethereum для разработчиков объясняется, как недавние обновления изменили комиссии Mainnet, возможности аккаунтов и экономику роллапов.

Развертывание в сети Layer 2 не отменяет необходимости оптимизировать контракты: лишние записи в хранилище и вычисления по-прежнему повышают комиссии пользователей и сокращают пропускную способность.

Перед выбором сети разработчикам также следует оценить требования к мостам, выводу средств, ликвидности, безопасности и совместимости.

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

Встроенный ассемблер дает разработчикам точный контроль над операциями EVM и иногда позволяет снизить расход газа.

Однако он отключает или обходит некоторые проверки типов, средства защиты памяти и другие функции безопасности высокого уровня в Solidity.

Короткий фрагмент ассемблера может быть сложен для понимания проверяющими и привести к повреждению памяти, ошибочному кодированию или небезопасному поведению вызовов.

Компилятор уже может преобразовывать обычный код Solidity в столь же эффективный байткод, как и ручная реализация.

Поэтому ассемблер следует использовать лишь для измеренных узких мест, специализированной криптографии, низкоуровневой обработки данных или функциональности, которую Solidity не позволяет реализовать эффективно.

Для каждой оптимизации на ассемблере необходимы тесты, сравнивающие ее результат с понятной эталонной реализацией.

Независимая проверка безопасности особенно важна, когда ассемблер управляет балансами токенов, подписями, разрешениями или внешними вызовами.

Не жертвуйте безопасностью ради экономии газа

Смарт-контракт не становится лучше от того, что он обходится дешевле, если при этом пользователи могут потерять криптовалюту.

Разработчикам не следует удалять проверки контроля доступа, валидацию входных данных, защиту от повторного входа, проверку срока действия, защиту от проскальзывания или проверки учета только ради экономии газа.

Арифметику

следует использовать только в том случае, если переполнение и потеря значимости математически невозможны при любых достижимых условиях.

Объединение нескольких переменных в одно сжатое значение может сэкономить место в хранилище, но повысить риск ошибок при побитовых операциях.

Прокси может снизить стоимость развертывания, но создает риски, связанные с полномочиями на обновление и конфликтами расположения хранилища.

Внешняя подпись может сократить количество транзакций, но требует корректно обрабатывать nonce, срок действия, разделение доменов и защиту от повторного воспроизведения.

При оценке каждой оптимизации следует учитывать читаемость, возможность аудита, операционные риски и поддержку в будущем, а не только расход газа.

Распространенные ошибки оптимизации газа

Одна из распространенных ошибок — выбирать целочисленные типы меньшего размера, не упаковывая их с другими значениями.

EVM работает со словами размером 256 бит, поэтому сам по себе тип меньшего размера может не снизить стоимость выполнения.

Другая ошибка — копировать всю calldata в память, хотя функция только считывает ее.

Третья — очищать хранилище ради возврата газа, планируя позднее заново создать то же состояние.

Четвертая — использовать неограниченный цикл по растущему массиву в хранилище.

Пятая — устанавливать высокое значение runs оптимизатора без сравнения поведения при развертывании и выполнении.

Шестая — писать ассемблер вручную до профилирования контракта.

Седьмая — считать, что оптимизация останется эффективной после обновления компилятора или сети, изменившего поведение опкодов.

Восьмая — измерять только успешные транзакции и не учитывать дорогие сценарии отката.

Девятая — считать меньшую оценку газа доказательством того, что две реализации имеют одинаковую безопасность и бизнес-логику.

Как выстроить процесс оптимизации газа

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

До начала низкоуровневой оптимизации команде следует подготовить функциональные тесты.

Затем нужно измерить стоимость развертывания и расход газа для каждого важного пути транзакции.

С помощью профилирования следует выявить самые затратные записи в хранилище, циклы, входные данные calldata и внешние вызовы.

Разработчики могут упростить архитектуру, сократить изменения состояния, выбрать подходящие области данных и включить проверенные настройки оптимизации компилятора.

Каждое изменение следует сравнивать с исходной версией и проверять на предмет новых рисков безопасности.

В проекте следует сохранить тесты на регрессию расхода газа, чтобы последующая разработка не привела к незаметной потере экономии.

Окончательный байткод для промышленной среды следует компилировать с зафиксированной версией компилятора, проверенной конфигурацией, правильной целевой версией EVM и проверенными версиями зависимостей.

Контракты с крупными суммами в криптовалюте должны проходить независимый аудит безопасности, даже если оптимизированный код успешно прошел внутреннее тестирование.

Часто задаваемые вопросы

Какой метод оптимизации газа самый эффективный?

Как правило, наибольший эффект дает сокращение операций с постоянным хранилищем и упрощение объема работы в блокчейне для каждой транзакции.

Всегда ли оптимизатор Solidity снижает расход газа?

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

Что означает настройка runs оптимизатора?

Она указывает компилятору, как часто разработчик рассчитывает выполнять код, и влияет на соотношение между размером при развертывании и стоимостью многократного выполнения.

Хранилище дороже памяти?

Да, постоянное хранилище обычно обходится значительно дороже, поскольку его данные остаются частью состояния блокчейна после завершения транзакции.

Calldata дешевле памяти?

Для внешних входных данных, доступных только для чтения, calldata может быть дешевле, поскольку контракту не нужно сначала полностью копировать данные в память.

Всегда ли целочисленные типы меньшего размера экономят газ?

Нет. Они наиболее полезны, когда несколько значений можно упаковать в один слот хранилища; отдельные небольшие целые числа могут потребовать дополнительных преобразований.

Зачем разработчикам кэшировать значения хранилища?

Кэширование позволяет избежать повторных чтений из хранилища, если значение не меняется и его безопасно повторно использовать из стека или памяти.

Что такое transient storage?

Transient storage — это хранилище EVM, действующее в пределах транзакции и автоматически очищаемое после нее; оно может использоваться для более дешевого хранения временных данных, например блокировки повторного входа.

Пользовательские ошибки дешевле строк отката?

Как правило, пользовательские ошибки эффективнее по расходу газа, поскольку используют компактный селектор и кодированные параметры вместо длинных текстовых строк.

Могут ли события заменить хранилище контракта?

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

Возвращается ли весь газ, потраченный на удаление данных из хранилища?

Нет, возврат за очистку хранилища ограничен и регулируется общим лимитом возврата газа на уровне протокола.

Следует ли разработчикам использовать арифметику unchecked для экономии газа?

Арифметику unchecked следует применять только тогда, когда переполнение или потеря значимости доказуемо невозможны, а обоснование безопасности задокументировано и проверено.

Всегда ли объединение транзакций экономит газ?

Нет, пакетная обработка может сократить повторяющиеся расходы на транзакции, но увеличить объем calldata, сложность выполнения и риск сбоя всех действий.

Может ли сеть Layer 2 заменить оптимизацию контракта?

Нет. Более низкие комиссии сети могут снизить расходы пользователей, но неэффективные контракты по-прежнему расходуют больше ресурсов и обходятся дороже оптимизированных контрактов в той же сети.

Всегда ли списки доступа снижают расход газа?

Нет, элементы списка доступа сами имеют стоимость и могут увеличить комиссию, если список неточен или не нужен.

Всегда ли встроенный ассемблер расходует меньше газа?

Нет. Компилятор может сгенерировать столь же эффективный код, а небезопасный ассемблер создает серьезные риски для безопасности и поддержки.

Как разработчикам измерять расход газа?

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

Почему после обновления сети стоимость газа может измениться?

Обновления Ethereum могут добавлять опкоды, менять цену существующих операций, корректировать правила для calldata или вводить более эффективные функции работы с хранилищем и памятью.

Может ли оптимизация газа предотвратить высокие сетевые комиссии?

Она сокращает число используемых единиц газа, но не может предотвратить рост рыночной цены газа, когда многие пользователи конкурируют за пространство в блоках.

Всегда ли самый дешевый контракт — лучший?

Нет, правильность, безопасность, читаемость и удобство поддержки важнее небольшой экономии газа.

Заключение

Методы оптимизации газа сокращают вычислительные ресурсы, объем хранилища, calldata и затраты на развертывание, необходимые смарт-контрактам для криптовалютных операций.

Наибольшую экономию часто дают сокращение записей в постоянное хранилище, безопасное кэширование повторных чтений, правильный выбор областей данных, уменьшение ненужной calldata и отказ от избыточных внешних вызовов.

Современные компиляторы Solidity могут автоматически оптимизировать байткод, но настройки оптимизатора следует выбирать на основе реалистичных измерений, а не догадок.

Современные функции Ethereum, такие как transient storage,

, , делегирование кода аккаунта и обновленные правила расчета стоимости calldata, изменили подход разработчиков к оптимизации.

Разработчикам следует выбирать правильную версию EVM и следить за актуальностью компилятора, тестов и знаний о правилах протокола.

Переменные можно упаковывать, а пользовательские ошибки, ограниченные циклы, пакетная обработка, события, библиотеки и развертывание в Layer 2 могут снижать затраты, если соответствуют архитектуре приложения.

Списки доступа, прокси, встроенный ассемблер, арифметика unchecked и сжатие хранилища требуют особой осторожности: небольшая экономия газа может привести к значительному усложнению или риску.

Каждую оптимизацию следует оценивать с учетом развертывания, успешного выполнения, сценариев отказа и долгосрочной эксплуатации контракта.

Нельзя удалять проверки безопасности лишь ради снижения показателя расхода газа.

Наиболее эффективная стратегия оптимизации газа — выполнять только минимальный объем работы в блокчейне, необходимый для безопасных и проверяемых операций с криптовалютой.