Посібник з оптимізації Gas для смартконтрактів: 10 основних практик для зниження вартості транзакції

Проблема з витратами на Gas в основній мережі Ethereum завжди викликала велику увагу, особливо під час заторів у мережі. У пікові години користувачам часто доводиться платити дорогі витрати на транзакції. Тому оптимізація витрат на Gas на етапі розробки смартконтрактів є вкрай важливою. Оптимізація споживання Gas не тільки може ефективно знизити вартість транзакцій, але й підвищити ефективність транзакцій, надаючи користувачам більш економічний і ефективний досвід використання блокчейну.

Ця стаття надасть огляд механізму витрат на газ (EVM) в Ethereum Virtual Machine, основних концепцій оптимізації витрат на газ, а також кращих практик оптимізації витрат на газ при розробці смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників та нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти механізм витрат на газ EVM і спільно долати виклики в екосистемі блокчейну.

Вступ до механізму плати за газ EVM

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

У структурі EVM споживання Gas в основному ділиться на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті та зберігання.

Кожна транзакція вимагає обчислювальних ресурсів, тому стягується певна плата для запобігання безкінечним циклам і відмовам у обслуговуванні (DoS) атакам. Вартість, необхідна для завершення транзакції, називається "Gas плата".

З моменту набрання чинності EIP-1559, плата за газ розраховується за наступною формулою:

Газовий збір = одиниці використаного газу * (базова плата + плата за пріоритет)

Базовий збір буде знищено, тоді як пріоритетний збір буде використовуватися як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення більш високого пріоритетного збору під час надсилання транзакції може підвищити ймовірність включення транзакції до наступного блоку. Це схоже на "чайові", які користувачі платять валідаторам.

Розуміння оптимізації Gas у EVM

Коли компілюється смартконтракт на Solidity, контракт перетворюється на серію "операційних кодів", тобто opcodes.

Будь-який фрагмент операційного коду (, наприклад, створення смартконтракту, виконання викликів повідомлень, доступ до сховища рахунків та виконання операцій на віртуальній машині ) має визнану вартість газу, яка зафіксована в жовтій книзі Ethereum.

Після кількох змін EIP, деякі коди операцій мали знижені витрати газу, які можуть відрізнятися від жовтої книги.

Основні концепції оптимізації газу

Основна ідея оптимізації Gas полягає у пріоритетному виборі операцій з високою вартістю ефективності на блокчейні EVM, уникаючи дорогих за Gas операцій.

У EVM нижча вартість транзакції для наступних операцій:

• Читання та запис змінних пам'яті
• Зчитування констант і незмінних змінних
• Читати та писати локальні змінні
• Читання змінної calldata, наприклад, масиву та структури calldata
• Виклик внутрішньої функції

Операції з високими витратами включають:

• Читати та записувати змінні стану, що зберігаються у контракті
• Виклик зовнішньої функції
• Циклічна операція

Оптимізація витрат на газ EVM: найкращі практики

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

1. Намагайтеся зменшити використання пам'яті

У Solidity, Storage( зберігання) є обмеженим ресурсом, чий витрати Gas значно перевищують Memory( пам'ять). Кожного разу, коли смартконтракт читає або записує дані зі сховища, виникають великі витрати Gas.

Згідно з визначенням, наведеним у жовтій книзі Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, інструкції OPcodesmload та mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують щонайменше 100 одиниць.

Обмеження методів використання зберігання включають:

• Зберігати непостійні дані в пам'яті
• Падіння кількості змін у сховищі: шляхом збереження проміжних результатів у пам'яті, поки всі обчислення не будуть завершені, а потім розподілити результати для змінних сховища.

2. Упаковка змінних

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

Компілер Solidity під час компіляції упаковує послідовні змінні зберігання і використовує 32-байтовий слот зберігання як основну одиницю для зберігання змінних. Упаковка змінних означає раціональне розміщення змінних так, щоб кілька змінних могли вміститися в одному слоті зберігання.

Через цю детальну настройку, розробники можуть зекономити 20 000 одиниць газу ) для зберігання невикористаного слоту пам'яті, який потребує 20 000 газу (, але тепер потрібно лише два слоти пам'яті.

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

![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum])https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp(

) 3. Оптимізація типів даних

Змінна може бути представлена кількома різними типами даних, але витрати на операції для різних типів даних також різні. Вибір відповідного типу даних допомагає оптимізувати використання Gas.

Наприклад, у 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.

