Найкращі практики оптимізації Gas для смартконтрактів Ethereum
Газові витрати основної мережі Ethereum завжди були складним питанням, особливо це стає очевидним під час перевантаження мережі. У пікові періоди користувачі часто вимушені платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише ефективно знижує витрати на транзакції, але також підвищує ефективність транзакцій, що забезпечує користувачам більш економічний та ефективний досвід використання блокчейну.
У цьому документі буде розглянуто механізм Gas-кошту Ethereum Virtual Machine (EVM), основні концепції оптимізації Gas-кошту, а також найкращі практики оптимізації Gas-кошту під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як функціонують Gas-кошти EVM, щоб спільно протистояти викликам у блокчейн-екосистемі.
Вступ до механізму газових витрат EVM
У мережах, що підтримують EVM, "Gas" вказує на одиницю, що використовується для вимірювання обчислювальної потужності, необхідної для виконання певної операції.
У структурі EVM витрати Gas поділяються на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті й зберігання.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і відмовам у обслуговуванні (DoS) атак. Плата, необхідна для завершення транзакції, називається "Gas 费".
З моменту вступу в силу EIP-1559, плата за Gas розраховується за наступною формулою:
Комісія за газ = одиниці газу, що використовуються * (базова комісія + комісія за пріоритет)
Базовий збір буде знищено, а пріоритетний збір буде використовуватися як мотиватор, який стимулює валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час відправлення транзакції може підвищити ймовірність внесення транзакції до наступного блоку. Це схоже на "чаєві", які користувачі сплачують валідаторам.
1.Розуміння оптимізації Gas в EVM
Коли смартконтракт компілюється за допомогою Solidity, контракт перетворюється на ряд "операційних кодів", тобто opcodes.
Будь-яка секція коду (, наприклад, створення контракту, виконання виклику повідомлення, доступ до сховища облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP, деякі коди операцій отримали нову вартість Gas, що може відрізнятися від значень у жовтій книзі.
2.Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на EVM блокчейні, уникаючи дорогих за Gas операцій.
У EVM наступні операції мають нижчу вартість:
Читання та запис змінних пам'яті
Читати константи та незмінні змінні
Читання та запис локальних змінних
Зчитування змінної calldata, наприклад, масиву та структур.
Внутрішній виклик функцій
Витратні операції включають:
Читати та записувати стан змінних, збережених у сховищі смартконтракту
Виклик зовнішньої функції
Циклічна операція
Оптимізація витрат на EVM Gas: найкращі практики
На основі наведених основних понять, ми підготували список найкращих практик оптимізації витрат на Gas для розробницької спільноти. Дотримуючись цих практик, розробники можуть знизити споживання Gas смартконтрактами, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів програми.
1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання Gas значно перевищує Memory( пам'ять). Кожного разу, коли смартконтракт читає або записує дані з/до сховища, виникають великі витрати Gas.
Згідно з визначенням жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці газу, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують як мінімум 100 одиниць.
Методи обмеження використання сховища включають:
Зберігайте непостійні дані в пам'яті
Зменшення кількості змін у сховищі: зберігайте проміжні результати в пам'яті, а після завершення всіх обчислень розподіліть результати на змінні сховища.
2. Упаковка змінних
Кількість слотів зберігання (, які використовуються в смартконтрактах, а також спосіб, яким розробники вказують дані, значно вплине на споживання газу.
Компілятор Solidity під час компіляції пакує послідовні змінні зберігання та використовує 32-байтовий слот зберігання як основну одиницю зберігання змінних. Пакування змінних означає раціональне розміщення змінних, щоб кілька змінних могли вміститися в одному слоті зберігання.
Завдяки цьому коригуванню розробники можуть зекономити 20 000 одиниць Gas. Зберігання невикористаного сховища потребує 20 000 Gas, але зараз потрібні лише два сховища.
Оскільки кожен слот пам'яті споживає Gas, упаковка змінних оптимізує використання Gas, зменшуючи кількість необхідних слотів пам'яті.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-30f0bc370a7b9ca65f3d623c31262b76.webp(
) 3. Оптимізація типів даних
Змінна може бути представлена різними типами даних, але вартість операцій, пов'язаних з різними типами даних, також відрізняється. Вибір відповідного типу даних допомагає оптимізувати використання Gas.
Наприклад, у Solidity цілі числа можна поділити на різні розміри: uint8, uint16, uint32 тощо. Оскільки EVM виконує операції в одиницях по 256 біт, використання uint8 означає, що EVM спочатку повинна перетворити його на uint256, а це перетворення додатково споживатиме Gas.
Окремо, тут використання uint256 є дешевшим, ніж uint8. Проте, якщо використовувати оптимізацію упаковки змінних, яку ми пропонували раніше, ситуація змінюється. Якщо розробник може упакувати чотири змінні uint8 в один слот пам'яті, то загальні витрати на ітерацію будуть нижчими, ніж на чотири змінні uint256. Таким чином, смартконтракт може читати та писати один слот пам'яті і за один раз помістити чотири змінні uint8 в пам'ять/сховище.
4. Використовуйте змінні фіксованого розміру замість динамічних змінних
Якщо дані можна контролювати в межах 32 байтів, рекомендується використовувати тип даних bytes32 замість bytes або strings. Як правило, змінні фіксованого розміру споживають менше Gas, ніж змінні змінного розміру. Якщо довжину байтів можна обмежити, намагайтеся вибрати мінімальну довжину від 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 якомога більше.
8. Використовуйте Unchecked, щоб забезпечити відсутність переповнення/недостатності.
Коли розробники можуть бути впевнені, що арифметичні операції не призведуть до переповнення або недостатності, вони можуть використовувати ключове слово unchecked, введене в Solidity v0.8.0, щоб уникнути зайвих перевірок переповнення або недостатності, заощаджуючи витрати на Gas.
Крім того, компілятори версії 0.8.0 та вище більше не потребують використання бібліотеки SafeMath, оскільки компілятор самостійно вбудував функції захисту від переповнення та недостачі.
9. Оптимізувати модифікатор
Код модифікатора вбудовується в змінену функцію, і щоразу, коли модифікатор використовується, його код копіюється. Це збільшує розмір байт-коду та підвищує споживання Gas.
Перебудувавши логіку в внутрішню функцію _checkOwner(), дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, що може зменшити розмір байт-коду та знизити витрати на Gas.
![Ethereum смартконтракти Gas оптимізація десять кращих практик]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 10. Оптимізація короткого замикання
Для || та && операторів логічні операції можуть мати коротке оцінювання, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінена.
Щоб оптимізувати витрати на Gas, слід розміщувати умови з низькою вартістю обчислень на початку, що може дозволити пропустити дорогі обчислення.
Додаткові загальні рекомендації
1. Видалити непотрібний код
Якщо в контракті є не використані функції або змінні, рекомендується їх видалити. Це найбільш прямий спосіб зменшення вартості розгортання контракту та підтримання маленького обсягу контракту.
Ось кілька корисних порад:
Використовуйте найбільш ефективні алгоритми для обчислень. Якщо в контракті безпосередньо використовуються результати певних обчислень, то слід усунути ці зайві обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У мережі Ethereum розробники можуть отримувати винагороду у вигляді Gas, звільняючи простір для зберігання. Якщо певна змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати витратних операцій з циклом, по можливості об'єднувати цикли та виводити повторні обчислення з тіла циклу.
( 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані смартконтракти надають складні бібліотечні функції, такі як криптографічні та хеш-операції. Оскільки код виконується не на EVM, а локально на клієнтських вузлах, витрачається менше Gas. Використання попередньо скомпільованих смартконтрактів може заощадити Gas шляхом зменшення обсягу обчислювальних робіт, необхідних для виконання смартконтракту.
Приклади попередньо скомпільованих контрактів включають алгоритм цифрового підпису на основі еліптичних кривих )ECDSA### та хеш-алгоритм SHA2-256. Використовуючи ці попередньо скомпільовані контракти в смартконтрактах, розробники можуть знизити витрати на Gas та підвищити ефективність роботи додатків.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
19 лайків
Нагородити
19
8
Поділіться
Прокоментувати
0/400
SerumDegen
· 07-23 04:02
лмао, газ витрачає мої гроші прямо зараз... розорений від
Переглянути оригіналвідповісти на0
WalletDivorcer
· 07-21 18:08
Є руки, отже, можна дивитися на оптимізацію контрактів
Переглянути оригіналвідповісти на0
ProofOfNothing
· 07-20 15:12
газ нема грошей, про що ще можна говорити
Переглянути оригіналвідповісти на0
AlphaBrain
· 07-20 04:31
Гаразд, ліньки оптимізувати газ, йдемо на L2
Переглянути оригіналвідповісти на0
ImpermanentLossEnjoyer
· 07-20 04:29
Хто ще пам'ятає трагедію з угодою на 2000u
Переглянути оригіналвідповісти на0
OvertimeSquid
· 07-20 04:19
Щоб отримати торговий збір, потрібно сплатити іпотеку.
Посібник з оптимізації Gas-кошту смартконтрактів Ethereum: Топ-10 найкращих практик та порад
Найкращі практики оптимізації Gas для смартконтрактів Ethereum
Газові витрати основної мережі Ethereum завжди були складним питанням, особливо це стає очевидним під час перевантаження мережі. У пікові періоди користувачі часто вимушені платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише ефективно знижує витрати на транзакції, але також підвищує ефективність транзакцій, що забезпечує користувачам більш економічний та ефективний досвід використання блокчейну.
У цьому документі буде розглянуто механізм Gas-кошту Ethereum Virtual Machine (EVM), основні концепції оптимізації Gas-кошту, а також найкращі практики оптимізації Gas-кошту під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як функціонують Gas-кошти EVM, щоб спільно протистояти викликам у блокчейн-екосистемі.
Вступ до механізму газових витрат EVM
У мережах, що підтримують EVM, "Gas" вказує на одиницю, що використовується для вимірювання обчислювальної потужності, необхідної для виконання певної операції.
У структурі EVM витрати Gas поділяються на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті й зберігання.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і відмовам у обслуговуванні (DoS) атак. Плата, необхідна для завершення транзакції, називається "Gas 费".
З моменту вступу в силу EIP-1559, плата за Gas розраховується за наступною формулою:
Комісія за газ = одиниці газу, що використовуються * (базова комісія + комісія за пріоритет)
Базовий збір буде знищено, а пріоритетний збір буде використовуватися як мотиватор, який стимулює валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час відправлення транзакції може підвищити ймовірність внесення транзакції до наступного блоку. Це схоже на "чаєві", які користувачі сплачують валідаторам.
1.Розуміння оптимізації Gas в EVM
Коли смартконтракт компілюється за допомогою Solidity, контракт перетворюється на ряд "операційних кодів", тобто opcodes.
Будь-яка секція коду (, наприклад, створення контракту, виконання виклику повідомлення, доступ до сховища облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP, деякі коди операцій отримали нову вартість Gas, що може відрізнятися від значень у жовтій книзі.
2.Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на EVM блокчейні, уникаючи дорогих за Gas операцій.
У EVM наступні операції мають нижчу вартість:
Витратні операції включають:
Оптимізація витрат на EVM Gas: найкращі практики
На основі наведених основних понять, ми підготували список найкращих практик оптимізації витрат на Gas для розробницької спільноти. Дотримуючись цих практик, розробники можуть знизити споживання Gas смартконтрактами, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів програми.
1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання Gas значно перевищує Memory( пам'ять). Кожного разу, коли смартконтракт читає або записує дані з/до сховища, виникають великі витрати Gas.
Згідно з визначенням жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці газу, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують як мінімум 100 одиниць.
Методи обмеження використання сховища включають:
2. Упаковка змінних
Кількість слотів зберігання (, які використовуються в смартконтрактах, а також спосіб, яким розробники вказують дані, значно вплине на споживання газу.
Компілятор Solidity під час компіляції пакує послідовні змінні зберігання та використовує 32-байтовий слот зберігання як основну одиницю зберігання змінних. Пакування змінних означає раціональне розміщення змінних, щоб кілька змінних могли вміститися в одному слоті зберігання.
Завдяки цьому коригуванню розробники можуть зекономити 20 000 одиниць Gas. Зберігання невикористаного сховища потребує 20 000 Gas, але зараз потрібні лише два сховища.
Оскільки кожен слот пам'яті споживає Gas, упаковка змінних оптимізує використання Gas, зменшуючи кількість необхідних слотів пам'яті.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-30f0bc370a7b9ca65f3d623c31262b76.webp(
) 3. Оптимізація типів даних
Змінна може бути представлена різними типами даних, але вартість операцій, пов'язаних з різними типами даних, також відрізняється. Вибір відповідного типу даних допомагає оптимізувати використання Gas.
Наприклад, у Solidity цілі числа можна поділити на різні розміри: uint8, uint16, uint32 тощо. Оскільки EVM виконує операції в одиницях по 256 біт, використання uint8 означає, що EVM спочатку повинна перетворити його на uint256, а це перетворення додатково споживатиме Gas.
Окремо, тут використання uint256 є дешевшим, ніж uint8. Проте, якщо використовувати оптимізацію упаковки змінних, яку ми пропонували раніше, ситуація змінюється. Якщо розробник може упакувати чотири змінні uint8 в один слот пам'яті, то загальні витрати на ітерацію будуть нижчими, ніж на чотири змінні uint256. Таким чином, смартконтракт може читати та писати один слот пам'яті і за один раз помістити чотири змінні uint8 в пам'ять/сховище.
4. Використовуйте змінні фіксованого розміру замість динамічних змінних
Якщо дані можна контролювати в межах 32 байтів, рекомендується використовувати тип даних bytes32 замість bytes або strings. Як правило, змінні фіксованого розміру споживають менше Gas, ніж змінні змінного розміру. Якщо довжину байтів можна обмежити, намагайтеся вибрати мінімальну довжину від 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 якомога більше.
8. Використовуйте Unchecked, щоб забезпечити відсутність переповнення/недостатності.
Коли розробники можуть бути впевнені, що арифметичні операції не призведуть до переповнення або недостатності, вони можуть використовувати ключове слово unchecked, введене в Solidity v0.8.0, щоб уникнути зайвих перевірок переповнення або недостатності, заощаджуючи витрати на Gas.
Крім того, компілятори версії 0.8.0 та вище більше не потребують використання бібліотеки SafeMath, оскільки компілятор самостійно вбудував функції захисту від переповнення та недостачі.
9. Оптимізувати модифікатор
Код модифікатора вбудовується в змінену функцію, і щоразу, коли модифікатор використовується, його код копіюється. Це збільшує розмір байт-коду та підвищує споживання Gas.
Перебудувавши логіку в внутрішню функцію _checkOwner(), дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, що може зменшити розмір байт-коду та знизити витрати на Gas.
![Ethereum смартконтракти Gas оптимізація десять кращих практик]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 10. Оптимізація короткого замикання
Для || та && операторів логічні операції можуть мати коротке оцінювання, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінена.
Щоб оптимізувати витрати на Gas, слід розміщувати умови з низькою вартістю обчислень на початку, що може дозволити пропустити дорогі обчислення.
Додаткові загальні рекомендації
1. Видалити непотрібний код
Якщо в контракті є не використані функції або змінні, рекомендується їх видалити. Це найбільш прямий спосіб зменшення вартості розгортання контракту та підтримання маленького обсягу контракту.
Ось кілька корисних порад:
Використовуйте найбільш ефективні алгоритми для обчислень. Якщо в контракті безпосередньо використовуються результати певних обчислень, то слід усунути ці зайві обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У мережі Ethereum розробники можуть отримувати винагороду у вигляді Gas, звільняючи простір для зберігання. Якщо певна змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати витратних операцій з циклом, по можливості об'єднувати цикли та виводити повторні обчислення з тіла циклу.
( 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані смартконтракти надають складні бібліотечні функції, такі як криптографічні та хеш-операції. Оскільки код виконується не на EVM, а локально на клієнтських вузлах, витрачається менше Gas. Використання попередньо скомпільованих смартконтрактів може заощадити Gas шляхом зменшення обсягу обчислювальних робіт, необхідних для виконання смартконтракту.
Приклади попередньо скомпільованих контрактів включають алгоритм цифрового підпису на основі еліптичних кривих )ECDSA### та хеш-алгоритм SHA2-256. Використовуючи ці попередньо скомпільовані контракти в смартконтрактах, розробники можуть знизити витрати на Gas та підвищити ефективність роботи додатків.