Практичний посібник з оптимізації Gas для смартконтрактів Ethereum
Газові витрати основної мережі Ethereum завжди були складною проблемою, особливо це стає очевидним під час завантаження мережі. У пікові періоди користувачам часто потрібно платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття охопить механізм витрат Gas в Ethereum Virtual Machine (EVM), основні поняття оптимізації витрат Gas, а також найкращі практики оптимізації витрат Gas під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як функціонують витрати Gas в EVM, щоб спільно справлятися з викликами в екосистемі блокчейну.
Вступ до механізму газових витрат EVM
У мережах, сумісних з EVM, "Gas" є одиницею вимірювання обчислювальної потужності, необхідної для виконання конкретних операцій.
У структурному розташуванні EVM, споживання Gas ділиться на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті і зберігання.
Оскільки виконання кожної транзакції вимагає обчислювальних ресурсів, стягується певна плата, щоб запобігти безкінечним циклам і атакам відмови в обслуговуванні (DoS). Вартість, необхідна для завершення транзакції, називається "Gas плата".
З моменту набрання чинності лондонським хард-форком EIP-1559( ), плата за газ розраховується за наступною формулою:
Gas-кошти = використані одиниці Gas * ( базова плата + пріоритетна плата )
Базовий збір буде знищено, а пріоритетний збір буде використаний як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час відправки транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чайові", які користувачі сплачують валідаторам.
Розуміння оптимізації Gas в EVM
Коли смартконтракт компілюється за допомогою Solidity, контракт перетворюється на серію "операційних кодів", тобто opcodes.
Будь-яка частина коду операцій (, наприклад, створення смартконтракту, виконання викликів повідомлень, доступ до зберігання рахунків та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після численних змін EIP, деякі коди операцій отримали коригування витрат Gas, що може відрізнятися від жовтої книги.
Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на EVM блокчейні, уникаючи дорогих за Gas операцій.
У EVM наступні операції мають нижчу вартість:
Читання та запис змінних пам'яті
Читання констант та незмінних змінних
Читання та запис локальних змінних
Читати змінну calldata, наприклад, масиви та структури calldata
Виклик внутрішньої функції
Операції з високими витратами включають:
Читати та записувати стан змінних, що зберігаються в сховищі смартконтракту
Виклик зовнішніх функцій
Циклічна операція
Оптимізація витрат газу EVM: найкращі практики
На основі вищезазначених основних концепцій ми підготували список кращих практик оптимізації витрат на Gas для спільноти розробників. Дотримуючись цих практик, розробники можуть знизити споживання Gas смартконтрактами, зменшити витрати на транзакції та створити більш ефективні та зручні програми.
1. Намагайтеся зменшити використання сховища
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання газу значно перевищує Memory( пам'ять). Кожен раз, коли смартконтракт читає або записує дані зі сховища, виникають високі витрати газу.
Згідно з визначенням жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, вартують щонайменше 100 одиниць.
Обмеження способів використання зберігання включають:
Зберігати непостійні дані в пам'яті
Зменшити кількість змін у сховищі: зберігати проміжні результати в пам'яті, а потім, коли всі обчислення завершено, розподілити результати на змінні сховища.
2. Упаковка змінних
Кількість сховищ, які використовуються в смартконтрактах, таких як Storage slot(, а також спосіб, яким розробники представляють дані, значно вплине на витрати Gas.
Компіллятор Solidity під час компіляції упаковує послідовні змінні зберігання та використовує 32-байтовий слот зберігання як базову одиницю для зберігання змінних. Упаковка змінних означає раціональну організацію змінних, щоб кілька змінних могли поміститися в один слот зберігання.
Завдяки цій детальній корекції, розробники можуть заощадити 20 000 одиниць Gas. Зберігання невикористаного сховища вимагає 20 000 Gas), але тепер потрібно лише два сховища.
Оскільки кожен слот зберігання споживає газ, упаковка змінних оптимізує використання газу, зменшуючи кількість необхідних слотів зберігання.
( 3. Оптимізація типів даних
Змінна може бути представлена кількома різними типами даних, але вартість операцій, пов'язаних з різними типами даних, також різна. Вибір відповідного типу даних допомагає оптимізувати використання Gas.
Наприклад, у Solidity цілі числа можуть бути поділені на різні розміри: uint8, uint16, uint32 тощо. Оскільки EVM виконує операції по 256 біт, використання uint8 означає, що EVM спочатку повинна перетворити його на uint256, а це перетворення додатково витрачає Газ.
Окремо, тут використання uint256 дешевше, ніж uint8. Проте, якщо використовувати оптимізацію упаковки змінних, яку ми раніше пропонували, то це буде інакше. Якщо розробники зможуть упакувати чотири змінні uint8 в один слот пам'яті, то загальна вартість ітерації їх буде нижчою, ніж у чотирьох змінних uint256. Таким чином, смартконтракти можуть читати і записувати один слот пам'яті, і за один раз помістити чотири змінні uint8 в пам'ять/сховище.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp###
( 4. Використання змінних фіксованого розміру замість динамічних змінних
Якщо дані можна контролювати в межах 32 байтів, рекомендується використовувати тип даних bytes32 замість bytes або strings. Загалом, змінні фіксованого розміру споживають менше газу, ніж змінні змінного розміру. Якщо довжину байтів можна обмежити, намагайтеся вибрати мінімальну довжину від bytes1 до bytes32.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-55fcdb765912ef9cd238c46b1d248cff.webp###
( 5. Відображення та масиви
Список даних Solidity може бути представлений двома типами даних: масивами ) Arrays ### та мапами ( Mappings ), але їхня синтаксис і структура кардинально відрізняються.
У більшості випадків мапи є більш ефективними та менш витратними, але масиви мають ітеративність і підтримують упаковку типів даних. Тому рекомендується віддавати перевагу мапам при управлінні списками даних, якщо не потрібно ітерувати або можна оптимізувати витрати газу за допомогою упаковки типів даних.
( 6. Використання calldata замість пам'яті
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Основна різниця між ними полягає в тому, що memory може бути змінена функцією, тоді як calldata є незмінною.
Пам'ятайте цей принцип: якщо параметри функції є тільки для читання, слід віддавати перевагу використанню calldata, а не memory. Це дозволяє уникнути непотрібних операцій копіювання з calldata функції до memory.
![Ethereum смартконтрактів Gas оптимізації десятка кращих практик])https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp###
( 7. Намагайтеся використовувати ключові слова Constant/Immutable якомога більше
Константні/незмінні змінні не зберігаються в сховищі контракту. Ці змінні обчислюються під час компіляції та зберігаються в байт-коді контракту. Тому їх вартість доступу значно нижча в порівнянні зі сховищем, рекомендується якомога більше використовувати ключові слова Constant або Immutable.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
( 8. Використовуйте Unchecked, щоб забезпечити відсутність переповнення/недостатності.
Коли розробники можуть бути впевнені, що арифметичні операції не призведуть до переповнення або недоповнення, вони можуть використовувати ключове слово unchecked, введене в Solidity v0.8.0, щоб уникнути зайвих перевірок переповнення або недоповнення, що економить витрати на газ.
Крім того, компілятори версії 0.8.0 та вище більше не потребують використання бібліотеки SafeMath, оскільки компілятор самостійно має вбудовані функції захисту від переповнень і недоповнень.
![Ethereum смартконтракти Gas оптимізації десятка найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp###
( 9. Оптимізація модифікатора
Код модифікатора вбудовується в змінену функцію, і щоразу, коли використовується модифікатор, його код копіюється. Це збільшує розмір байт-коду і підвищує витрати на Gas. Можна зменшити розмір байт-коду та знизити витрати на Gas, реорганізувавши логіку в внутрішню функцію, що дозволяє повторно використовувати цю внутрішню функцію в модифікаторі.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp###
( 10. Оптимізація короткого замикання
Щодо || та && операторів, логічні операції підлягають короткочасній оцінці, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не оцінюється.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, так можна пропустити обчислення з високою вартістю.
![Ethereum смартконтракти Gas оптимізації десятка найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a141884dcdcdc56faff12eee2601b7b7.webp###
Додаткові загальні рекомендації
( 1. Видалити непотрібний код
Якщо в контракті є не використані функції або змінні, рекомендується їх видалити. Це найпряміший спосіб зменшити витрати на розгортання контракту та зберегти малий обсяг контракту.
Ось кілька корисних порад:
Використовуйте найефективніший алгоритм для виконання обчислень. Якщо результати певних обчислень безпосередньо використовуються в контракті, тоді слід усунути ці зайві обчислювальні процеси. Власне, будь-які невикористовувані обчислення слід видалити.
В Ethereum розробники можуть отримувати винагороду Gas, звільняючи місце для зберігання. Якщо певна змінна більше не потрібна, слід використовувати ключове слово delete, щоб видалити її, або встановити за замовчуванням.
Оптимізація циклів: уникати витратних операцій циклу, по можливості об'єднувати цикли та виводити повторювані обчислення за межі тіла циклу.
) 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як шифрування та хешування. Оскільки код не виконується на EVM, а запускається на локальному вузлі клієнта, потрібно менше газу. Використання попередньо скомпільованих контрактів може заощадити газ, зменшуючи обсяги обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису на основі еліптичних кривих ###ECDSA### та хеш-алгоритм SHA2-256. Використовуючи ці попередньо скомпільовані смартконтракти в своїх смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи програм.
( 3. Використання вбудованого асемблерного коду
Вбудована асемблер)in-line assembly###дозволяє розробникам писати низькорівневий, але ефективний код, який може бути безпосередньо виконаний EVM, не використовуючи дорогі операції Solidity. Вбудована асемблер також дозволяє більш точно контролювати використання пам'яті та зберігання, що ще більше зменшує витрати на газ. Крім того, вбудована асемблер може виконувати деякі складні операції, які важко реалізувати лише за допомогою Solidity, надаючи більше гнучкості для оптимізації споживання газу.
Однак використання вбудованого асемблера також може нести ризики та дозволи
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 лайків
Нагородити
14
4
Поділіться
Прокоментувати
0/400
DaoGovernanceOfficer
· 23год тому
*зітхання* ще один пост про газ, який ігнорує дослідження масштабування l2...
Переглянути оригіналвідповісти на0
ApeShotFirst
· 23год тому
газ коштує так дорого, що я, мабуть, збанкрутіла.
Переглянути оригіналвідповісти на0
BottomMisser
· 23год тому
Оптимізація газу? Краще почекати ведмежий ринок.
Переглянути оригіналвідповісти на0
Rekt_Recovery
· 08-02 23:12
рв газові комісії... все ще відновлююсь після ПТСР 2021, не кажучи вже.
Ethereum смартконтракти Gas оптимізація повний посібник Падіння Вартість транзакції підвищення ефективності
Практичний посібник з оптимізації Gas для смартконтрактів Ethereum
Газові витрати основної мережі Ethereum завжди були складною проблемою, особливо це стає очевидним під час завантаження мережі. У пікові періоди користувачам часто потрібно платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття охопить механізм витрат Gas в Ethereum Virtual Machine (EVM), основні поняття оптимізації витрат Gas, а також найкращі практики оптимізації витрат Gas під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як функціонують витрати Gas в EVM, щоб спільно справлятися з викликами в екосистемі блокчейну.
Вступ до механізму газових витрат EVM
У мережах, сумісних з EVM, "Gas" є одиницею вимірювання обчислювальної потужності, необхідної для виконання конкретних операцій.
У структурному розташуванні EVM, споживання Gas ділиться на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті і зберігання.
Оскільки виконання кожної транзакції вимагає обчислювальних ресурсів, стягується певна плата, щоб запобігти безкінечним циклам і атакам відмови в обслуговуванні (DoS). Вартість, необхідна для завершення транзакції, називається "Gas плата".
З моменту набрання чинності лондонським хард-форком EIP-1559( ), плата за газ розраховується за наступною формулою:
Gas-кошти = використані одиниці Gas * ( базова плата + пріоритетна плата )
Базовий збір буде знищено, а пріоритетний збір буде використаний як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час відправки транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чайові", які користувачі сплачують валідаторам.
Розуміння оптимізації Gas в EVM
Коли смартконтракт компілюється за допомогою Solidity, контракт перетворюється на серію "операційних кодів", тобто opcodes.
Будь-яка частина коду операцій (, наприклад, створення смартконтракту, виконання викликів повідомлень, доступ до зберігання рахунків та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після численних змін EIP, деякі коди операцій отримали коригування витрат Gas, що може відрізнятися від жовтої книги.
Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на EVM блокчейні, уникаючи дорогих за Gas операцій.
У EVM наступні операції мають нижчу вартість:
Операції з високими витратами включають:
Оптимізація витрат газу EVM: найкращі практики
На основі вищезазначених основних концепцій ми підготували список кращих практик оптимізації витрат на Gas для спільноти розробників. Дотримуючись цих практик, розробники можуть знизити споживання Gas смартконтрактами, зменшити витрати на транзакції та створити більш ефективні та зручні програми.
1. Намагайтеся зменшити використання сховища
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання газу значно перевищує Memory( пам'ять). Кожен раз, коли смартконтракт читає або записує дані зі сховища, виникають високі витрати газу.
Згідно з визначенням жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, вартують щонайменше 100 одиниць.
Обмеження способів використання зберігання включають:
2. Упаковка змінних
Кількість сховищ, які використовуються в смартконтрактах, таких як Storage slot(, а також спосіб, яким розробники представляють дані, значно вплине на витрати Gas.
Компіллятор Solidity під час компіляції упаковує послідовні змінні зберігання та використовує 32-байтовий слот зберігання як базову одиницю для зберігання змінних. Упаковка змінних означає раціональну організацію змінних, щоб кілька змінних могли поміститися в один слот зберігання.
Завдяки цій детальній корекції, розробники можуть заощадити 20 000 одиниць Gas. Зберігання невикористаного сховища вимагає 20 000 Gas), але тепер потрібно лише два сховища.
Оскільки кожен слот зберігання споживає газ, упаковка змінних оптимізує використання газу, зменшуючи кількість необхідних слотів зберігання.
( 3. Оптимізація типів даних
Змінна може бути представлена кількома різними типами даних, але вартість операцій, пов'язаних з різними типами даних, також різна. Вибір відповідного типу даних допомагає оптимізувати використання Gas.
Наприклад, у Solidity цілі числа можуть бути поділені на різні розміри: uint8, uint16, uint32 тощо. Оскільки EVM виконує операції по 256 біт, використання uint8 означає, що EVM спочатку повинна перетворити його на uint256, а це перетворення додатково витрачає Газ.
Окремо, тут використання uint256 дешевше, ніж uint8. Проте, якщо використовувати оптимізацію упаковки змінних, яку ми раніше пропонували, то це буде інакше. Якщо розробники зможуть упакувати чотири змінні uint8 в один слот пам'яті, то загальна вартість ітерації їх буде нижчою, ніж у чотирьох змінних uint256. Таким чином, смартконтракти можуть читати і записувати один слот пам'яті, і за один раз помістити чотири змінні uint8 в пам'ять/сховище.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp###
( 4. Використання змінних фіксованого розміру замість динамічних змінних
Якщо дані можна контролювати в межах 32 байтів, рекомендується використовувати тип даних bytes32 замість bytes або strings. Загалом, змінні фіксованого розміру споживають менше газу, ніж змінні змінного розміру. Якщо довжину байтів можна обмежити, намагайтеся вибрати мінімальну довжину від bytes1 до bytes32.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-55fcdb765912ef9cd238c46b1d248cff.webp###
( 5. Відображення та масиви
Список даних Solidity може бути представлений двома типами даних: масивами ) Arrays ### та мапами ( Mappings ), але їхня синтаксис і структура кардинально відрізняються.
У більшості випадків мапи є більш ефективними та менш витратними, але масиви мають ітеративність і підтримують упаковку типів даних. Тому рекомендується віддавати перевагу мапам при управлінні списками даних, якщо не потрібно ітерувати або можна оптимізувати витрати газу за допомогою упаковки типів даних.
( 6. Використання calldata замість пам'яті
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Основна різниця між ними полягає в тому, що memory може бути змінена функцією, тоді як calldata є незмінною.
Пам'ятайте цей принцип: якщо параметри функції є тільки для читання, слід віддавати перевагу використанню calldata, а не memory. Це дозволяє уникнути непотрібних операцій копіювання з calldata функції до memory.
![Ethereum смартконтрактів Gas оптимізації десятка кращих практик])https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp###
( 7. Намагайтеся використовувати ключові слова Constant/Immutable якомога більше
Константні/незмінні змінні не зберігаються в сховищі контракту. Ці змінні обчислюються під час компіляції та зберігаються в байт-коді контракту. Тому їх вартість доступу значно нижча в порівнянні зі сховищем, рекомендується якомога більше використовувати ключові слова Constant або Immutable.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
( 8. Використовуйте Unchecked, щоб забезпечити відсутність переповнення/недостатності.
Коли розробники можуть бути впевнені, що арифметичні операції не призведуть до переповнення або недоповнення, вони можуть використовувати ключове слово unchecked, введене в Solidity v0.8.0, щоб уникнути зайвих перевірок переповнення або недоповнення, що економить витрати на газ.
Крім того, компілятори версії 0.8.0 та вище більше не потребують використання бібліотеки SafeMath, оскільки компілятор самостійно має вбудовані функції захисту від переповнень і недоповнень.
![Ethereum смартконтракти Gas оптимізації десятка найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp###
( 9. Оптимізація модифікатора
Код модифікатора вбудовується в змінену функцію, і щоразу, коли використовується модифікатор, його код копіюється. Це збільшує розмір байт-коду і підвищує витрати на Gas. Можна зменшити розмір байт-коду та знизити витрати на Gas, реорганізувавши логіку в внутрішню функцію, що дозволяє повторно використовувати цю внутрішню функцію в модифікаторі.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp###
( 10. Оптимізація короткого замикання
Щодо || та && операторів, логічні операції підлягають короткочасній оцінці, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не оцінюється.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, так можна пропустити обчислення з високою вартістю.
![Ethereum смартконтракти Gas оптимізації десятка найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a141884dcdcdc56faff12eee2601b7b7.webp###
Додаткові загальні рекомендації
( 1. Видалити непотрібний код
Якщо в контракті є не використані функції або змінні, рекомендується їх видалити. Це найпряміший спосіб зменшити витрати на розгортання контракту та зберегти малий обсяг контракту.
Ось кілька корисних порад:
Використовуйте найефективніший алгоритм для виконання обчислень. Якщо результати певних обчислень безпосередньо використовуються в контракті, тоді слід усунути ці зайві обчислювальні процеси. Власне, будь-які невикористовувані обчислення слід видалити.
В Ethereum розробники можуть отримувати винагороду Gas, звільняючи місце для зберігання. Якщо певна змінна більше не потрібна, слід використовувати ключове слово delete, щоб видалити її, або встановити за замовчуванням.
Оптимізація циклів: уникати витратних операцій циклу, по можливості об'єднувати цикли та виводити повторювані обчислення за межі тіла циклу.
) 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як шифрування та хешування. Оскільки код не виконується на EVM, а запускається на локальному вузлі клієнта, потрібно менше газу. Використання попередньо скомпільованих контрактів може заощадити газ, зменшуючи обсяги обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису на основі еліптичних кривих ###ECDSA### та хеш-алгоритм SHA2-256. Використовуючи ці попередньо скомпільовані смартконтракти в своїх смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи програм.
( 3. Використання вбудованого асемблерного коду
Вбудована асемблер)in-line assembly###дозволяє розробникам писати низькорівневий, але ефективний код, який може бути безпосередньо виконаний EVM, не використовуючи дорогі операції Solidity. Вбудована асемблер також дозволяє більш точно контролювати використання пам'яті та зберігання, що ще більше зменшує витрати на газ. Крім того, вбудована асемблер може виконувати деякі складні операції, які важко реалізувати лише за допомогою Solidity, надаючи більше гнучкості для оптимізації споживання газу.
Однак використання вбудованого асемблера також може нести ризики та дозволи