Газовый гольфинг

Что такое газовый гольфинг?

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

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

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

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

Чаще всего газовый гольфинг применяют в Ethereum и других сетях, исполняющих смарт-контракты с помощью Ethereum Virtual Machine.

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

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

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

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

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

Почему это называется газовым гольфингом?

Слово «гольфинг» отсылает к цели набрать меньше очков.

В традиционном гольфе чем меньше ударов, тем лучше.

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

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

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

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

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

Как работает газовый гольфинг

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

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

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

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

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

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

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

Итоговый результат нужно измерять на скомпилированном байт-коде: визуально более короткий код Solidity не всегда дешевле выполняется в EVM.

Газовый гольфинг и оптимизация газа

Оптимизация газа — это широкий процесс снижения затрат на развертывание и выполнение смарт-контракта.

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

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

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

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

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

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

Газовый гольфинг и код-гольф

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

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

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

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

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

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

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

Газовый гольфинг и снижение цены газа

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

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

Комиссию за транзакцию можно представить формулой: «Списанный газ × Эффективная цена газа».

Изменения в рамках газового гольфинга направлены на сокращение количества списываемого газа.

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

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

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

Зачем разработчики занимаются газовым гольфингом

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

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

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

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

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

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

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

Сначала измерьте расход газа

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

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

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

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

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

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

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

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

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

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

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

В официальном объявлении о выпуске Solidity 0.8.36 версия 0.8.36 указана как актуальная в июле 2026 года.

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

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

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

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

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

Сначала используйте оптимизатор Solidity

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

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

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

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

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

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

Высокое значение runs обычно сильнее ориентировано на многократное выполнение кода.

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

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

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

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

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

В соответствии с EIP-2929 Ethereum применяет разные затраты для холодного и теплого доступа.

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

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

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

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

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

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

Запись постоянного состояния — одна из самых затратных распространенных операций смарт-контракта.

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

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

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

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

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

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

Упаковывайте переменные в хранилище

Ethereum делит хранилище контракта на слоты размером 32 байта.

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

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

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

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

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

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

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

Используйте константы и неизменяемые значения

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

Значение, известное во время компиляции, можно объявить как

.

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

.

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

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

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

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

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

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

.

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

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

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

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

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

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

Используйте пользовательские ошибки

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

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

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

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

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

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

Расположите условия с учетом короткого замыкания

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

В выражении с логическим AND вычисление может остановиться после первого ложного условия.

В выражении с логическим OR вычисление может остановиться после первого истинного условия.

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

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

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

Оптимизируйте циклы осторожно

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

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

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

Для счетчика цикла можно использовать инкремент

, если математически невозможно его переполнение.

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

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

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

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

Используйте арифметику unchecked только при наличии доказательства

В Solidity 0.8 и более поздних версиях по умолчанию проверяется переполнение и потеря значимости целочисленной арифметики.

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

Блок

отключает автоматическую проверку для содержащихся в нем операций.

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

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

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

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

Используйте transient storage для временного состояния

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

Ethereum ввел операции

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

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

Типичный пример данных, ограниченных одной транзакцией, — блокировка повторного входа.

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

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

Замена проверенного механизма безопасности более дешевой реализацией на transient storage требует полного тестирования и проверки.

Используйте современные инструкции EVM

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

EIP-3855 ввел

— компактную инструкцию для помещения нуля в стек.

EIP-5656 ввел

— специальную операцию копирования данных в памяти.

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

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

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

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

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

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

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

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

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

Возвращаемые значения и условия успешного выполнения по-прежнему нужно проверять корректно.

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

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

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

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

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

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

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

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

Сокращайте размер байт-кода при развертывании

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

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

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

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

Код инициализации отдельно учитывается и ограничивается согласно EIP-3860.

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

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

Учитывайте ограничения возврата газа

Некоторые старые стратегии газового гольфинга в Ethereum в значительной степени опирались на создание и последующее удаление записей хранилища.

Действующие правила Ethereum существенно ограничивают такой подход.

EIP-3529 уменьшил возврат газа за очистку хранилища, отменил прежний возврат за

и ограничил применяемый возврат 20% от общего расхода газа.

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

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

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

Оптимизация calldata и EIP-7623

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

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

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

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

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

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

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

Когда уместен встроенный ассемблер

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

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

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

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

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

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

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

Когда газовый гольфинг становится опасным

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

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

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

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

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

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

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

Устаревшие советы по газовому гольфингу

Советы по газовому гольфингу могут устаревать по мере изменений Solidity и EVM.

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

Обновление сети может изменить стоимость опкода или добавить более эффективную инструкцию.

Старый совет использовать

для получения возврата газа больше не актуален для текущего Ethereum.

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

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

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

Как оценить изменение в рамках газового гольфинга

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

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

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

Модульные тесты должны проверять обычное поведение функций.

Фазз-тестирование должно охватывать неожиданные входные данные и граничные условия.

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

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

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

Газовый гольфинг в рабочих контрактах

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

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

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

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

В обновляемых контрактах необходимо сохранять структуру хранилища и модель авторизации.

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

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

Распространенные ошибки при газовом гольфинге

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

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

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

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

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

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

Они могут полагаться на старое расписание затрат на газ, которое уже не соответствует текущей EVM.

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

Вопросы и ответы

Что такое газовый гольфинг простыми словами?

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

Газовый гольфинг — это то же самое, что оптимизация газа?

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

Газовый гольфинг — это функция протокола Ethereum?

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

Короткий код Solidity всегда потребляет меньше газа?

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

Может ли оптимизатор Solidity автоматически выполнять газовый гольфинг?

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

Какой прием газового гольфинга лучше всего?

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

Всегда ли целые числа меньшего размера дешевле?

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

Всегда ли calldata дешевле memory?

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

Почему пользовательские ошибки полезны для газового гольфинга?

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

Всегда ли кэширование значения из хранилища экономит газ?

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

Безопасна ли арифметика unchecked как способ оптимизации?

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

Следует ли использовать встроенный ассемблер?

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

Всегда ли префиксный инкремент стоит дешевле постфиксного?

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

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

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

Может ли газовый гольфинг сделать транзакцию бесплатной?

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

Снижает ли газовый гольфинг цену газа?

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

Можно ли использовать возврат газа как метод газового гольфинга?

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

Может ли газовый гольфинг создавать риски безопасности?

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

Как тестировать результаты газового гольфинга?

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

Когда газовый гольфинг оправдан?

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

Заключение

Газовый гольфинг — это целенаправленное изменение смарт-контракта, снижающее расход газа при развертывании или выполнении.

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

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

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

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

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

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

Встроенный ассемблер и операции unchecked следует применять только тогда, когда экономию можно измерить, а безопасность — доказать.

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

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