Найкращі практики оптимізації газу для смартконтрактів Ethereum
Газові витрати основної мережі Ethereum завжди були складним питанням, особливо це стає помітним під час завантаження мережі. У пікові години користувачі часто змушені платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід роботи з блокчейном.
У цій статті буде розглянуто механізм плати за Gas в Ethereum Virtual Machine (EVM), основні концепції оптимізації плати за Gas, а також найкращі практики оптимізації плати за Gas під час розробки смартконтрактів. Сподіваємось, що ці матеріали надихнуть розробників та нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як працює плата за Gas в EVM, спільно протистояти викликам екосистеми блокчейну.
Вступ до механізму зборів Gas в EVM
У мережах, сумісних з EVM, "Gas" є одиницею виміру обчислювальної потужності, необхідної для виконання певних операцій.
У структурі EVM витрати газу поділяються на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис в пам'ять і сховище.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата, щоб запобігти безкінечним циклам і атакам відмови в обслуговуванні ( DoS ). Плата, необхідна для виконання транзакції, називається "Gas плата".
З моменту вступу в силу Лондонського хардфорку EIP-1559(), витрати на газ обчислюються за наступною формулою:
Комісія за газ = одиниці використаного газу * (базова комісія + пріоритетна комісія)
Базовий збір буде знищено, а пріоритетний збір буде використаний як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення більш високого пріоритетного збору під час відправки транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чайові", які користувачі сплачують валідаторам.
1. Розуміння оптимізації Gas в EVM
Коли смартконтракти компілюються за допомогою Solidity, контракт перетворюється на серію "операційних кодів", тобто opcodes.
Будь-який фрагмент коду операцій (, наприклад, створення контракту, виконання викликів повідомлень, доступ до зберігання облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP деякі коди операцій отримали коригування вартості Gas, що може відрізнятися від жовтої книги.
2.Базові поняття оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою ефективністю витрат на блокчейні EVM, уникнення дорогих за вартістю операцій.
У EVM наступні операції мають низьку вартість:
Читати та записувати змінні пам'яті
Читання констант і незмінних змінних
Читати та писати локальні змінні
Читати змінні calldata, такі як масиви та структури calldata
Виклик внутрішньої функції
Операції з високими витратами включають:
Читати та записувати змінні стану, які зберігаються в контракті
Виклик зовнішньої функції
Циклічна операція
! [Топ-10 найкращих практик оптимізації газу смарт-контрактів Ethereum](https://img-cdn.gateio.im/webp-social/moments-b237228ebe933741fb60f2e8bcb38405.webp0192837465674839201
Оптимізація витрат газу EVM: найкращі практики
На основі вищезазначених основних понять, ми підготували для спільноти розробників список найкращих практик оптимізації витрат Gas. Дотримуючись цих практик, розробники можуть знизити споживання Gas смартконтрактами, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
) 1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage### зберігання( є обмеженим ресурсом, споживання газу якого значно перевищує Memory) пам'ять(. Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають великі витрати газу.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більше ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують як мінімум 100 одиниць.
Обмеження методів використання зберігання включають:
Зберігати непостійні дані в пам'яті
Зменшити кількість змін у зберіганні: зберігати проміжні результати в пам'яті, а потім, після завершення всіх обчислень, призначити результати змінним зберігання.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-30f0bc370a7b9ca65f3d623c31262b76.webp(
) 2. Упаковка змінних
Кількість Storage slot###, що використовується в смартконтрактах, а також спосіб, яким розробники представляють дані, суттєво вплине на споживання Gas.
Компіллятор 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 ), але їх синтаксис і структура кардинально відрізняються.
У більшості випадків мапи є більш ефективними та менш витратними, але масиви мають ітеративність та підтримують упаковку типів даних. Тому рекомендується віддавати перевагу використанню мап, коли ви керуєте списком даних, якщо не потрібно ітерувати або якщо можна оптимізувати витрати газу за допомогою упаковки типів даних.
( 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, щоб уникнути зайвих перевірок на переповнення або недоповнення, що дозволяє зекономити витрати на газ.
Крім того, компілятори версії 0.8.0 та вище більше не потребують використання бібліотеки SafeMath, оскільки сама компілятор вже має вбудовані функції захисту від переповнень і недостатньостей.
) 9. Оптимізація модифікатора
Код модифікатора вбудовується в змінену функцію, і щоразу, коли використовується модифікатор, його код копіюється. Це збільшує розмір байт-коду і підвищує споживання Gas.
Перетворивши логіку на внутрішню функцію _checkOwner######, дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, що може зменшити розмір байт-коду та знизити витрати на Gas.
( 10. Оптимізація короткого замикання
Для операторів || та && логічні обчислення підлягають короткому оцінюванню, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід помістити умови з низькою вартістю обчислень на початку, так можна уникнути дорогих обчислень.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp###
Додаткові загальні рекомендації
( 1. Видалити непотрібний код
Якщо в контракті є невикористані функції чи змінні, рекомендується їх видалити. Це найбільш прямий спосіб зменшення витрат на розгортання контракту та підтримки малого обсягу контракту.
Ось кілька корисних порад:
Використовуйте найефективніший алгоритм для виконання обчислень. Якщо результати певних обчислень безпосередньо використовуються в контракті, тоді слід усунути ці зайві обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У мережі Ethereum розробники можуть отримати Gas винагороди, звільняючи пам'ять. Якщо змінна більше не потрібна, її слід видалити за допомогою ключового слова delete або встановити на значення за замовчуванням.
Оптимізація циклів: уникайте дорогих операцій циклу, по можливості об'єднуйте цикли та виводьте повторні обчислення за межі тіла циклу.
) 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як криптографічні та хеш-операції. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, потрібно менше Gas. Використання попередньо скомпільованих контрактів може заощадити Gas, зменшуючи обсяги обчислювальної роботи, необхідної для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису на основі еліптичних кривих ###ECDSA### та алгоритм хешування SHA2-256. Використовуючи ці попередньо скомпільовані смартконтракти у смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи програм.
( 3. Використання інтегрованого асемблерного коду
Вбудована збірка ) in-line assembly ### дозволяє розробникам писати низькорівневий, але ефективний код, який може виконуватися безпосередньо EVM, без використання дорогих операційних кодів Solidity. Вбудована збірка також дозволяє більш точно контролювати використання пам'яті та сховища, що ще більше зменшує витрати на Gas. Крім того, вбудована збірка може виконувати деякі складні операції, які важко реалізувати, використовуючи тільки Solidity, надаючи більше гнучкості для оптимізації споживання Gas.
Проте використання вбудованого асемблера також може нести ризики та бути схильним до помилок. Тому його слід використовувати обережно, лише досвідченими розробниками.
( 4. Використання рішень Layer 2
Використання рішень Layer 2 може зменшити потребу в зберіганні та обчисленнях на основній мережі Ethereum.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 способів оптимізації витрат на Gas для смартконтрактів Ethereum, які допоможуть розробникам знизити витрати
Найкращі практики оптимізації газу для смартконтрактів Ethereum
Газові витрати основної мережі Ethereum завжди були складним питанням, особливо це стає помітним під час завантаження мережі. У пікові години користувачі часто змушені платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід роботи з блокчейном.
У цій статті буде розглянуто механізм плати за Gas в Ethereum Virtual Machine (EVM), основні концепції оптимізації плати за Gas, а також найкращі практики оптимізації плати за Gas під час розробки смартконтрактів. Сподіваємось, що ці матеріали надихнуть розробників та нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як працює плата за Gas в EVM, спільно протистояти викликам екосистеми блокчейну.
Вступ до механізму зборів Gas в EVM
У мережах, сумісних з EVM, "Gas" є одиницею виміру обчислювальної потужності, необхідної для виконання певних операцій.
У структурі EVM витрати газу поділяються на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис в пам'ять і сховище.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата, щоб запобігти безкінечним циклам і атакам відмови в обслуговуванні ( DoS ). Плата, необхідна для виконання транзакції, називається "Gas плата".
З моменту вступу в силу Лондонського хардфорку EIP-1559(), витрати на газ обчислюються за наступною формулою:
Комісія за газ = одиниці використаного газу * (базова комісія + пріоритетна комісія)
Базовий збір буде знищено, а пріоритетний збір буде використаний як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення більш високого пріоритетного збору під час відправки транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чайові", які користувачі сплачують валідаторам.
1. Розуміння оптимізації Gas в EVM
Коли смартконтракти компілюються за допомогою Solidity, контракт перетворюється на серію "операційних кодів", тобто opcodes.
Будь-який фрагмент коду операцій (, наприклад, створення контракту, виконання викликів повідомлень, доступ до зберігання облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP деякі коди операцій отримали коригування вартості Gas, що може відрізнятися від жовтої книги.
2.Базові поняття оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою ефективністю витрат на блокчейні EVM, уникнення дорогих за вартістю операцій.
У EVM наступні операції мають низьку вартість:
Операції з високими витратами включають:
! [Топ-10 найкращих практик оптимізації газу смарт-контрактів Ethereum](https://img-cdn.gateio.im/webp-social/moments-b237228ebe933741fb60f2e8bcb38405.webp0192837465674839201
Оптимізація витрат газу EVM: найкращі практики
На основі вищезазначених основних понять, ми підготували для спільноти розробників список найкращих практик оптимізації витрат Gas. Дотримуючись цих практик, розробники можуть знизити споживання Gas смартконтрактами, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
) 1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage### зберігання( є обмеженим ресурсом, споживання газу якого значно перевищує Memory) пам'ять(. Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають великі витрати газу.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більше ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують як мінімум 100 одиниць.
Обмеження методів використання зберігання включають:
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-30f0bc370a7b9ca65f3d623c31262b76.webp(
) 2. Упаковка змінних
Кількість Storage slot###, що використовується в смартконтрактах, а також спосіб, яким розробники представляють дані, суттєво вплине на споживання Gas.
Компіллятор 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 ), але їх синтаксис і структура кардинально відрізняються.
У більшості випадків мапи є більш ефективними та менш витратними, але масиви мають ітеративність та підтримують упаковку типів даних. Тому рекомендується віддавати перевагу використанню мап, коли ви керуєте списком даних, якщо не потрібно ітерувати або якщо можна оптимізувати витрати газу за допомогою упаковки типів даних.
( 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, щоб уникнути зайвих перевірок на переповнення або недоповнення, що дозволяє зекономити витрати на газ.
Крім того, компілятори версії 0.8.0 та вище більше не потребують використання бібліотеки SafeMath, оскільки сама компілятор вже має вбудовані функції захисту від переповнень і недостатньостей.
) 9. Оптимізація модифікатора
Код модифікатора вбудовується в змінену функцію, і щоразу, коли використовується модифікатор, його код копіюється. Це збільшує розмір байт-коду і підвищує споживання Gas.
Перетворивши логіку на внутрішню функцію _checkOwner######, дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, що може зменшити розмір байт-коду та знизити витрати на Gas.
( 10. Оптимізація короткого замикання
Для операторів || та && логічні обчислення підлягають короткому оцінюванню, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід помістити умови з низькою вартістю обчислень на початку, так можна уникнути дорогих обчислень.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp###
Додаткові загальні рекомендації
( 1. Видалити непотрібний код
Якщо в контракті є невикористані функції чи змінні, рекомендується їх видалити. Це найбільш прямий спосіб зменшення витрат на розгортання контракту та підтримки малого обсягу контракту.
Ось кілька корисних порад:
Використовуйте найефективніший алгоритм для виконання обчислень. Якщо результати певних обчислень безпосередньо використовуються в контракті, тоді слід усунути ці зайві обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У мережі Ethereum розробники можуть отримати Gas винагороди, звільняючи пам'ять. Якщо змінна більше не потрібна, її слід видалити за допомогою ключового слова delete або встановити на значення за замовчуванням.
Оптимізація циклів: уникайте дорогих операцій циклу, по можливості об'єднуйте цикли та виводьте повторні обчислення за межі тіла циклу.
) 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як криптографічні та хеш-операції. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, потрібно менше Gas. Використання попередньо скомпільованих контрактів може заощадити Gas, зменшуючи обсяги обчислювальної роботи, необхідної для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису на основі еліптичних кривих ###ECDSA### та алгоритм хешування SHA2-256. Використовуючи ці попередньо скомпільовані смартконтракти у смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи програм.
( 3. Використання інтегрованого асемблерного коду
Вбудована збірка ) in-line assembly ### дозволяє розробникам писати низькорівневий, але ефективний код, який може виконуватися безпосередньо EVM, без використання дорогих операційних кодів Solidity. Вбудована збірка також дозволяє більш точно контролювати використання пам'яті та сховища, що ще більше зменшує витрати на Gas. Крім того, вбудована збірка може виконувати деякі складні операції, які важко реалізувати, використовуючи тільки Solidity, надаючи більше гнучкості для оптимізації споживання Gas.
Проте використання вбудованого асемблера також може нести ризики та бути схильним до помилок. Тому його слід використовувати обережно, лише досвідченими розробниками.
( 4. Використання рішень Layer 2
Використання рішень Layer 2 може зменшити потребу в зберіганні та обчисленнях на основній мережі Ethereum.