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