Головною проблемою, з якою стикаються розробники та користувачі, є витрати на Gas в основній мережі Ethereum, особливо це стає помітно під час завантаженості мережі. У пікові години транзакцій користувачі зазвичай змушені платити високі збори. Тому оптимізація витрат на Gas на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання Gas може не лише ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний і ефективний досвід використання блокчейну.
Ця стаття розгляне механізм плати за Gas в Ethereum Virtual Machine (EVM), основні концепції оптимізації плати за Gas, а також найкращі практики оптимізації плати за Gas під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти механізм плати за Gas в EVM, щоб спільно долати виклики в екосистемі блокчейн.
Огляд механізму плати Gas в EVM
У сумісних з EVM мережах, "Gas" є одиницею, що використовується для вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурі EVM споживання газу в основному поділяється на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті і сховища.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і атакам відмови в обслуговуванні ( DoS ). Плата, необхідна для завершення транзакції, називається "Gas-кошти".
З моменту набрання чинності хардфорком Лондона EIP-1559(), плата за газ розраховується за наступною формулою:
Комісія за газ = одиниці використаного газу * (базова комісія + плата за пріоритет)
Базовий збір буде знищено, а пріоритетний збір слугуватиме як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час відправлення транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чаєві", які користувачі платять валідаторам.
Розуміння оптимізації Gas в EVM
Коли смартконтракти компілюються за допомогою Solidity, контракти перетворюються на ряд "операційних кодів", тобто opcodes.
Будь-який фрагмент байтового коду (, наприклад, створення смартконтракту, виконання виклику повідомлення, доступ до сховища рахунків та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після численних змін EIP, деякі коди операцій тепер мають відкориговану вартість Gas, що може відрізнятися від вказаного в жовтій книзі.
Основні поняття оптимізації Gas
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартістю ефективності на блокчейні EVM, уникаючи операцій з високими витратами Gas.
У EVM наступні операції мають нижчу вартість:
Читання та запис змінних пам'яті
Читання констант і незмінних змінних
Читати та писати локальні змінні
Читання змінної calldata, наприклад масиву та структурі calldata
Виклик внутрішніх функцій
Операції з високими витратами включають:
Читати та записувати стан змінних, що зберігаються в смартконтракті
Виклик зовнішніх функцій
Циклічна операція
Оптимізація витрат на газ EVM: найкращі практики
На основі наведених основних концепцій, нижче наведено список найкращих практик оптимізації Gas-кошту. Дотримуючись цих практик, розробники можуть знизити споживання Gas-кошту смартконтрактів, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, його витрати газу значно вищі, ніж у Memory( пам'яті). Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають високі витрати газу.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload і sstore, навіть в найкращих умовах, коштують щонайменше 100 одиниць.
Обмеження методів використання зберігання включає:
Зберігайте непостійні дані в пам'яті
Зменшити кількість змін у пам'яті: зберігати проміжні результати в пам'яті, а після завершення всіх обчислень, призначати результати змінним пам'яті.
2. Упаковка змінних
Кількість storage slot(, що використовується в смартконтрактах, а також спосіб, яким розробники представляють дані, значно вплине на витрати Gas.
Компілятор Solidity під час компіляції упаковує послідовні змінні зберігання і використовує 32-байтовий слот пам'яті як базову одиницю зберігання змінних. Упаковка змінних означає, що за рахунок раціонального розміщення змінних декілька змінних можуть поміститися в одному слоті пам'яті.
Завдяки цій детальній корекції, розробники можуть зекономити 20 000 одиниць Gas. Для зберігання невикористаного сховища потрібно було витратити 20 000 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. Як правило, змінні фіксованого розміру споживають менше 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 не зберігаються в сховищі контракту. Ці змінні розраховуються під час компіляції та зберігаються в байт-коді контракту. Тому вартість доступу до них значно нижча, ніж у випадку зі сховищем, тому рекомендується використовувати ключові слова 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.
Переписавши логіку у вигляді внутрішньої функції, дозволяючи повторно використовувати цю внутрішню функцію в модифікаторах, можна зменшити розмір байт-коду та знизити витрати на Gas.
![Ethereum смартконтракти Gas оптимізація десятка найкращих практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
10. Оптимізація короткого замикання
Для || та && операторів логічні операції зазнають короткозамикання, тобто, якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, це дозволить, ймовірно, пропустити витратні обчислення.
Додаткові загальні рекомендації
1. Видалити непотрібний код
Якщо в контракті є невикористані функції чи змінні, рекомендується їх видалити. Це найбільш прямий спосіб зменшення витрат на розгортання контракту та підтримки малого обсягу контракту.
Ось кілька корисних порад:
Використовуйте найбільш ефективні алгоритми для обчислень. Якщо в смартконтрактах безпосередньо використовуються результати певних обчислень, то слід усунути ці зайві обчислювальні процеси. Сутність полягає в тому, що будь-які невикористані обчислення повинні бути видалені.
В Ethereum розробники можуть отримувати винагороду Gas, звільняючи місце для зберігання. Якщо змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати дорогих циклічних операцій, по можливості об'єднувати цикли та виносити повторювані обчислення за межі тіла циклу.
( 2. Використання попередньо скомпільованих смартконтрактів
Препродані контракти надають складні бібліотечні функції, такі як криптографічні та хеш-операції. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, то потрібно менше Gas. Використання препроданих контрактів дозволяє заощадити Gas, зменшуючи обсяг обчислювальних витрат, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих контрактів включають алгоритм цифрового підпису на основі еліптичних кривих )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, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
4
Поділіться
Прокоментувати
0/400
MEV_Whisperer
· 08-02 05:53
газ знову зростає, торгувати контрактами надзвичайно важко
Переглянути оригіналвідповісти на0
fomo_fighter
· 08-02 05:46
газ високий до нудоти, де прохолодніше, там і сидітимемо
Переглянути оригіналвідповісти на0
ApeWithAPlan
· 08-02 05:39
газ навіть якщо дорогий, все одно ETH найсмачніший
Десять найкращих практик оптимізації Gas-кошту смартконтрактів Ethereum
Найкращі практики оптимізації газових витрат смартконтрактів Ethereum
Головною проблемою, з якою стикаються розробники та користувачі, є витрати на Gas в основній мережі Ethereum, особливо це стає помітно під час завантаженості мережі. У пікові години транзакцій користувачі зазвичай змушені платити високі збори. Тому оптимізація витрат на Gas на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання Gas може не лише ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний і ефективний досвід використання блокчейну.
Ця стаття розгляне механізм плати за Gas в Ethereum Virtual Machine (EVM), основні концепції оптимізації плати за Gas, а також найкращі практики оптимізації плати за Gas під час розробки смартконтрактів. Сподіваємося, що ці матеріали надихнуть розробників і нададуть практичну допомогу, а також допоможуть звичайним користувачам краще зрозуміти механізм плати за Gas в EVM, щоб спільно долати виклики в екосистемі блокчейн.
Огляд механізму плати Gas в EVM
У сумісних з EVM мережах, "Gas" є одиницею, що використовується для вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурі EVM споживання газу в основному поділяється на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті і сховища.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і атакам відмови в обслуговуванні ( DoS ). Плата, необхідна для завершення транзакції, називається "Gas-кошти".
З моменту набрання чинності хардфорком Лондона EIP-1559(), плата за газ розраховується за наступною формулою:
Комісія за газ = одиниці використаного газу * (базова комісія + плата за пріоритет)
Базовий збір буде знищено, а пріоритетний збір слугуватиме як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час відправлення транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чаєві", які користувачі платять валідаторам.
Розуміння оптимізації Gas в EVM
Коли смартконтракти компілюються за допомогою Solidity, контракти перетворюються на ряд "операційних кодів", тобто opcodes.
Будь-який фрагмент байтового коду (, наприклад, створення смартконтракту, виконання виклику повідомлення, доступ до сховища рахунків та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після численних змін EIP, деякі коди операцій тепер мають відкориговану вартість Gas, що може відрізнятися від вказаного в жовтій книзі.
Основні поняття оптимізації Gas
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартістю ефективності на блокчейні EVM, уникаючи операцій з високими витратами Gas.
У EVM наступні операції мають нижчу вартість:
Операції з високими витратами включають:
Оптимізація витрат на газ EVM: найкращі практики
На основі наведених основних концепцій, нижче наведено список найкращих практик оптимізації Gas-кошту. Дотримуючись цих практик, розробники можуть знизити споживання Gas-кошту смартконтрактів, зменшити витрати на транзакції та створити більш ефективні та зручні для користувачів додатки.
1. Намагайтеся зменшити використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, його витрати газу значно вищі, ніж у Memory( пам'яті). Кожного разу, коли смартконтракт читає або записує дані зі зберігання, виникають високі витрати газу.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload і sstore, навіть в найкращих умовах, коштують щонайменше 100 одиниць.
Обмеження методів використання зберігання включає:
2. Упаковка змінних
Кількість storage slot(, що використовується в смартконтрактах, а також спосіб, яким розробники представляють дані, значно вплине на витрати Gas.
Компілятор Solidity під час компіляції упаковує послідовні змінні зберігання і використовує 32-байтовий слот пам'яті як базову одиницю зберігання змінних. Упаковка змінних означає, що за рахунок раціонального розміщення змінних декілька змінних можуть поміститися в одному слоті пам'яті.
Завдяки цій детальній корекції, розробники можуть зекономити 20 000 одиниць Gas. Для зберігання невикористаного сховища потрібно було витратити 20 000 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. Як правило, змінні фіксованого розміру споживають менше 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 не зберігаються в сховищі контракту. Ці змінні розраховуються під час компіляції та зберігаються в байт-коді контракту. Тому вартість доступу до них значно нижча, ніж у випадку зі сховищем, тому рекомендується використовувати ключові слова 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.
Переписавши логіку у вигляді внутрішньої функції, дозволяючи повторно використовувати цю внутрішню функцію в модифікаторах, можна зменшити розмір байт-коду та знизити витрати на Gas.
![Ethereum смартконтракти Gas оптимізація десятка найкращих практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
10. Оптимізація короткого замикання
Для || та && операторів логічні операції зазнають короткозамикання, тобто, якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, це дозволить, ймовірно, пропустити витратні обчислення.
Додаткові загальні рекомендації
1. Видалити непотрібний код
Якщо в контракті є невикористані функції чи змінні, рекомендується їх видалити. Це найбільш прямий спосіб зменшення витрат на розгортання контракту та підтримки малого обсягу контракту.
Ось кілька корисних порад:
Використовуйте найбільш ефективні алгоритми для обчислень. Якщо в смартконтрактах безпосередньо використовуються результати певних обчислень, то слід усунути ці зайві обчислювальні процеси. Сутність полягає в тому, що будь-які невикористані обчислення повинні бути видалені.
В Ethereum розробники можуть отримувати винагороду Gas, звільняючи місце для зберігання. Якщо змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати дорогих циклічних операцій, по можливості об'єднувати цикли та виносити повторювані обчислення за межі тіла циклу.
( 2. Використання попередньо скомпільованих смартконтрактів
Препродані контракти надають складні бібліотечні функції, такі як криптографічні та хеш-операції. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, то потрібно менше Gas. Використання препроданих контрактів дозволяє заощадити Gas, зменшуючи обсяг обчислювальних витрат, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих контрактів включають алгоритм цифрового підпису на основі еліптичних кривих )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.