Десять найкращих практик для оптимізації Gas витрат смартконтрактів Ethereum
Газові витрати на основній мережі Ethereum завжди були складною проблемою, особливо це стає очевидним під час завантаження мережі. У пікові моменти користувачі часто змушені платити надзвичайно високі комісії за транзакції. Тому оптимізація витрат на газ на етапі розробки смартконтрактів є вкрай важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, що надає користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття розгляне механізм газових витрат Етеріум віртуальної машини (EVM), основні концепції оптимізації газових витрат, а також найкращі практики оптимізації газових витрат під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як працюють газові витрати EVM, спільно долаючи виклики в екосистемі блокчейн.
Огляд механізму плати Gas в 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, наприклад масиви та структури calldata
Виклик внутрішньої функції
Високовартісні операції включають:
Читати та записувати стан змінних, що зберігаються у сховищі смартконтракту
Виклик зовнішніх функцій
Циклічна операція
Оптимізація витрат газу EVM: найкращі практики
На основі вищезазначених основних концепцій ми підготували список найкращих практик оптимізації Gas-кошту для спільноти розробників. Дотримуючись цих практик, розробники можуть зменшити витрати Gas для смартконтрактів, знизити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
1. Намагайтеся зменшити використання пам'яті.
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання газу значно вище, ніж у Memory( пам'яті). Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають високі витрати на газ.
Згідно з визначенням, наведеним у жовтій книзі Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcode smload і mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload і sstore, навіть у найкращих умовах, коштують принаймні 100 одиниць.
Обмеження методів використання зберігання включають:
Зберігайте непостійні дані в пам'яті
Зменшення кількості змін у зберіганні: зберігаючи проміжні результати в пам'яті, а після завершення всіх обчислень розподіляючи результати між змінними зберігання.
2.Упаковка змінних
Кількість сховищ, які використовуються в смартконтрактах Storage slot( та спосіб, яким розробники представляють дані, суттєво вплине на витрати Gas.
Компіллятор Solidity під час компіляції упаковує послідовні змінні зберігання і використовує 32-байтний слот зберігання як основну одиницю для зберігання змінних. Упаковка змінних означає раціональне розміщення змінних, щоб кілька змінних могли бути розміщені в одному слоту зберігання.
Завдяки цій детальній настройці, розробники можуть зекономити 20 000 одиниць Gas. Зберігання невикористаного сховища вимагає 20 000 Gas, але тепер потрібно лише два сховища.
Оскільки кожен слот зберігання споживає Gas, упаковка змінних оптимізує використання Gas шляхом зменшення кількості необхідних слотів зберігання.
![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 змінні в пам'ять/сховище.
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 замість пам'яті
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Основна різниця між ними полягає в тому, що memory може бути змінена функцією, тоді як calldata є незмінною.
Запам'ятайте цей принцип: якщо параметри функції є тільки для читання, слід віддавати перевагу використанню calldata, а не memory. Це допоможе уникнути непотрібних операцій копіювання з calldata функції до memory.
( 7.Якомога більше використовуйте ключові слова 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)###, можна дозволити повторне використання цієї внутрішньої функції в модифікаторі, що зменшить розмір байт-коду та знизить витрати на Gas.
![Ethereum смартконтракти Gas оптимізація десять кращих практик]###https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp(
) 10. Оптимізація короткого замикання
Для || та && операторів логічні операції будуть підлягати короткій оцінці, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, так можна пропустити обчислення з високими витратами.
Додаткові загальні рекомендації
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, без необхідності використовувати дорогі операції Solidity. Вбудована збірка також дозволяє більш точно контролювати використання пам'яті та зберігання, що ще більше зменшує витрати на Gas. Крім того, вбудована збірка може виконувати деякі складні операції, які важко реалізувати, використовуючи лише Solidity, що забезпечує більше гнучкості для оптимізації споживання Gas.
Однак використання вбудованого асемблера також може нести ризики та бути схильним до помилок. Тому слід обережно використовувати, тільки для досвідчених розробників.
4. Використання рішень Layer 2
Використання рішень Layer 2 може зменшити обсяг даних, які потрібно зберігати та обробляти на основній мережі Ethereum.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
21 лайків
Нагородити
21
6
Репост
Поділіться
Прокоментувати
0/400
LootboxPhobia
· 07-07 22:43
газ справді не пахне
Переглянути оригіналвідповісти на0
OnChainSleuth
· 07-06 04:36
Знову обман для дурнів з Gas fee
Переглянути оригіналвідповісти на0
TokenomicsTrapper
· 07-05 08:12
лmao ще одна тема "газової оптимізації"... просто почекайте, поки ви побачите каскад ліквідацій, коли ці "оптимізовані" контракти будуть знищені під навантаженням
Десять найкращих практик для оптимізації газових витрат смартконтрактів Ethereum
Десять найкращих практик для оптимізації Gas витрат смартконтрактів Ethereum
Газові витрати на основній мережі Ethereum завжди були складною проблемою, особливо це стає очевидним під час завантаження мережі. У пікові моменти користувачі часто змушені платити надзвичайно високі комісії за транзакції. Тому оптимізація витрат на газ на етапі розробки смартконтрактів є вкрай важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, що надає користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття розгляне механізм газових витрат Етеріум віртуальної машини (EVM), основні концепції оптимізації газових витрат, а також найкращі практики оптимізації газових витрат під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти, як працюють газові витрати EVM, спільно долаючи виклики в екосистемі блокчейн.
Огляд механізму плати Gas в 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 для смартконтрактів, знизити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
1. Намагайтеся зменшити використання пам'яті.
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання газу значно вище, ніж у Memory( пам'яті). Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають високі витрати на газ.
Згідно з визначенням, наведеним у жовтій книзі Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcode smload і mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload і sstore, навіть у найкращих умовах, коштують принаймні 100 одиниць.
Обмеження методів використання зберігання включають:
2.Упаковка змінних
Кількість сховищ, які використовуються в смартконтрактах Storage slot( та спосіб, яким розробники представляють дані, суттєво вплине на витрати Gas.
Компіллятор Solidity під час компіляції упаковує послідовні змінні зберігання і використовує 32-байтний слот зберігання як основну одиницю для зберігання змінних. Упаковка змінних означає раціональне розміщення змінних, щоб кілька змінних могли бути розміщені в одному слоту зберігання.
Завдяки цій детальній настройці, розробники можуть зекономити 20 000 одиниць Gas. Зберігання невикористаного сховища вимагає 20 000 Gas, але тепер потрібно лише два сховища.
Оскільки кожен слот зберігання споживає Gas, упаковка змінних оптимізує використання Gas шляхом зменшення кількості необхідних слотів зберігання.
![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 змінні в пам'ять/сховище.
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 замість пам'яті
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Основна різниця між ними полягає в тому, що memory може бути змінена функцією, тоді як calldata є незмінною.
Запам'ятайте цей принцип: якщо параметри функції є тільки для читання, слід віддавати перевагу використанню calldata, а не memory. Це допоможе уникнути непотрібних операцій копіювання з calldata функції до memory.
( 7.Якомога більше використовуйте ключові слова 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)###, можна дозволити повторне використання цієї внутрішньої функції в модифікаторі, що зменшить розмір байт-коду та знизить витрати на Gas.
![Ethereum смартконтракти Gas оптимізація десять кращих практик]###https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp(
) 10. Оптимізація короткого замикання
Для || та && операторів логічні операції будуть підлягати короткій оцінці, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, так можна пропустити обчислення з високими витратами.
Додаткові загальні рекомендації
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, без необхідності використовувати дорогі операції Solidity. Вбудована збірка також дозволяє більш точно контролювати використання пам'яті та зберігання, що ще більше зменшує витрати на Gas. Крім того, вбудована збірка може виконувати деякі складні операції, які важко реалізувати, використовуючи лише Solidity, що забезпечує більше гнучкості для оптимізації споживання Gas.
Однак використання вбудованого асемблера також може нести ризики та бути схильним до помилок. Тому слід обережно використовувати, тільки для досвідчених розробників.
4. Використання рішень Layer 2
Використання рішень Layer 2 може зменшити обсяг даних, які потрібно зберігати та обробляти на основній мережі Ethereum.
Як самокрутки,