ЕтерФлотсмарт-контрактигазОптимізаціядесятьнайкращихпрактик

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

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

Опис механізму комісії газу EVM

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

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

Джерело: Офіційний сайт Ethereum [1]

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

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

Комісія за газ = одиниці газу, використаних * (базова комісія + пріоритетна комісія)

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

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

Під час компіляції смарт-контракту за допомогою Solidity, контракт буде перетворений на серію 'операційних кодів', тобто opcodes.

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

Після кількох змін EIP вартість газу деяких опкодів була змінена і може відрізнятися від значень, зазначених у жовтій книзі. Для отримання оновленої інформації про вартість опкодів дивіться тут: [3].

2. Основні поняття оптимізації газу

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

В EVM вартість наступних операцій є низькою:

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

Висококоштовні операції включають:

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

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

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

1.Спробуйте мінімізувати використання зберігання

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

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

! [Топ-10 найкращих практик оптимізації газу смарт-контрактів Ethereum] (https://cdn-img.panewslab.com/yijian/2024/12/30/images/db2057dbd27e1fe60842809ba363de02.jpg)

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

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

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

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

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

Ліва сторона є менш ефективним способом реалізації, вона використовує 3 слоти пам'яті; права сторона є більш ефективним способом.

! [Топ-10 найкращих практик оптимізації газу смарт-контрактів Ethereum] (https://cdn-img.panewslab.com/yijian/2024/12/30/images/3d3437b6ecd45b30b40d3c734616b25e.jpg)

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

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

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

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

Наприклад, у Solidity цілі числа можуть бути розбиті на різні розміри: uint8, uint16, uint32, тощо. Оскільки EVM виконує операції в одиницях 256 біт, використання uint8 означає, що EVM спочатку мусить перетворити його на uint256, а це додатково споживає газ.

Ми можемо порівняти витрати на газ для uint8 та uint256 за кодом на зображенні. Функція UseUint() споживає 120,382 одиниці газу, а функція UseUInt8() споживає 166,111 одиниць газу.

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

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

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

5. Мапування та масиви

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

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

6. Використовуйте calldata замість пам'яті

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

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

Приклад 1: Використання пам'яті

​

При використанні ключового слова memory значення масиву будуть скопійовані з закодованого calldata в пам'ять під час декодування ABI. Вартість виконання цього фрагмента коду становить 3,694 газових одиниць.

Приклад 2: використання calldata

! [Топ-10 найкращих практик оптимізації газу смарт-контрактів Ethereum] (https://cdn-img.panewslab.com/yijian/2024/12/30/images/d4abb8af9991800400595ae852296d9b.jpg)

При прямій читанні значень з calldata, пропускаються проміжні операції з пам'яттю. Цей спосіб оптимізації знижує вартість виконання до всього 2 413 одиниць газу, що покращує ефективність газу на 35%.

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

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

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

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

У наведеному нижче зображенні, обмеженням умов є i

! [Топ-10 найкращих практик оптимізації газу смарт-контрактів Ethereum] (https://cdn-img.panewslab.com/yijian/2024/12/30/images/d41402737a3ef12093c707306a1cbf7b.jpg)

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

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

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

Оптимізація перед:

Після оптимізації:

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

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

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

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

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

1. Видалення непотрібного коду

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

Нижче наведено деякі корисні поради：

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

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

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

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

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

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

Щоб отримати повний список попередньо скомпільованих контрактів, які підтримує мережа ETH, див. тут [4].

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

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

Ось приклад коду з використанням вбудованої асемблерної мови для економії газу:

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

Однак використання вбудованої асемблерної вставки також може належати до ризиків і призводити до помилок. Тому її слід використовувати з обережністю тільки досвідченим розробникам.

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

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

Подібні рішення другого рівня, як rollups, sidechains та state channels, можуть розподілити обробку транзакцій з головного ланцюжка ETH, що дозволяє здійснювати швидші та дешевші транзакції.

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

5. Використання оптимізаційних інструментів та бібліотек

Є кілька інструментів оптимізації, таких як оптимізатор solc, оптимізатор збірки Truffle та компілятор Solidity для Remix, які можна використовувати.

! [Топ-10 найкращих практик оптимізації газу смарт-контрактів Ethereum] (https://cdn-img.panewslab.com/yijian/2024/12/30/images/b9dc072d3e850ceeb7961a0c7469a03a.jpg)

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

Висновок

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

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

[1] :

[2] :

[3] :

[4] :передкомпільований