Посібник з оптимізації Gas для смартконтрактів Ethereum
Газові витрати на основній мережі Ethereum завжди були болючим питанням, особливо це помітно під час перевантаженості мережі. У пікові моменти користувачі часто змушені платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є вкрай важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття окреслить механізм газових витрат Етер віртуальної машини (EVM), основні концепції оптимізації газових витрат, а також найкращі практики оптимізації газових витрат під час розробки смартконтрактів. Сподіваюся, що ці матеріали нададуть натхнення та практичну допомогу розробникам, а також допоможуть звичайним користувачам краще зрозуміти, як працюють газові витрати EVM, і спільно протистояти викликам у екосистемі блокчейн.
Вступ до механізму плати за газ EVM
У мережах, сумісних з EVM, "Gas" є одиницею вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурній компоновці EVM витрати газу поділяються на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис у пам'ять і зберігання.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата, щоб запобігти безкінечним циклам і атакам відмови в обслуговуванні (DoS). Плата, необхідна для завершення транзакції, називається "Gas fee".
З моменту набрання чинності Лондонським хардфорком EIP-1559(), плата за газ розраховується за наступною формулою:
Комісія за газ = одиниці використаного газу * ( базова комісія + пріоритетна комісія)
Базовий збір буде знищено, тоді як пріоритетний збір буде використовуватися як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення більш високого пріоритетного збору під час відправлення транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чайові", які користувачі платять валідаторам.
Коли смартконтракт компілюється за допомогою Solidity, контракт перетворюється на серію "операційних кодів", тобто opcodes.
Будь-яка частина операційного коду (, наприклад, створення контракту, виконання виклику повідомлення, доступ до сховища облікового запису та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP, деякі коди операцій мали змінену вартість Gas, що може відрізнятися від жовтої книги.
2.Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на блокчейні EVM, уникаючи операцій з дорогою вартістю Gas.
У EVM наступні операції мають низьку вартість:
Читання та запис змінних пам'яті
Читання констант і незмінних змінних
Читання та запис локальних змінних
Читання змінної calldata, наприклад, масиву та структури calldata
Виклик внутрішніх функцій
Операції з високими витратами включають:
Читання та запис змінних стану, що зберігаються в сховищі смартконтракту
Виклик зовнішніх функцій
Циклічна операція
Оптимізація витрат на газ EVM: найкращі практики
На основі вищезазначених основних концепцій, ми підготували для розробницької спільноти список найкращих практик оптимізації Gas витрат. Дотримуючись цих практик, розробники можуть знизити витрати Gas на смартконтракти, зменшити витрати на транзакції та створити більш ефективні та дружні до користувачів програми.
1. Намагайтеся зменшити використання пам'яті.
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання газу значно перевищує Memory( пам'ять). Кожен раз, коли смартконтракт читає або записує дані зі зберігання, виникають великі витрати газу.
Згідно з визначенням, наведеним у жовтій книзі Ethereum, вартість операцій зі зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці газу, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують щонайменше 100 одиниць.
Методи обмеження використання зберігання включають:
Зберігайте непостійні дані в пам'яті
Зменшення кількості змін у пам'яті: зберігаючи проміжні результати в пам'яті, а потім після завершення всіх обчислень виділяючи результати змінним зберігання.
2. Упаковка змінних
Кількість слотів зберігання (, що використовуються в смартконтрактах, а також спосіб, яким розробники представляють дані, значно вплине на витрати газу.
Компилятор Solidity під час компіляції упакує послідовні змінні зберігання і використовуватиме 32-байтний слот зберігання як базову одиницю зберігання змінних. Упаковка змінних означає раціональне розміщення змінних, щоб кілька змінних могли поміститися в один слот зберігання.
Завдяки цьому детальному налаштуванню, розробники можуть заощадити 20 000 одиниць газу. Зберігання невикористаного сховища потребує 20 000 газу, але тепер потрібно лише два сховища.
Оскільки кожен слот для зберігання споживає 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, а ця конверсія додатково споживає газ.
Окремо, тут використання 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 замість пам'яті
Змінні, оголошені в параметрах функції, можуть зберігатися в 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.
Перепроектування логіки в внутрішню функцію, що дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, може зменшити розмір байткоду та знизити витрати на газ.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
10. Оптимізація короткого замикання
Для || та && операторів логічні операції виконують коротке оцінювання, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід ставити умови з низькими витратами на обчислення на перше місце, так можна пропустити обчислення з високими витратами.
Додаткові загальні поради
1. Видалити непотрібний код
Якщо в контракті є невикористані функції чи змінні, рекомендується їх видалити. Це найдиректніший спосіб зменшити витрати на розгортання контракту та зберегти малий обсяг контракту.
Ось кілька корисних порад:
Використовуйте найефективніші алгоритми для обчислень. Якщо результати певних обчислень використовуються безпосередньо в контракті, тоді слід усунути ці надмірні обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У Ethereum розробники можуть отримати нагороду за газ, звільняючи пам'ять. Якщо змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати витратних операцій циклу, якомога більше об'єднувати цикли та виводити повторні обчислення за межі тіла циклу.
( 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як криптографічні та хеш-функції. Оскільки код не виконується в EVM, а виконується на локальному вузлі клієнта, то потрібно менше Gas. Використання попередньо скомпільованих контрактів може заощадити Gas шляхом зменшення обсягу обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису elliptic curve )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, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
18 лайків
Нагородити
18
7
Поділіться
Прокоментувати
0/400
PrivacyMaximalist
· 19год тому
газ так дорогий, краще піти на L2.
Переглянути оригіналвідповісти на0
0xSherlock
· 07-30 09:26
Коли газ буде таким же дешевим, як на L2?
Переглянути оригіналвідповісти на0
SnapshotBot
· 07-30 04:26
Ще краще пограти в L2.
Переглянути оригіналвідповісти на0
MetaverseLandlord
· 07-30 04:18
Просто сподіваюсь продати дорогий газ, щоб заробити трохи більше.
Переглянути оригіналвідповісти на0
BearMarketBuyer
· 07-30 04:17
газ занадто дорогий, поїдає людей!
Переглянути оригіналвідповісти на0
LiquidityHunter
· 07-30 04:08
оптимізація газу 0.7 разів арбітражний простір щойно зловлено три прослизання торговельних угод
Переглянути оригіналвідповісти на0
ContractFreelancer
· 07-30 04:07
Оптимізація непогана, якщо все працює, це просто супер.
Посібник з оптимізації Gas смартконтрактів Ethereum: Падіння витрат та підвищення ефективності
Посібник з оптимізації Gas для смартконтрактів Ethereum
Газові витрати на основній мережі Ethereum завжди були болючим питанням, особливо це помітно під час перевантаженості мережі. У пікові моменти користувачі часто змушені платити високі комісії за транзакції. Тому оптимізація газових витрат на етапі розробки смартконтрактів є вкрай важливою. Оптимізація споживання газу не лише може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний та ефективний досвід використання блокчейну.
Ця стаття окреслить механізм газових витрат Етер віртуальної машини (EVM), основні концепції оптимізації газових витрат, а також найкращі практики оптимізації газових витрат під час розробки смартконтрактів. Сподіваюся, що ці матеріали нададуть натхнення та практичну допомогу розробникам, а також допоможуть звичайним користувачам краще зрозуміти, як працюють газові витрати EVM, і спільно протистояти викликам у екосистемі блокчейн.
Вступ до механізму плати за газ EVM
У мережах, сумісних з EVM, "Gas" є одиницею вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурній компоновці EVM витрати газу поділяються на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис у пам'ять і зберігання.
Оскільки виконання кожної транзакції потребує обчислювальних ресурсів, стягується певна плата, щоб запобігти безкінечним циклам і атакам відмови в обслуговуванні (DoS). Плата, необхідна для завершення транзакції, називається "Gas fee".
З моменту набрання чинності Лондонським хардфорком EIP-1559(), плата за газ розраховується за наступною формулою:
Комісія за газ = одиниці використаного газу * ( базова комісія + пріоритетна комісія)
Базовий збір буде знищено, тоді як пріоритетний збір буде використовуватися як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення більш високого пріоритетного збору під час відправлення транзакції може підвищити ймовірність того, що транзакція буде включена до наступного блоку. Це схоже на "чайові", які користувачі платять валідаторам.
! 10 найкращих практик оптимізації газу для смарт-контрактів Ethereum
1. Розуміння оптимізації Gas в EVM
Коли смартконтракт компілюється за допомогою Solidity, контракт перетворюється на серію "операційних кодів", тобто opcodes.
Будь-яка частина операційного коду (, наприклад, створення контракту, виконання виклику повідомлення, доступ до сховища облікового запису та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після кількох змін EIP, деякі коди операцій мали змінену вартість Gas, що може відрізнятися від жовтої книги.
2.Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на блокчейні EVM, уникаючи операцій з дорогою вартістю Gas.
У EVM наступні операції мають низьку вартість:
Операції з високими витратами включають:
Оптимізація витрат на газ EVM: найкращі практики
На основі вищезазначених основних концепцій, ми підготували для розробницької спільноти список найкращих практик оптимізації Gas витрат. Дотримуючись цих практик, розробники можуть знизити витрати Gas на смартконтракти, зменшити витрати на транзакції та створити більш ефективні та дружні до користувачів програми.
1. Намагайтеся зменшити використання пам'яті.
У Solidity, Storage( зберігання) є обмеженим ресурсом, його споживання газу значно перевищує Memory( пам'ять). Кожен раз, коли смартконтракт читає або записує дані зі зберігання, виникають великі витрати газу.
Згідно з визначенням, наведеним у жовтій книзі Ethereum, вартість операцій зі зберігання перевищує вартість операцій з пам'яттю більш ніж у 100 разів. Наприклад, команди OPcodesmload та mstore споживають лише 3 одиниці газу, тоді як операції зберігання, такі як sload та sstore, навіть у найкращих умовах, коштують щонайменше 100 одиниць.
Методи обмеження використання зберігання включають:
2. Упаковка змінних
Кількість слотів зберігання (, що використовуються в смартконтрактах, а також спосіб, яким розробники представляють дані, значно вплине на витрати газу.
Компилятор Solidity під час компіляції упакує послідовні змінні зберігання і використовуватиме 32-байтний слот зберігання як базову одиницю зберігання змінних. Упаковка змінних означає раціональне розміщення змінних, щоб кілька змінних могли поміститися в один слот зберігання.
Завдяки цьому детальному налаштуванню, розробники можуть заощадити 20 000 одиниць газу. Зберігання невикористаного сховища потребує 20 000 газу, але тепер потрібно лише два сховища.
Оскільки кожен слот для зберігання споживає 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, а ця конверсія додатково споживає газ.
Окремо, тут використання 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 замість пам'яті
Змінні, оголошені в параметрах функції, можуть зберігатися в 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.
Перепроектування логіки в внутрішню функцію, що дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, може зменшити розмір байткоду та знизити витрати на газ.
![Ethereum смартконтракти Gas оптимізації десять найкращих практик])https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp###
10. Оптимізація короткого замикання
Для || та && операторів логічні операції виконують коротке оцінювання, тобто якщо перша умова вже може визначити результат логічного виразу, друга умова не буде оцінюватися.
Щоб оптимізувати споживання Gas, слід ставити умови з низькими витратами на обчислення на перше місце, так можна пропустити обчислення з високими витратами.
Додаткові загальні поради
1. Видалити непотрібний код
Якщо в контракті є невикористані функції чи змінні, рекомендується їх видалити. Це найдиректніший спосіб зменшити витрати на розгортання контракту та зберегти малий обсяг контракту.
Ось кілька корисних порад:
Використовуйте найефективніші алгоритми для обчислень. Якщо результати певних обчислень використовуються безпосередньо в контракті, тоді слід усунути ці надмірні обчислювальні процеси. По суті, будь-які невикористані обчислення повинні бути видалені.
У Ethereum розробники можуть отримати нагороду за газ, звільняючи пам'ять. Якщо змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати витратних операцій циклу, якомога більше об'єднувати цикли та виводити повторні обчислення за межі тіла циклу.
( 2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як криптографічні та хеш-функції. Оскільки код не виконується в EVM, а виконується на локальному вузлі клієнта, то потрібно менше Gas. Використання попередньо скомпільованих контрактів може заощадити Gas шляхом зменшення обсягу обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих смартконтрактів включають алгоритм цифрового підпису elliptic curve )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.