Посібник з оптимізації газу для смартконтрактів 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: найкращі практики

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

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

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

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

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

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

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

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

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

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

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

![Ethereum смартконтракти Gas оптимізації десять найкращих практик])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 в пам'ять/зберігання за однією операцією.

![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 замість 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, щоб уникнути зайвих перевірок на переповнення або недоповнення, тим самим заощаджуючи витрати на Gas.

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

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

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

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

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

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

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

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

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

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

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

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

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

![Ethereum смартконтракти Gas оптимізації десять найкращих практик])