Посібник з оптимізації газу смартконтрактів Ethereum
Газові витрати на основній мережі Ethereum завжди були складним питанням, особливо під час перевантаження мережі. У пікові години користувачі часто змушені платити високі комісії за транзакції. Тому оптимізація витрат на газ під час етапу розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття надасть огляд механізму плати за газ Ethereum Virtual Machine (EVM), основних концепцій оптимізації плати за газ, а також найкращих практик оптимізації плати за газ під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників та нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як працюють витрати на газ у EVM, щоб спільно протистояти викликам у блокчейн-екосистемі.
Огляд механізму плати за газ EVM
У мережах, що підтримують EVM, "Gas" є одиницею для вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурній схемі EVM витрати Gas діляться на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті та зберігання.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і атакам відмови в обслуговуванні (DoS). Плата, необхідна для завершення транзакції, називається "Gas 费".
З моменту набрання чинності лондонським хард-форком EIP-1559( ), Gas витрати розраховуються за наступною формулою:
Газовий збір = одиниці використаного газу * (базовий збір + пріоритетний збір)
Базовий збір буде знищено, в той час як пріоритетний збір буде використовуватися як стимул, щоб заохотити валідаторів додавати транзакції в блокчейн. Встановлення вищого пріоритетного збору під час відправлення транзакції може підвищити ймовірність того, що транзакція буде включена в наступний блок. Це схоже на "чайові", які користувачі платять валідаторам.
Розуміння оптимізації Gas в EVM
Коли смартконтракти компілюються за допомогою Solidity, контракт буде перетворено на ряд "операційних кодів", тобто opcodes.
Будь-яка частина коду операцій (, наприклад, створення контракту, виконання викликів повідомлень, доступ до сховища облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP, вартість газу для деяких операційних кодів була скоригована, що може відрізнятися від даних у жовтій книзі.
Основні концепції оптимізації Gas
Основна ідея оптимізації газу полягає в пріоритетному виборі операцій з високою вартісною ефективністю на блокчейні EVM, уникаючи операцій з дорогими витратами на газ.
У EVM нижче вартість таких операцій:
Читання та запис змінних пам'яті
Читання констант та незмінних змінних
Читати та записувати локальні змінні
Зчитування змінної calldata, наприклад масиву та структур.
Виклик внутрішніх функцій
Операції з високими витратами включають:
Читати та записувати стан змінних, які зберігаються у смартконтрактах
Виклики зовнішніх функцій
Циклічна операція
Оптимізація витрат газу EVM: найкращі практики
На основі вищезгаданих основних понять, ми підготували для спільноти розробників список найкращих практик оптимізації газових витрат. Дотримуючись цих практик, розробники можуть знизити витрати газу на смартконтракти, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, споживання Gas якого значно перевищує Memory( пам'ять). Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають великі витрати Gas.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore витрачають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують щонайменше 100 одиниць.
Обмеження методів використання зберігання включають:
Зберігайте непостійні дані в пам'яті
Зменшення кількості змін у пам'яті: зберігаючи проміжні результати в пам'яті, а потім, після завершення всіх обчислень, розподіляючи результати між змінними зберігання.
2. Пакування змінних
Кількість сховищ, що використовуються в смартконтрактах, та спосіб, яким розробники представляють дані, суттєво вплине на споживання газу.
Компілятор Solidity під час компіляції пакує послідовні змінні зберігання і використовує 32-байтовий слот зберігання як базову одиницю для зберігання змінних. Пакування змінних означає раціональне розташування змінних, що дозволяє декільком змінним поміститися в одному слоті зберігання.
За допомогою цього коригування розробники можуть заощадити 20,000 одиниць Gas. Зберігання невикористаного сховища потребує 20,000 Gas, але тепер потрібно лише два сховища.
Оскільки кожен слот зберігання споживає Gas, упаковка змінних оптимізує використання Gas шляхом зменшення кількості необхідних слотів зберігання.
( 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 шляхом пакування типів даних.
( 6. Використовуйте calldata замість memory
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Основна різниця між ними полягає в тому, що memory може бути змінена функцією, тоді як calldata є незмінною.
Запам'ятайте цей принцип: якщо параметри функції є лише для читання, слід віддавати перевагу використанню calldata замість memory. Це дозволяє уникнути непотрібних операцій копіювання з calldata функції в memory.
) 7. Намагайтеся використовувати ключові слова Constant/Immutable якомога більше.
Змінні Constant/Immutable не зберігаються в сховищі контракту. Ці змінні обчислюються під час компіляції та зберігаються в байт-коді контракту. Отже, їхня вартість доступу набагато нижча в порівнянні з сховищем, рекомендується використовувати ключові слова Constant або Immutable, коли це можливо.
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. Оптимізація короткого замикання
Для || та && операторів логічні операції будуть підлягати короткочасній оцінці, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати витрати на Gas, слід розмістити умови з низькою вартістю обчислень спочатку, що може дозволити пропустити дорогі обчислення.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp(
Додаткові загальні поради
) 1. Видалити непотрібний код
Якщо в контракті є невикористані функції або змінні, рекомендується їх видалити. Це найпряміший спосіб зменшити витрати на розгортання контракту та зберегти його обсяг малим.
Ось кілька практичних порад:
Використовуйте найефективніші алгоритми для обчислень. Якщо в контракті безпосередньо використовуються результати певних обчислень, то слід усунути ці надмірні обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У Ethereum розробники можуть отримувати нагороду за Gas, звільняючи місце для зберігання. Якщо змінна більше не потрібна, слід використовувати ключове слово delete, щоб видалити її, або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати дорогих операцій циклу, по можливості об'єднувати цикли та виносити повторні обчислення з тіла циклу.
2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як шифрування та хешування. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, споживання газу потребує менше. Використовуючи попередньо скомпільовані контракти, можна заощадити газ, зменшуючи обсяг обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису на основі еліптичних кривих (ECDSA) та хеш-алгоритм SHA2-256. Використовуючи ці попередньо скомпільовані смартконтракти в смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи застосунків.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp###
( 3. Використання вбудованого асемблерного коду
Вбудована асемблер)in-line assembly(дозволяє розробникам писати низькорівневий, але ефективний код, який може бути безпосередньо виконаний EVM, без необхідності використання
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
6 лайків
Нагородити
6
4
Репост
Поділіться
Прокоментувати
0/400
GateUser-00be86fc
· 8год тому
газ надто дорогий, щоб займатися смартконтрактами
Переглянути оригіналвідповісти на0
PermabullPete
· 9год тому
газ високий до абсурду, хто ще наважиться торкнутися?
Переглянути оригіналвідповісти на0
BearMarketMonk
· 9год тому
Усі ці оптимізації в кінцевому підсумку лише для того, щоб заощадити на обіді...
Переглянути оригіналвідповісти на0
RunWithRugs
· 9год тому
В години пік газові витрати можуть купити вечерю, тс-тс.
Ethereum смартконтракти Gas оптимізація практичний посібник: Падіння витрат підвищення ефективності
Посібник з оптимізації газу смартконтрактів Ethereum
Газові витрати на основній мережі Ethereum завжди були складним питанням, особливо під час перевантаження мережі. У пікові години користувачі часто змушені платити високі комісії за транзакції. Тому оптимізація витрат на газ під час етапу розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття надасть огляд механізму плати за газ Ethereum Virtual Machine (EVM), основних концепцій оптимізації плати за газ, а також найкращих практик оптимізації плати за газ під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників та нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як працюють витрати на газ у EVM, щоб спільно протистояти викликам у блокчейн-екосистемі.
Огляд механізму плати за газ EVM
У мережах, що підтримують EVM, "Gas" є одиницею для вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурній схемі EVM витрати Gas діляться на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті та зберігання.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і атакам відмови в обслуговуванні (DoS). Плата, необхідна для завершення транзакції, називається "Gas 费".
З моменту набрання чинності лондонським хард-форком EIP-1559( ), Gas витрати розраховуються за наступною формулою:
Газовий збір = одиниці використаного газу * (базовий збір + пріоритетний збір)
Базовий збір буде знищено, в той час як пріоритетний збір буде використовуватися як стимул, щоб заохотити валідаторів додавати транзакції в блокчейн. Встановлення вищого пріоритетного збору під час відправлення транзакції може підвищити ймовірність того, що транзакція буде включена в наступний блок. Це схоже на "чайові", які користувачі платять валідаторам.
Розуміння оптимізації Gas в EVM
Коли смартконтракти компілюються за допомогою Solidity, контракт буде перетворено на ряд "операційних кодів", тобто opcodes.
Будь-яка частина коду операцій (, наприклад, створення контракту, виконання викликів повідомлень, доступ до сховища облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP, вартість газу для деяких операційних кодів була скоригована, що може відрізнятися від даних у жовтій книзі.
Основні концепції оптимізації Gas
Основна ідея оптимізації газу полягає в пріоритетному виборі операцій з високою вартісною ефективністю на блокчейні EVM, уникаючи операцій з дорогими витратами на газ.
У EVM нижче вартість таких операцій:
Операції з високими витратами включають:
Оптимізація витрат газу EVM: найкращі практики
На основі вищезгаданих основних понять, ми підготували для спільноти розробників список найкращих практик оптимізації газових витрат. Дотримуючись цих практик, розробники можуть знизити витрати газу на смартконтракти, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, споживання Gas якого значно перевищує Memory( пам'ять). Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають великі витрати Gas.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore витрачають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують щонайменше 100 одиниць.
Обмеження методів використання зберігання включають:
2. Пакування змінних
Кількість сховищ, що використовуються в смартконтрактах, та спосіб, яким розробники представляють дані, суттєво вплине на споживання газу.
Компілятор Solidity під час компіляції пакує послідовні змінні зберігання і використовує 32-байтовий слот зберігання як базову одиницю для зберігання змінних. Пакування змінних означає раціональне розташування змінних, що дозволяє декільком змінним поміститися в одному слоті зберігання.
За допомогою цього коригування розробники можуть заощадити 20,000 одиниць Gas. Зберігання невикористаного сховища потребує 20,000 Gas, але тепер потрібно лише два сховища.
Оскільки кожен слот зберігання споживає Gas, упаковка змінних оптимізує використання Gas шляхом зменшення кількості необхідних слотів зберігання.
( 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 шляхом пакування типів даних.
( 6. Використовуйте calldata замість memory
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Основна різниця між ними полягає в тому, що memory може бути змінена функцією, тоді як calldata є незмінною.
Запам'ятайте цей принцип: якщо параметри функції є лише для читання, слід віддавати перевагу використанню calldata замість memory. Це дозволяє уникнути непотрібних операцій копіювання з calldata функції в memory.
) 7. Намагайтеся використовувати ключові слова Constant/Immutable якомога більше.
Змінні Constant/Immutable не зберігаються в сховищі контракту. Ці змінні обчислюються під час компіляції та зберігаються в байт-коді контракту. Отже, їхня вартість доступу набагато нижча в порівнянні з сховищем, рекомендується використовувати ключові слова Constant або Immutable, коли це можливо.
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. Оптимізація короткого замикання
Для || та && операторів логічні операції будуть підлягати короткочасній оцінці, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати витрати на Gas, слід розмістити умови з низькою вартістю обчислень спочатку, що може дозволити пропустити дорогі обчислення.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp(
Додаткові загальні поради
) 1. Видалити непотрібний код
Якщо в контракті є невикористані функції або змінні, рекомендується їх видалити. Це найпряміший спосіб зменшити витрати на розгортання контракту та зберегти його обсяг малим.
Ось кілька практичних порад:
Використовуйте найефективніші алгоритми для обчислень. Якщо в контракті безпосередньо використовуються результати певних обчислень, то слід усунути ці надмірні обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У Ethereum розробники можуть отримувати нагороду за Gas, звільняючи місце для зберігання. Якщо змінна більше не потрібна, слід використовувати ключове слово delete, щоб видалити її, або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати дорогих операцій циклу, по можливості об'єднувати цикли та виносити повторні обчислення з тіла циклу.
2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як шифрування та хешування. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, споживання газу потребує менше. Використовуючи попередньо скомпільовані контракти, можна заощадити газ, зменшуючи обсяг обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису на основі еліптичних кривих (ECDSA) та хеш-алгоритм SHA2-256. Використовуючи ці попередньо скомпільовані смартконтракти в смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи застосунків.
![Ethereum смартконтракти Gas оптимізація десять найкращих практик]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp###
( 3. Використання вбудованого асемблерного коду
Вбудована асемблер)in-line assembly(дозволяє розробникам писати низькорівневий, але ефективний код, який може бути безпосередньо виконаний EVM, без необхідності використання