Руководство по оптимизации Gas для смарт-контрактов Ethereum
Газовые расходы сети Ethereum всегда были общей проблемой для разработчиков и пользователей, особенно в периоды перегрузки сети. В часы пик пользователи часто вынуждены платить крайне высокие транзакционные сборы. Поэтому оптимизация газовых расходов на этапе разработки смарт-контрактов имеет решающее значение. Оптимизация расхода газа не только может эффективно снизить транзакционные затраты, но и повысить эффективность транзакций, обеспечивая пользователям более экономичный и эффективный опыт использования блокчейна.
В данной статье будет рассмотрена механика Gas-стоимости Эфирной виртуальной машины (EVM), ключевые концепции оптимизации Gas-стоимости, а также лучшие практики оптимизации Gas-стоимости при разработке смарт-контрактов. Надеемся, что эти материалы смогут вдохновить разработчиков и предоставить практическую помощь, а также помогут обычным пользователям лучше понять, как работают Gas-расходы EVM, в целях совместного решения проблем в экосистеме блокчейна.
Введение в механизм Gas-оплат EVM
В сетях, совместимых с EVM, "Gas" является единицей измерения вычислительных мощностей, необходимых для выполнения определённых операций.
В структуре EVM расходы на газ делятся на три части: выполнение операций, вызовы внешних сообщений и чтение/запись в память и хранилище.
Поскольку выполнение каждой транзакции требует вычислительных ресурсов, взимается определенная плата для предотвращения бесконечных циклов и отказа в обслуживании (DoS) атак. Плата, необходимая для завершения транзакции, называется "Gas-оплата".
С момента вступления в силу лондонского хардфорка EIP-1559( ), стоимость газа рассчитывается по следующей формуле:
Базовая плата будет уничтожена, а приоритетная плата будет использоваться в качестве стимула, чтобы побудить валидаторов добавлять транзакции в блокчейн. Установка более высокой приоритетной платы при отправке транзакции может увеличить вероятность включения транзакции в следующий блок. Это похоже на "чаевые", которые пользователи платят валидаторам.
1. Понимание оптимизации Gas в EVM
Когда смарт-контракты компилируются с помощью Solidity, контракт преобразуется в серию "операционных кодов", то есть opcodes.
Любая последовательность операций (, например, создание контракта, выполнение вызовов сообщений, доступ к хранилищу аккаунта и выполнение операций на виртуальной машине ) имеет признанную стоимость потребления газа, эти затраты зафиксированы в желтой книге Ethereum.
После нескольких изменений в EIP, стоимость газа для некоторых операций была скорректирована и может отличаться от указанной в желтой книге.
2.Основные концепции оптимизации газа
Основная идея оптимизации газа заключается в том, чтобы приоритизировать операции с высокой стоимостью эффективности на блокчейне EVM, избегая операций с высокими затратами на газ.
В EVM следующие операции имеют низкую стоимость:
Чтение и запись переменных в памяти
Чтение констант и неизменяемых переменных
Чтение и запись локальных переменных
Чтение переменной calldata, например массива и структур calldata
Внутренний вызов функции
Операции с высокой стоимостью включают:
Чтение и запись состояния переменных, хранящихся в смарт-контрактах
Внешний вызов функций
Циклические операции
Оптимизация затрат на газ EVM: лучшие практики
Основываясь на вышеупомянутых основных концепциях, мы составили список лучших практик по оптимизации Gas-расходов для сообщества разработчиков. Следуя этим практикам, разработчики могут снизить потребление Gas смарт-контрактами, уменьшить затраты на транзакции и создать более эффективные и удобные для пользователей приложения.
1. Старайтесь уменьшить использование хранилища
В Solidity хранилище ( является ограниченным ресурсом, потребление газа которого значительно выше, чем у памяти ). Каждый раз, когда смарт-контракт читает или записывает данные из хранилища, возникают высокие затраты на газ.
Согласно определению в желтой книге Ethereum, стоимость операций хранения более чем в 100 раз выше, чем стоимость операций с памятью. Например, команды OPcodesmload и mstore потребляют всего 3 единицы газа, в то время как операции хранения, такие как sload и sstore, даже в самых идеальных условиях требуют как минимум 100 единиц.
Методы ограничения использования хранилища включают:
Хранить непостоянные данные в памяти
Уменьшение количества изменений в хранилище: сохраняя промежуточные результаты в памяти, а затем, после завершения всех вычислений, распределяя результаты по переменным хранения.
( 2.Упаковка переменных
Количество Storage slot), используемого в смарт-контрактах, и способ, которым разработчик представляет данные, будут значительно влиять на потребление Gas.
Компилятор Solidity упаковывает последовательные переменные хранения в процессе компиляции и использует 32-байтовый слот хранения в качестве базовой единицы хранения переменных. Упаковка переменных означает разумное размещение переменных, позволяющее нескольким переменным поместиться в одном слоте хранения.
С помощью этого изменения разработчики могут сэкономить 20 000 единиц газа ###, поскольку для хранения неиспользуемого слота хранения требуется 20 000 газа (, но теперь нужно всего два слота хранения.
Поскольку каждый слот хранения потребляет газ, упаковка переменных оптимизирует использование газа, уменьшая количество необходимых слотов хранения.
![Gas оптимизация смарт-контрактов Ethereum: десять лучших практик])https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp(
) 3.Оптимизация типов данных
Переменная может быть представлена разными типами данных, но стоимость операций с разными типами данных также различна. Выбор подходящего типа данных помогает оптимизировать использование газа.
Например, в Solidity целые числа можно разделить на разные размеры: uint8, uint16, uint32 и т.д. Поскольку EVM выполняет операции с единицами по 256 бит, использование uint8 означает, что EVM сначала должен преобразовать его в uint256, а это преобразование потребует дополнительных затрат газа.
С точки зрения отдельных переменных, использование uint256 дешевле, чем uint8. Однако, если используется оптимизация упаковки переменных, ситуация меняется. Если разработчик сможет упаковать четыре переменные uint8 в один слот хранения, то общая стоимость их итерации будет ниже, чем у четырех переменных uint256. Таким образом, смарт-контракт сможет читать и записывать один слот хранения и помещать четыре переменные uint8 в память/хранение за одну операцию.
4. Использование переменных фиксированного размера вместо динамических переменных
Если данные могут быть ограничены 32 байтами, рекомендуется использовать тип данных bytes32 вместо bytes или strings. Как правило, переменные фиксированного размера потребляют меньше газа, чем переменные переменного размера. Если длина байтов может быть ограничена, старайтесь выбирать минимальную длину от bytes1 до bytes32.
( 5.Отображения и массивы
Списки данных Solidity могут быть представлены двумя типами данных: массивами ) Arrays ### и отображениями ### Mappings (, но их синтаксис и структура совершенно разные.
В большинстве случаев отображение более эффективно и менее затратно, однако массивы обладают итеративностью и поддерживают упаковку типов данных. Поэтому рекомендуется в первую очередь использовать отображение при управлении списками данных, если нет необходимости в итерации или если упаковка типов данных может оптимизировать потребление Gas.
![Оптимизация Gas для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-5f3d7e103e47c886f50599cffe35c707.webp(
) 6. Используйте calldata вместо memory
Переменные, объявленные в параметрах функции, могут храниться в calldata или memory. Основное различие между ними заключается в том, что memory может быть изменен функцией, тогда как calldata является неизменяемым.
Запомните этот принцип: если параметры функции являются только для чтения, следует предпочитать использование calldata вместо memory. Это поможет избежать ненужных операций копирования из calldata функции в memory.
( 7. Постарайтесь использовать ключевые слова Constant/Immutable.
Константные/Неизменяемые переменные не хранятся в хранилище контракта. Эти переменные вычисляются во время компиляции и хранятся в байт-коде контракта. Таким образом, их стоимость доступа значительно ниже по сравнению с хранилищем, рекомендуется использовать ключевые слова Constant или Immutable, когда это возможно.
![Оптимизация газа для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp###
8. Используйте Unchecked, чтобы гарантировать отсутствие переполнения/недополнения.
Когда разработчики могут убедиться, что арифметические операции не приведут к переполнению или недополнению, они могут использовать ключевое слово unchecked, введенное в Solidity v0.8.0, чтобы избежать избыточной проверки на переполнение или недополнение, тем самым сэкономив затраты на газ.
Кроме того, в версиях компилятора 0.8.0 и выше больше не требуется использовать библиотеку SafeMath, так как в самом компиляторе уже встроены функции защиты от переполнения и недополнения.
( 9. Оптимизатор
Код модификатора встроен в изменённую функцию, и каждый раз при использовании модификатора его код копируется. Это увеличивает размер байт-кода и повышает расход газа. Оптимизацией является рефакторинг логики в внутреннюю функцию, что позволяет повторно использовать эту внутреннюю функцию в модификаторе, что может уменьшить размер байт-кода и снизить стоимость газа.
![Оптимизация газа для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
10. Оптимизация короткого замыкания
Для || и && операторов логические операции будут выполнять короткое замыкание, то есть если первое условие уже может определить результат логического выражения, второе условие не будет оцениваться.
Для оптимизации потребления газа следует разместить условия с низкой стоимостью вычислений в начале, что позволит, возможно, пропустить дорогостоящие вычисления.
Дополнительные общие рекомендации
1.Удалить бесполезный код
Если в смарт-контракте есть неиспользуемые функции или переменные, рекомендуется их удалить. Это самый прямой способ снизить стоимость развертывания контракта и сохранить его небольшой объем.
Вот некоторые полезные советы:
Используйте самые эффективные алгоритмы для вычислений. Если в смарт-контракте напрямую используются результаты некоторых расчетов, то следует исключить эти избыточные вычислительные процессы. По сути, любые неиспользуемые вычисления должны быть удалены.
В Эфире разработчики могут получать Gas награды, освобождая пространство для хранения. Если переменная больше не нужна, следует использовать ключевое слово delete для ее удаления или установить ее в значение по умолчанию.
Оптимизация циклов: избегайте высокозатратных циклических операций, старайтесь объединять циклы и выносить повторные вычисления за пределы тела цикла.
( 2. Использование предкомпилированных смарт-контрактов
Предварительно скомпилированные контракты предоставляют сложные библиотечные функции, такие как операции шифрования и хеширования. Поскольку код не выполняется на EVM, а запускается локально на клиентском узле, требуется меньше газа. Использование предварительно скомпилированных контрактов может сэкономить газ за счет снижения вычислительной нагрузки, необходимой для выполнения смарт-контрактов.
Примеры предкомпилированных контрактов включают алгоритм цифровой подписи на основе эллиптической кривой )ECDSA### и хеш-алгоритм SHA2-256. Используя эти предкомпилированные контракты в смарт-контрактах, разработчики могут снизить стоимость газа и повысить эффективность работы приложений.
![Газовые оптимизации смарт-контрактов Ethereum: 10 лучших практик]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 3.Использование встроенного ассемблера
Встраиваемая ассемблер(in-line assembly) позволяет разработчикам писать низкоуровневый, но эффективный код, который может выполняться непосредственно EVM, без необходимости использовать дорогостоящие операции Solidity. Встраиваемая ассемблер также позволяет более точно контролировать использование памяти и хранилища, что further снижает затраты на газ. Кроме того, встраиваемая ассемблер может выполнять некоторые сложные операции, которые трудно реализовать только с помощью Solidity, предоставляя больше гибкости для оптимизации потребления газа.
Однако использование встроенного ассемблера также может представлять риск и легко привести к ошибкам. Поэтому следует использовать его с осторожностью, только опытным разработчикам.
4. Использование решений второго уровня
Использование решений Layer 2 может снизить объем данных, которые необходимо хранить и обрабатывать в сети Ethereum.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Руководство по оптимизации Gas для смарт-контрактов Ethereum
Руководство по оптимизации Gas для смарт-контрактов Ethereum
Газовые расходы сети Ethereum всегда были общей проблемой для разработчиков и пользователей, особенно в периоды перегрузки сети. В часы пик пользователи часто вынуждены платить крайне высокие транзакционные сборы. Поэтому оптимизация газовых расходов на этапе разработки смарт-контрактов имеет решающее значение. Оптимизация расхода газа не только может эффективно снизить транзакционные затраты, но и повысить эффективность транзакций, обеспечивая пользователям более экономичный и эффективный опыт использования блокчейна.
В данной статье будет рассмотрена механика Gas-стоимости Эфирной виртуальной машины (EVM), ключевые концепции оптимизации Gas-стоимости, а также лучшие практики оптимизации Gas-стоимости при разработке смарт-контрактов. Надеемся, что эти материалы смогут вдохновить разработчиков и предоставить практическую помощь, а также помогут обычным пользователям лучше понять, как работают Gas-расходы EVM, в целях совместного решения проблем в экосистеме блокчейна.
Введение в механизм Gas-оплат EVM
В сетях, совместимых с EVM, "Gas" является единицей измерения вычислительных мощностей, необходимых для выполнения определённых операций.
В структуре EVM расходы на газ делятся на три части: выполнение операций, вызовы внешних сообщений и чтение/запись в память и хранилище.
Поскольку выполнение каждой транзакции требует вычислительных ресурсов, взимается определенная плата для предотвращения бесконечных циклов и отказа в обслуживании (DoS) атак. Плата, необходимая для завершения транзакции, называется "Gas-оплата".
С момента вступления в силу лондонского хардфорка EIP-1559( ), стоимость газа рассчитывается по следующей формуле:
Газовая плата = единицы газа, использованные * (базовая плата + плата за приоритет)
Базовая плата будет уничтожена, а приоритетная плата будет использоваться в качестве стимула, чтобы побудить валидаторов добавлять транзакции в блокчейн. Установка более высокой приоритетной платы при отправке транзакции может увеличить вероятность включения транзакции в следующий блок. Это похоже на "чаевые", которые пользователи платят валидаторам.
1. Понимание оптимизации Gas в EVM
Когда смарт-контракты компилируются с помощью Solidity, контракт преобразуется в серию "операционных кодов", то есть opcodes.
Любая последовательность операций (, например, создание контракта, выполнение вызовов сообщений, доступ к хранилищу аккаунта и выполнение операций на виртуальной машине ) имеет признанную стоимость потребления газа, эти затраты зафиксированы в желтой книге Ethereum.
После нескольких изменений в EIP, стоимость газа для некоторых операций была скорректирована и может отличаться от указанной в желтой книге.
2.Основные концепции оптимизации газа
Основная идея оптимизации газа заключается в том, чтобы приоритизировать операции с высокой стоимостью эффективности на блокчейне EVM, избегая операций с высокими затратами на газ.
В EVM следующие операции имеют низкую стоимость:
Операции с высокой стоимостью включают:
Оптимизация затрат на газ EVM: лучшие практики
Основываясь на вышеупомянутых основных концепциях, мы составили список лучших практик по оптимизации Gas-расходов для сообщества разработчиков. Следуя этим практикам, разработчики могут снизить потребление Gas смарт-контрактами, уменьшить затраты на транзакции и создать более эффективные и удобные для пользователей приложения.
1. Старайтесь уменьшить использование хранилища
В Solidity хранилище ( является ограниченным ресурсом, потребление газа которого значительно выше, чем у памяти ). Каждый раз, когда смарт-контракт читает или записывает данные из хранилища, возникают высокие затраты на газ.
Согласно определению в желтой книге Ethereum, стоимость операций хранения более чем в 100 раз выше, чем стоимость операций с памятью. Например, команды OPcodesmload и mstore потребляют всего 3 единицы газа, в то время как операции хранения, такие как sload и sstore, даже в самых идеальных условиях требуют как минимум 100 единиц.
Методы ограничения использования хранилища включают:
( 2.Упаковка переменных
Количество Storage slot), используемого в смарт-контрактах, и способ, которым разработчик представляет данные, будут значительно влиять на потребление Gas.
Компилятор Solidity упаковывает последовательные переменные хранения в процессе компиляции и использует 32-байтовый слот хранения в качестве базовой единицы хранения переменных. Упаковка переменных означает разумное размещение переменных, позволяющее нескольким переменным поместиться в одном слоте хранения.
С помощью этого изменения разработчики могут сэкономить 20 000 единиц газа ###, поскольку для хранения неиспользуемого слота хранения требуется 20 000 газа (, но теперь нужно всего два слота хранения.
Поскольку каждый слот хранения потребляет газ, упаковка переменных оптимизирует использование газа, уменьшая количество необходимых слотов хранения.
![Gas оптимизация смарт-контрактов Ethereum: десять лучших практик])https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp(
) 3.Оптимизация типов данных
Переменная может быть представлена разными типами данных, но стоимость операций с разными типами данных также различна. Выбор подходящего типа данных помогает оптимизировать использование газа.
Например, в Solidity целые числа можно разделить на разные размеры: uint8, uint16, uint32 и т.д. Поскольку EVM выполняет операции с единицами по 256 бит, использование uint8 означает, что EVM сначала должен преобразовать его в uint256, а это преобразование потребует дополнительных затрат газа.
С точки зрения отдельных переменных, использование uint256 дешевле, чем uint8. Однако, если используется оптимизация упаковки переменных, ситуация меняется. Если разработчик сможет упаковать четыре переменные uint8 в один слот хранения, то общая стоимость их итерации будет ниже, чем у четырех переменных uint256. Таким образом, смарт-контракт сможет читать и записывать один слот хранения и помещать четыре переменные uint8 в память/хранение за одну операцию.
4. Использование переменных фиксированного размера вместо динамических переменных
Если данные могут быть ограничены 32 байтами, рекомендуется использовать тип данных bytes32 вместо bytes или strings. Как правило, переменные фиксированного размера потребляют меньше газа, чем переменные переменного размера. Если длина байтов может быть ограничена, старайтесь выбирать минимальную длину от bytes1 до bytes32.
( 5.Отображения и массивы
Списки данных Solidity могут быть представлены двумя типами данных: массивами ) Arrays ### и отображениями ### Mappings (, но их синтаксис и структура совершенно разные.
В большинстве случаев отображение более эффективно и менее затратно, однако массивы обладают итеративностью и поддерживают упаковку типов данных. Поэтому рекомендуется в первую очередь использовать отображение при управлении списками данных, если нет необходимости в итерации или если упаковка типов данных может оптимизировать потребление Gas.
![Оптимизация Gas для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-5f3d7e103e47c886f50599cffe35c707.webp(
) 6. Используйте calldata вместо memory
Переменные, объявленные в параметрах функции, могут храниться в calldata или memory. Основное различие между ними заключается в том, что memory может быть изменен функцией, тогда как calldata является неизменяемым.
Запомните этот принцип: если параметры функции являются только для чтения, следует предпочитать использование calldata вместо memory. Это поможет избежать ненужных операций копирования из calldata функции в memory.
( 7. Постарайтесь использовать ключевые слова Constant/Immutable.
Константные/Неизменяемые переменные не хранятся в хранилище контракта. Эти переменные вычисляются во время компиляции и хранятся в байт-коде контракта. Таким образом, их стоимость доступа значительно ниже по сравнению с хранилищем, рекомендуется использовать ключевые слова Constant или Immutable, когда это возможно.
![Оптимизация газа для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp###
8. Используйте Unchecked, чтобы гарантировать отсутствие переполнения/недополнения.
Когда разработчики могут убедиться, что арифметические операции не приведут к переполнению или недополнению, они могут использовать ключевое слово unchecked, введенное в Solidity v0.8.0, чтобы избежать избыточной проверки на переполнение или недополнение, тем самым сэкономив затраты на газ.
Кроме того, в версиях компилятора 0.8.0 и выше больше не требуется использовать библиотеку SafeMath, так как в самом компиляторе уже встроены функции защиты от переполнения и недополнения.
( 9. Оптимизатор
Код модификатора встроен в изменённую функцию, и каждый раз при использовании модификатора его код копируется. Это увеличивает размер байт-кода и повышает расход газа. Оптимизацией является рефакторинг логики в внутреннюю функцию, что позволяет повторно использовать эту внутреннюю функцию в модификаторе, что может уменьшить размер байт-кода и снизить стоимость газа.
![Оптимизация газа для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
10. Оптимизация короткого замыкания
Для || и && операторов логические операции будут выполнять короткое замыкание, то есть если первое условие уже может определить результат логического выражения, второе условие не будет оцениваться.
Для оптимизации потребления газа следует разместить условия с низкой стоимостью вычислений в начале, что позволит, возможно, пропустить дорогостоящие вычисления.
Дополнительные общие рекомендации
1.Удалить бесполезный код
Если в смарт-контракте есть неиспользуемые функции или переменные, рекомендуется их удалить. Это самый прямой способ снизить стоимость развертывания контракта и сохранить его небольшой объем.
Вот некоторые полезные советы:
Используйте самые эффективные алгоритмы для вычислений. Если в смарт-контракте напрямую используются результаты некоторых расчетов, то следует исключить эти избыточные вычислительные процессы. По сути, любые неиспользуемые вычисления должны быть удалены.
В Эфире разработчики могут получать Gas награды, освобождая пространство для хранения. Если переменная больше не нужна, следует использовать ключевое слово delete для ее удаления или установить ее в значение по умолчанию.
Оптимизация циклов: избегайте высокозатратных циклических операций, старайтесь объединять циклы и выносить повторные вычисления за пределы тела цикла.
( 2. Использование предкомпилированных смарт-контрактов
Предварительно скомпилированные контракты предоставляют сложные библиотечные функции, такие как операции шифрования и хеширования. Поскольку код не выполняется на EVM, а запускается локально на клиентском узле, требуется меньше газа. Использование предварительно скомпилированных контрактов может сэкономить газ за счет снижения вычислительной нагрузки, необходимой для выполнения смарт-контрактов.
Примеры предкомпилированных контрактов включают алгоритм цифровой подписи на основе эллиптической кривой )ECDSA### и хеш-алгоритм SHA2-256. Используя эти предкомпилированные контракты в смарт-контрактах, разработчики могут снизить стоимость газа и повысить эффективность работы приложений.
![Газовые оптимизации смарт-контрактов Ethereum: 10 лучших практик]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 3.Использование встроенного ассемблера
Встраиваемая ассемблер(in-line assembly) позволяет разработчикам писать низкоуровневый, но эффективный код, который может выполняться непосредственно EVM, без необходимости использовать дорогостоящие операции Solidity. Встраиваемая ассемблер также позволяет более точно контролировать использование памяти и хранилища, что further снижает затраты на газ. Кроме того, встраиваемая ассемблер может выполнять некоторые сложные операции, которые трудно реализовать только с помощью Solidity, предоставляя больше гибкости для оптимизации потребления газа.
Однако использование встроенного ассемблера также может представлять риск и легко привести к ошибкам. Поэтому следует использовать его с осторожностью, только опытным разработчикам.
4. Использование решений второго уровня
Использование решений Layer 2 может снизить объем данных, которые необходимо хранить и обрабатывать в сети Ethereum.
как роллапы, сайдчейны