![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-5f3d7e103e47c886f50599cffe35c707.webp(

) 5. Відображення та масиви

Список даних Solidity може бути представлений двома типами даних: масиви ###Arrays ( та відображення )Mappings (, але їх синтаксис і структура кардинально відрізняються.

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

![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum])https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp(

) 6. Використання calldata замість memory

Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Основна різниця між ними полягає в тому, що memory може бути зміненою функцією, тоді як calldata є незмінною.

Запам'ятайте цей принцип: якщо параметри функції є лише для читання, слід віддавати перевагу використанню calldata замість memory. Це допоможе уникнути непотрібних операцій копіювання з calldata в memory.

![Оптимізація Gas для смартконтрактів Ethereum: десять найкращих практик]###https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp(

) 7. Якомога більше використовуйте ключові слова Constant/Immutable

Змінні Constant/Immutable не будуть зберігатися в сховищі контракту. Ці змінні обчислюються під час компіляції та зберігаються в байт-коді контракту. Тому їх вартість доступу значно нижча в порівнянні зі сховищем, рекомендовано використовувати ключові слова Constant або Immutable, якщо це можливо.

![Оптимізація Gas смартконтрактів Ethereum: десять найкращих практик]###https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp(

) 8. Використовуйте Unchecked, щоб забезпечити, що переповнення/недостатність не станеться.

Коли розробники можуть бути впевнені, що арифметичні операції не призведуть до переповнення або недоповнення, вони можуть використовувати ключове слово unchecked, введене в Solidity v0.8.0, щоб уникнути зайвих перевірок на переповнення або недоповнення, що дозволяє зекономити витрати на газ.

Крім того, компілятори версії 0.8.0 і вище більше не потребують використання бібліотеки SafeMath, оскільки сам компілятор вже вбудував функції захисту від переповнення та недоповнення.

![Топ 10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(

) 9. Оптимізація модифікаторів

Код модифікатора вбудовується в змінені функції, і щоразу, коли використовується модифікатор, його код копіюється. Це збільшує розмір байт-коду та підвищує споживання газу.

Перебудовуючи логіку в внутрішню функцію _checkOwner###(, можна дозволити повторне використання цієї внутрішньої функції в модифікаторі, що зменшує розмір байт-коду та Падіння вартості транзакції.

![Десять найкращих практик оптимізації газу смартконтрактів Ethereum])https://img-cdn.gateio.im/webp-social/moments-a141884dcdcdc56faff12eee2601b7b7.webp(

) 10. Оптимізація короткого замикання

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

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

![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-248337b15929868ed1250ffb9fcfa289.webp(

Додаткові загальні рекомендації

) 1. Видалити непотрібний код

Якщо в смартконтракті є невикористані функції або змінні, рекомендується їх видалити. Це найпростіший спосіб зменшити вартість розгортання контракту та зберегти компактний обсяг контракту.

Ось кілька корисних порад:

• Використовуйте найбільш ефективні алгоритми для обчислень. Якщо результати деяких обчислень використовуються безпосередньо в контракті, то ці надмірні обчислювальні процеси слід видалити. По суті, будь-які невикористані обчислення повинні бути видалені.

• У Ethereum розробники можуть отримувати нагороду Gas, звільняючи місце для зберігання. Якщо змінна більше не потрібна, її слід видалити за допомогою ключового слова delete або встановити на значення за замовчуванням.

• Оптимізація циклів: уникати операцій циклів з високою вартістю транзакції, якнайбільше об'єднувати цикли та виводити повторні обчислення за межі тіла циклу.

2. Використання попередньо скомпільованих смартконтрактів

Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як криптографічні та хеш-функції. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, потрібно менше Gas. Використання попередньо скомпільованих контрактів може заощадити Gas, зменшуючи обсяг обчислювальних робіт, необхідних для виконання смартконтрактів.

Приклади попередньо скомпільованих контрактів включають алгоритм цифрового підпису elliptic curve ###ECDSA( та хеш-алгоритм SHA2-256. Використовуючи ці попередньо скомпільовані контракти в смартконтрактах, розробники можуть знизити вартість транзакції та підвищити ефективність роботи додатків.

) 3. Використання вбудованого асемблерного коду

Вбудована асемблія ###in-line assembly ( дозволяє розробникам писати низькорівневий, але ефективний код, який може бути виконаний EVM без використання дорогих операційних кодів Solidity. Вбудована асемблія також дозволяє більш точно контролювати використання пам'яті та зберігання, що далі зменшує Вартість транзакції. Крім того, вбудована асемблія може виконувати деякі завдання, які важко реалізувати лише за допомогою Solidity.