Руководство по оптимизации газовых сборов смарт-контрактов Ethereum
Газовые сборы в основной сети Ethereum всегда были проблемой, особенно это проявляется во время перегрузки сети. В пиковые моменты пользователи часто вынуждены платить очень высокие транзакционные сборы. Поэтому оптимизация газовых сборов на этапе разработки смарт-контрактов имеет важное значение. Оптимизация потребления газа не только эффективно снижает затраты на транзакции, но и повышает эффективность транзакций, обеспечивая пользователям более экономичный и эффективный опыт работы с блокчейном.
В данной статье будет рассмотрена механика расходов на газ Эфира (EVM), основные концепции оптимизации расходов на газ, а также лучшие практики оптимизации расходов на газ при разработке смарт-контрактов. Надеемся, что эти материалы смогут вдохновить разработчиков и предоставить практическую помощь, а также помочь обычным пользователям лучше понять, как работают расходы на газ в EVM, чтобы вместе справляться с вызовами в экосистеме блокчейна.
Введение в механизм Gas-стоимости EVM
В совместимых с EVM сетях "Gas" является единицей измерения вычислительной мощности, необходимой для выполнения определенных операций.
В структуре EVM потребление газа делится на три части: выполнение операций, вызовы внешних сообщений и чтение/запись в память и хранилище.
Поскольку выполнение каждой транзакции требует вычислительных ресурсов, взимается определенная плата для предотвращения бесконечных циклов и атак拒绝服务(DoS). Плата, необходимая для завершения транзакции, называется "Gas费".
С момента вступления в силу Лондонского хардфорка EIP-1559( ), газовые сборы рассчитываются по следующей формуле:
Плата за газ = единицы газа, использованные * (базовая плата + плата за приоритет)
Базовая плата будет уничтожена, а плата за приоритет будет использоваться в качестве стимула, чтобы побудить валидаторов добавлять транзакции в блокчейн. Установка более высокой платы за приоритет при отправке транзакции может увеличить вероятность включения транзакции в следующий блок. Это похоже на "чаевые", которые пользователь платит валидатору.
1. Понимание оптимизации Gas в EVM
Когда вы компилируете смарт-контракты с помощью Solidity, контракт преобразуется в ряд "операционных кодов", то есть opcodes.
Любая часть кода операции (, например, создание контракта, выполнение вызова сообщений, доступ к хранилищу аккаунта и выполнение операций на виртуальной машине ) имеет общепринятую стоимость потребления газа, эти расходы зафиксированы в желтой книге Ethereum.
После нескольких изменений EIP, стоимость газа для некоторых операций была скорректирована и может отличаться от указанной в жёлтой книге.
2.Основные концепции оптимизации газа
Основная идея оптимизации Gas заключается в том, чтобы в блокчейне EVM приоритизировать операции с высокой стоимостью эффективности и избегать операций с дорогими затратами Gas.
В EVM следующие операции имеют низкую стоимость:
Чтение и запись переменных в памяти
Чтение констант и неизменяемых переменных
Чтение и запись локальных переменных
Чтение переменной calldata, например, массива и структуры calldata
Внутренний вызов функций
Дорогие операции включают:
Чтение и запись состояния переменных, хранящихся в смарт-контрактах
Вызов внешних функций
Циклическая операция
Оптимизация затрат на газ EVM: лучшие практики
Основываясь на вышеупомянутых основных концепциях, мы подготовили для сообщества разработчиков список лучших практик по оптимизации Gas-расходов. Следуя этим практикам, разработчики могут снизить расход Gas для смарт-контрактов, сократить затраты на транзакции и создать более эффективные и удобные для пользователей приложения.
1. Старайтесь минимизировать использование хранилища
В Solidity, Storage( хранение) является ограниченным ресурсом, его расход газа значительно выше, чем у Memory( памяти). Каждый раз, когда смарт-контракт читает или записывает данные из хранилища, возникают высокие затраты на газ.
Согласно определению из Жёлтой книги Ethereum, стоимость операций хранения более чем в 100 раз выше, чем стоимость операций с памятью. Например, инструкции OPcodesmload и mstore расходуют всего 3 единицы Газ, тогда как операции хранения, такие как sload и sstore, даже в самых идеальных условиях, требуют как минимум 100 единиц.
Методы ограничения использования хранилища включают:
Хранить непостоянные данные в памяти
Сокращение количества изменений в хранилище: сохраняя промежуточные результаты в памяти и распределяя результаты переменным хранилища только после завершения всех вычислений.
2. Упаковка переменных
Количество слотов хранения (, используемых в смарт-контрактах, а также способ, которым разработчики представляют данные, значительно влияет на потребление газа.
Компилятор Solidity упаковывает последовательные переменные хранения в процессе компиляции и использует 32-байтовый слот хранения в качестве базовой единицы хранения переменных. Упаковка переменных означает разумное распределение переменных, позволяющее нескольким переменным поместиться в одном слоте хранения.
С помощью этой настройки разработчики могут сэкономить 20 000 единиц газа ) для хранения неиспользуемого слота хранения, который требует 20 000 газа (, но теперь требуется только два слота хранения.
Поскольку каждый слот хранения потребляет газ, упаковка переменных оптимизирует использование газа, уменьшая количество необходимых слотов хранения.
![Оптимизация Gas для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp(
) 3. Оптимизация типов данных
Переменная может быть представлена различными типами данных, но стоимость операций для разных типов данных также различна. Выбор подходящего типа данных помогает оптимизировать использование газа.
Например, в Solidity целые числа могут быть разбиты на различные размеры: uint8, uint16, uint32 и т.д. Поскольку EVM выполняет операции с размером 256 бит, использование uint8 означает, что EVM сначала должен преобразовать его в uint256, и это преобразование потребует дополнительных затрат на Gas.
На первый взгляд использование uint256 дешевле, чем uint8. Однако, если использовать предложенную ранее оптимизацию упаковки переменных, ситуация меняется. Если разработчик сможет упаковать четыре переменные uint8 в один слот памяти, то общая стоимость их итерации будет ниже, чем у четырех переменных uint256. Таким образом, смарт-контракт сможет прочитать и записать один слот памяти и поместить четыре переменные uint8 в память/хранилище за одно действие.
![Оптимизация Gas для смарт-контрактов Ethereum: десять лучших практик]###https://img-cdn.gateio.im/webp-social/moments-55fcdb765912ef9cd238c46b1d248cff.webp(
) 4. Используйте фиксированные переменные вместо динамических переменных
Если данные можно контролировать в пределах 32 байт, рекомендуется использовать тип данных bytes32 вместо bytes или strings. Как правило, переменные фиксированного размера потребляют меньше газа, чем переменные переменного размера. Если длину байтов можно ограничить, старайтесь выбирать минимальную длину от bytes1 до bytes32.
5. Отображения и массивы
Списки данных Solidity могут быть представлены двумя типами данных: массивы ###Arrays ( и отображения )Mappings (, но их синтаксис и структура совершенно различны.
В большинстве случаев отображения более эффективны и дешевле, но массивы имеют итеративность и поддерживают упаковку типов данных. Поэтому рекомендуется при управлении списками данных в первую очередь использовать отображения, если не требуется итерация или если можно оптимизировать потребление газа за счет упаковки типов данных.
![Оптимизация Gas для смарт-контрактов Ethereum: десять лучших практик])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, когда это возможно.
![Эфир смарт-контракты Gas оптимизация десять лучших практик]###https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp(
) 8. Используйте Unchecked, гарантируя, что переполнение/недостаток не произойдет
Когда разработчики могут быть уверены, что арифметические операции не приведут к переполнению или недостатку, они могут использовать ключевое слово unchecked, введенное в Solidity v0.8.0, чтобы избежать излишних проверок переполнения или недостатка, тем самым экономя Gas.
Кроме того, компиляторы версии 0.8.0 и выше больше не требуют использования библиотеки SafeMath, так как сам компилятор уже включает функции защиты от переполнения и недополнения.
9. Оптимизация модификатора
Код модификатора встраивается в изменённую функцию, и каждый раз при использовании модификатора его код копируется. Это увеличивает размер байт-кода и повышает потребление Gas.
Путем реорганизации логики в внутреннюю функцию _checkOwner###(, можно повторно использовать эту внутреннюю функцию в модификаторах, что позволяет уменьшить размер байт-кода и снизить стоимость газа.
![Ethereum смарт-контрактов Gas оптимизация десяти лучших практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp(
) 10. Оптимизация коротких замыканий
Для операторов || и && логические операции будут осуществлять короткое замыкание, то есть если первое условие уже может определить результат логического выражения, то второе условие не будет оцениваться.
Чтобы оптимизировать потребление газа, следует размещать условия с низкой стоимостью вычислений впереди, так можно пропустить дорогостоящие вычисления.
![Оптимизация Gas для смарт-контрактов Ethereum: 10 лучших практик]###https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp(
Дополнительные общие рекомендации
) 1. Удалить ненужный код
Если в смарт-контракте есть неиспользуемые функции или переменные, рекомендуется их удалить. Это самый прямой способ уменьшить стоимость развертывания контракта и поддерживать малый размер контракта.
Вот некоторые полезные советы:
Используйте самые эффективные алгоритмы для вычислений. Если в смарт-контракте напрямую используются результаты некоторых вычислений, то следует исключить эти избыточные вычислительные процессы. По сути, любые неиспользуемые вычисления должны быть удалены.
В Ethereum разработчики могут получать вознаграждение в виде газа, освобождая пространство для хранения. Если переменная больше не нужна, следует использовать ключевое слово delete для её удаления или установить её на значение по умолчанию.
Оптимизация циклов: избегайте затратных операций с циклами, объединяйте циклы по возможности и выносите повторяющиеся вычисления за пределы тела цикла.
2. Использование предкомпилированных смарт-контрактов
Предварительно скомпилированные контракты предоставляют сложные библиотечные функции, такие как шифрование и хэширование. Поскольку код не выполняется на EVM, а выполняется локально на клиентском узле, требуется меньше газа. Использование предварительно скомпилированных контрактов позволяет экономить газ, снижая вычислительные затраты на выполнение смарт-контрактов.
Примеры предкомпилированных смарт-контрактов включают алгоритм цифровой подписи на основе эллиптической кривой ###ECDSA( и хеш-алгоритм SHA2-256. Используя эти предкомпилированные контракты в смарт-контрактах, разработчики могут снизить затраты на Gas и повысить эффективность работы приложений.
! [10 лучших практик оптимизации газа для смарт-контрактов Ethereum])https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 3. Использование встроенного ассемблера
Встроенная ассемблер###in-line assembly( позволяет разработчикам писать низкоуровневый, но эффективный код, который может выполняться непосредственно EVM, без необходимости использования дорогостоящих операций Solidity. Встроенная ассемблер также позволяет более точно контролировать использование памяти и хранилища, что дополнительно снижает стоимость Gas. Кроме того, встроенная ассемблер может выполнять некоторые сложные операции, которые трудно реализовать только с использованием Solidity, предоставляя больше гибкости для оптимизации потребления Gas.
Однако использование встроенного ассемблера также может быть рискованным и подверженным ошибкам. Поэтому его следует использовать с осторожностью, только опытным разработчикам.
) 4. Использование решений второго уровня
Использование решений Layer 2 может уменьшить количество данных, которые необходимо хранить и вычислять в основной сети Ethereum.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
3
Репост
Поделиться
комментарий
0/400
SocialFiQueen
· 07-10 22:01
Всегда найдутся те, кто стиснув зубы, терпит Газ.
Посмотреть ОригиналОтветить0
LostBetweenChains
· 07-08 12:24
Слишком надоело, Газ как неудачники, которых срезают.
Посмотреть ОригиналОтветить0
ResearchChadButBroke
· 07-08 05:57
Когда же мы сможем не быть разыгранными людьми как лохов под высоким Газ?
Оптимизация Газовых сборов смарт-контрактов Ethereum: 15 советов для быстрого просмотра
Руководство по оптимизации газовых сборов смарт-контрактов Ethereum
Газовые сборы в основной сети Ethereum всегда были проблемой, особенно это проявляется во время перегрузки сети. В пиковые моменты пользователи часто вынуждены платить очень высокие транзакционные сборы. Поэтому оптимизация газовых сборов на этапе разработки смарт-контрактов имеет важное значение. Оптимизация потребления газа не только эффективно снижает затраты на транзакции, но и повышает эффективность транзакций, обеспечивая пользователям более экономичный и эффективный опыт работы с блокчейном.
В данной статье будет рассмотрена механика расходов на газ Эфира (EVM), основные концепции оптимизации расходов на газ, а также лучшие практики оптимизации расходов на газ при разработке смарт-контрактов. Надеемся, что эти материалы смогут вдохновить разработчиков и предоставить практическую помощь, а также помочь обычным пользователям лучше понять, как работают расходы на газ в EVM, чтобы вместе справляться с вызовами в экосистеме блокчейна.
Введение в механизм Gas-стоимости EVM
В совместимых с EVM сетях "Gas" является единицей измерения вычислительной мощности, необходимой для выполнения определенных операций.
В структуре EVM потребление газа делится на три части: выполнение операций, вызовы внешних сообщений и чтение/запись в память и хранилище.
Поскольку выполнение каждой транзакции требует вычислительных ресурсов, взимается определенная плата для предотвращения бесконечных циклов и атак拒绝服务(DoS). Плата, необходимая для завершения транзакции, называется "Gas费".
С момента вступления в силу Лондонского хардфорка EIP-1559( ), газовые сборы рассчитываются по следующей формуле:
Плата за газ = единицы газа, использованные * (базовая плата + плата за приоритет)
Базовая плата будет уничтожена, а плата за приоритет будет использоваться в качестве стимула, чтобы побудить валидаторов добавлять транзакции в блокчейн. Установка более высокой платы за приоритет при отправке транзакции может увеличить вероятность включения транзакции в следующий блок. Это похоже на "чаевые", которые пользователь платит валидатору.
1. Понимание оптимизации Gas в EVM
Когда вы компилируете смарт-контракты с помощью Solidity, контракт преобразуется в ряд "операционных кодов", то есть opcodes.
Любая часть кода операции (, например, создание контракта, выполнение вызова сообщений, доступ к хранилищу аккаунта и выполнение операций на виртуальной машине ) имеет общепринятую стоимость потребления газа, эти расходы зафиксированы в желтой книге Ethereum.
После нескольких изменений EIP, стоимость газа для некоторых операций была скорректирована и может отличаться от указанной в жёлтой книге.
2.Основные концепции оптимизации газа
Основная идея оптимизации Gas заключается в том, чтобы в блокчейне EVM приоритизировать операции с высокой стоимостью эффективности и избегать операций с дорогими затратами Gas.
В EVM следующие операции имеют низкую стоимость:
Дорогие операции включают:
Оптимизация затрат на газ EVM: лучшие практики
Основываясь на вышеупомянутых основных концепциях, мы подготовили для сообщества разработчиков список лучших практик по оптимизации Gas-расходов. Следуя этим практикам, разработчики могут снизить расход Gas для смарт-контрактов, сократить затраты на транзакции и создать более эффективные и удобные для пользователей приложения.
1. Старайтесь минимизировать использование хранилища
В Solidity, Storage( хранение) является ограниченным ресурсом, его расход газа значительно выше, чем у Memory( памяти). Каждый раз, когда смарт-контракт читает или записывает данные из хранилища, возникают высокие затраты на газ.
Согласно определению из Жёлтой книги Ethereum, стоимость операций хранения более чем в 100 раз выше, чем стоимость операций с памятью. Например, инструкции OPcodesmload и mstore расходуют всего 3 единицы Газ, тогда как операции хранения, такие как sload и sstore, даже в самых идеальных условиях, требуют как минимум 100 единиц.
Методы ограничения использования хранилища включают:
2. Упаковка переменных
Количество слотов хранения (, используемых в смарт-контрактах, а также способ, которым разработчики представляют данные, значительно влияет на потребление газа.
Компилятор Solidity упаковывает последовательные переменные хранения в процессе компиляции и использует 32-байтовый слот хранения в качестве базовой единицы хранения переменных. Упаковка переменных означает разумное распределение переменных, позволяющее нескольким переменным поместиться в одном слоте хранения.
С помощью этой настройки разработчики могут сэкономить 20 000 единиц газа ) для хранения неиспользуемого слота хранения, который требует 20 000 газа (, но теперь требуется только два слота хранения.
Поскольку каждый слот хранения потребляет газ, упаковка переменных оптимизирует использование газа, уменьшая количество необходимых слотов хранения.
![Оптимизация Gas для смарт-контрактов Ethereum: 10 лучших практик])https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp(
) 3. Оптимизация типов данных
Переменная может быть представлена различными типами данных, но стоимость операций для разных типов данных также различна. Выбор подходящего типа данных помогает оптимизировать использование газа.
Например, в Solidity целые числа могут быть разбиты на различные размеры: uint8, uint16, uint32 и т.д. Поскольку EVM выполняет операции с размером 256 бит, использование uint8 означает, что EVM сначала должен преобразовать его в uint256, и это преобразование потребует дополнительных затрат на Gas.
На первый взгляд использование uint256 дешевле, чем uint8. Однако, если использовать предложенную ранее оптимизацию упаковки переменных, ситуация меняется. Если разработчик сможет упаковать четыре переменные uint8 в один слот памяти, то общая стоимость их итерации будет ниже, чем у четырех переменных uint256. Таким образом, смарт-контракт сможет прочитать и записать один слот памяти и поместить четыре переменные uint8 в память/хранилище за одно действие.
![Оптимизация Gas для смарт-контрактов Ethereum: десять лучших практик]###https://img-cdn.gateio.im/webp-social/moments-55fcdb765912ef9cd238c46b1d248cff.webp(
) 4. Используйте фиксированные переменные вместо динамических переменных
Если данные можно контролировать в пределах 32 байт, рекомендуется использовать тип данных bytes32 вместо bytes или strings. Как правило, переменные фиксированного размера потребляют меньше газа, чем переменные переменного размера. Если длину байтов можно ограничить, старайтесь выбирать минимальную длину от bytes1 до bytes32.
5. Отображения и массивы
Списки данных Solidity могут быть представлены двумя типами данных: массивы ###Arrays ( и отображения )Mappings (, но их синтаксис и структура совершенно различны.
В большинстве случаев отображения более эффективны и дешевле, но массивы имеют итеративность и поддерживают упаковку типов данных. Поэтому рекомендуется при управлении списками данных в первую очередь использовать отображения, если не требуется итерация или если можно оптимизировать потребление газа за счет упаковки типов данных.
![Оптимизация Gas для смарт-контрактов Ethereum: десять лучших практик])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, когда это возможно.
![Эфир смарт-контракты Gas оптимизация десять лучших практик]###https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp(
) 8. Используйте Unchecked, гарантируя, что переполнение/недостаток не произойдет
Когда разработчики могут быть уверены, что арифметические операции не приведут к переполнению или недостатку, они могут использовать ключевое слово unchecked, введенное в Solidity v0.8.0, чтобы избежать излишних проверок переполнения или недостатка, тем самым экономя Gas.
Кроме того, компиляторы версии 0.8.0 и выше больше не требуют использования библиотеки SafeMath, так как сам компилятор уже включает функции защиты от переполнения и недополнения.
9. Оптимизация модификатора
Код модификатора встраивается в изменённую функцию, и каждый раз при использовании модификатора его код копируется. Это увеличивает размер байт-кода и повышает потребление Gas.
Путем реорганизации логики в внутреннюю функцию _checkOwner###(, можно повторно использовать эту внутреннюю функцию в модификаторах, что позволяет уменьшить размер байт-кода и снизить стоимость газа.
![Ethereum смарт-контрактов Gas оптимизация десяти лучших практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp(
) 10. Оптимизация коротких замыканий
Для операторов || и && логические операции будут осуществлять короткое замыкание, то есть если первое условие уже может определить результат логического выражения, то второе условие не будет оцениваться.
Чтобы оптимизировать потребление газа, следует размещать условия с низкой стоимостью вычислений впереди, так можно пропустить дорогостоящие вычисления.
![Оптимизация Gas для смарт-контрактов Ethereum: 10 лучших практик]###https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp(
Дополнительные общие рекомендации
) 1. Удалить ненужный код
Если в смарт-контракте есть неиспользуемые функции или переменные, рекомендуется их удалить. Это самый прямой способ уменьшить стоимость развертывания контракта и поддерживать малый размер контракта.
Вот некоторые полезные советы:
Используйте самые эффективные алгоритмы для вычислений. Если в смарт-контракте напрямую используются результаты некоторых вычислений, то следует исключить эти избыточные вычислительные процессы. По сути, любые неиспользуемые вычисления должны быть удалены.
В Ethereum разработчики могут получать вознаграждение в виде газа, освобождая пространство для хранения. Если переменная больше не нужна, следует использовать ключевое слово delete для её удаления или установить её на значение по умолчанию.
Оптимизация циклов: избегайте затратных операций с циклами, объединяйте циклы по возможности и выносите повторяющиеся вычисления за пределы тела цикла.
2. Использование предкомпилированных смарт-контрактов
Предварительно скомпилированные контракты предоставляют сложные библиотечные функции, такие как шифрование и хэширование. Поскольку код не выполняется на EVM, а выполняется локально на клиентском узле, требуется меньше газа. Использование предварительно скомпилированных контрактов позволяет экономить газ, снижая вычислительные затраты на выполнение смарт-контрактов.
Примеры предкомпилированных смарт-контрактов включают алгоритм цифровой подписи на основе эллиптической кривой ###ECDSA( и хеш-алгоритм SHA2-256. Используя эти предкомпилированные контракты в смарт-контрактах, разработчики могут снизить затраты на Gas и повысить эффективность работы приложений.
! [10 лучших практик оптимизации газа для смарт-контрактов Ethereum])https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 3. Использование встроенного ассемблера
Встроенная ассемблер###in-line assembly( позволяет разработчикам писать низкоуровневый, но эффективный код, который может выполняться непосредственно EVM, без необходимости использования дорогостоящих операций Solidity. Встроенная ассемблер также позволяет более точно контролировать использование памяти и хранилища, что дополнительно снижает стоимость Gas. Кроме того, встроенная ассемблер может выполнять некоторые сложные операции, которые трудно реализовать только с использованием Solidity, предоставляя больше гибкости для оптимизации потребления Gas.
Однако использование встроенного ассемблера также может быть рискованным и подверженным ошибкам. Поэтому его следует использовать с осторожностью, только опытным разработчикам.
) 4. Использование решений второго уровня
Использование решений Layer 2 может уменьшить количество данных, которые необходимо хранить и вычислять в основной сети Ethereum.