Оптимізація газових витрат EVM - Посібник з розробки смартконтрактів Ethereum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У EVM нижче витрати на наступні операції:

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

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

• Читати та записувати стан змінних, збережених у смартконтракті
• Виклик зовнішніх функцій
• Циклічна операція

Найкращі практики оптимізації витрат на газ EVM

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

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

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

Методи обмеження використання сховища включають:

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

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

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

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

Завдяки упаковці змінних розробники можуть заощадити значну кількість одиниць Gas. Оскільки кожен слот зберігання споживає 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, а це перетворення додатково споживає Gas.

Проте, якщо використовувати упаковку змінних для оптимізації, упакувавши чотири змінні uint8 в один слот пам'яті, то загальна вартість ітерації над ними буде нижчою, ніж для чотирьох змінних uint256. Таким чином, смартконтракт зможе читати і записувати один слот пам'яті, і за одну операцію помістити чотири змінні uint8 в пам'ять/сховище.

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

) 4. Використовуйте змінні фіксованого розміру замість динамічних змінних

Якщо дані можна обмежити до 32 байтів, рекомендується використовувати тип даних bytes32 замість bytes або strings. Загалом, змінні фіксованого розміру споживають менше газу, ніж змінні змінного розміру. Якщо довжину байтів можна обмежити, намагайтеся обрати мінімальну довжину від bytes1 до bytes32.

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

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

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

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

) 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 не зберігаються у сховищі контракту. Ці змінні обчислюються під час компіляції і зберігаються у байт-коді контракту. Тому їх вартість доступу значно нижча у порівнянні зі сховищем, тому рекомендується використовувати ключові слова 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, а запускається локально на клієнтському вузлі, потрібна менша кількість Gas. Використання пре-компіляційних контрактів може заощадити Gas, зменшуючи обсяг обчислювальних робіт, необхідних для виконання смартконтрактів.

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

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

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

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

) 4. Використання рішень Layer 2

Використання рішень Layer 2 може зменшити обсяг даних, які потрібно зберігати та обробляти в основній мережі Ethereum.

Рішення Layer 2, такі як rollups, бокові ланцюги та канали стану, можуть розвантажити обробку транзакцій з основного ланцюга Ethereum, що дозволяє здійснювати транзакції швидше і дешевше.

Шляхом об'єднання великої кількості транзакцій ці рішення зменшують кількість транзакцій в мережі, що, в свою чергу, знижує Gas витрати. Використання рішень Layer 2 також може підвищити масштабованість Ethereum, дозволяючи більшій кількості користувачів та додатків брати участь у мережі, не призводячи до