Стратегії оптимізації витрат Gas у розробці смартконтрактів
Проблема вартості Gas в основній мережі Ethereum завжди була в центрі уваги розробників і користувачів, особливо під час перевантаження мережі. У пікові моменти транзакцій користувачі часто змушені платити високі збори. Тому оптимізація вартості Gas на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання Gas не тільки може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний і ефективний досвід використання блокчейну.
У цій статті буде розглянуто механізм плати за газ в Ethereum Virtual Machine (EVM), пов'язані ключові концепції, а також найкращі практики оптимізації плати за газ під час розробки смартконтрактів. Сподіваємось, що цей матеріал надасть натхнення та корисну допомогу розробникам, а також допоможе звичайним користувачам краще зрозуміти, як працює плата за газ в EVM, щоб спільно долати виклики в екосистемі блокчейну.
Вступ до механізму Gas-оплат EVM
У мережах, що підтримують EVM, Gas є одиницею, що використовується для вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурі EVM споживання Gas переважно ділиться на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті і зберігання.
Оскільки виконання кожної транзакції вимагає обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і атакам відмови в обслуговуванні ( DoS ). Плата, необхідна для завершення транзакції, називається Gas платою.
З моменту набуття чинності лондонським хардфорком EIP-1559( ), плата за газ розраховується за наступною формулою:
Газовий збір = одиниці використаного газу * (базовий збір + пріоритетний збір)
Базовий збір буде знищено, а пріоритетний збір буде використано як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час надсилання транзакції може підвищити ймовірність її включення до наступного блоку.
Розуміння оптимізації Gas в EVM
Коли компілюється смартконтракт на Solidity, контракт перетворюється на ряд операційних кодів (opcodes).
Будь-яка операція з кодом (, наприклад, створення смартконтракту, виконання викликів повідомлень, доступ до сховища облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після багатьох змін EIP, вартість Gas деяких опкодів була скоригована і може відрізнятися від зазначеної в жовтій книзі.
Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на блокчейні EVM, уникаючи дорогих за Gas операцій.
У EVM наступні операції мають нижчу вартість:
Читання та запис змінних у пам'яті
Читання констант і змінних, що не змінюються
Читання та запис локальних змінних
Читати змінну calldata, наприклад, масив та структури calldata
Виклик внутрішньої функції
Операції з високими витратами включають:
Читати та записувати стан змінних, які зберігаються в смартконтрактах
Виклик зовнішніх функцій
Циклічна операція
Оптимізація витрат газу EVM: найкращі практики
На основі вищезазначених базових концепцій ми підготували для спільноти розробників список найкращих практик оптимізації плати за газ. Дотримуючись цих практик, розробники можуть знизити витрати на газ для смартконтрактів, зменшити витрати на транзакції та створити більш ефективні та дружні до користувача додатки.
1. Намагайтеся мінімізувати використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, витрати Gas на яке значно вищі, ніж у Memory( пам'яті). Кожен раз, коли смартконтракти читають або записують дані з/в зберігання, виникають великі витрати Gas.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій пам'яті більш ніж у 100 разів. Наприклад, команди OPcodesmload і mstore витрачають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload і sstore, навіть у найбільш ідеальних умовах, коштують як мінімум 100 одиниць.
Обмеження методів використання сховища включає:
Зберігати непостійні дані в пам'яті
Зменшення кількості змін у пам'яті: зберігаючи проміжні результати в пам'яті, а потім, після завершення всіх обчислень, присвоюючи результати змінним пам'яті.
2. Упаковка змінних
Кількість слотів зберігання (, що використовуються в смартконтрактах, а також спосіб, яким розробники представляють дані, суттєво вплине на витрати газу.
Компилятор Solidity під час компіляції упаковує послідовні змінні зберігання та використовує 32-байтовий слот зберігання як основну одиницю зберігання змінних. Упаковка змінних означає раціональне розміщення змінних, що дозволяє кільком змінним вміститися в один слот зберігання.
Завдяки цій детальній корекції розробники можуть зекономити 20 000 одиниць Gas), оскільки зберігання невикористаного сховища вимагає 20 000 Gas(.
Оскільки кожен слот зберігання споживає Gas, упаковка змінних оптимізує використання Gas, зменшуючи кількість необхідних слотів зберігання.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum])https://img-cdn.gateio.im/webp-social/moments-30f0bc370a7b9ca65f3d623c31262b76.webp(
) 3. Оптимізація типів даних
Змінна може бути представлена різними типами даних, але вартість операцій, пов'язаних з різними типами даних, також різна. Вибір відповідного типу даних допомагає оптимізувати використання Gas.
Наприклад, у Solidity цілі числа можна розділити на різні розміри: uint8, uint16, uint32 тощо. Оскільки EVM виконує операції в одиницях по 256 біт, використання uint8 означає, що EVM спочатку повинна перетворити його на uint256, а це перетворення додатково витрачає Gas.
Окремо, використання uint256 дешевше, ніж uint8. Однак, якщо використовувати упаковку змінних для оптимізації, то це інша справа. Якщо розробник зможе упакувати чотири змінні uint8 в один слот пам'яті, то загальна вартість їх ітерації буде нижчою, ніж у чотирьох змінних uint256. Таким чином, смартконтракти можуть читати і записувати один слот пам'яті, і за одну операцію помістити чотири змінні uint8 в пам'ять/сховище.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp(
) 4. Використання змінних фіксованого розміру замість динамічних змінних
Якщо дані можна контролювати в межах 32 байтів, рекомендується використовувати тип даних bytes32 замість bytes або strings. Загалом, змінні фіксованого розміру споживають менше газу, ніж змінні змінного розміру. Якщо довжину байтів можна обмежити, намагайтеся вибрати мінімальну довжину від bytes1 до bytes32.
![Топ-10 найкращих практик оптимізації газу для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-55fcdb765912ef9cd238c46b1d248cff.webp(
) 5. Відображення та масиви
Список даних Solidity може бути представленим двома типами даних: масиви ### Arrays ( та відображення ) Mappings (, але їх синтаксис і структура кардинально відрізняються.
У більшості випадків відображення є більш ефективним та дешевшим, але масиви мають ітерабельність і підтримують упаковку типів даних. Тому рекомендується надавати перевагу відображенню при управлінні списками даних, якщо не потрібно ітерувати або якщо можна оптимізувати споживання газу за допомогою упаковки типів даних.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum])https://img-cdn.gateio.im/webp-social/moments-5f3d7e103e47c886f50599cffe35c707.webp(
) 6. Використання calldata замість memory
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Головна відмінність між ними полягає в тому, що memory може бути зміненою функцією, тоді як calldata є незмінною.
Запам'ятайте цей принцип: якщо параметри функції є лише для читання, слід надавати перевагу використанню calldata, а не memory. Це дозволяє уникнути непотрібних операцій копіювання з функціонального calldata до memory.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp(
) 7. Якомога більше використовуйте ключові слова Constant/Immutable
Константні/незмінні змінні не зберігаються у сховищі контракту. Ці змінні обчислюються під час компіляції та зберігаються в байт-коді контракту. Тому їх вартість доступу значно нижча в порівнянні зі сховищем, рекомендовано використовувати ключові слова Constant або Immutable якомога більше.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp(
) 8. Використовуйте Unchecked, щоб забезпечити, що переповнення/недостатність не відбудеться.
Коли розробники можуть впевнитися, що арфметичні операції не призведуть до переповнення або недоповнення, вони можуть використовувати ключове слово unchecked, введене в Solidity v0.8.0, щоб уникнути зайвих перевірок на переповнення або недоповнення, таким чином заощаджуючи витрати на Gas.
Крім того, компілятор версії 0.8.0 та вище більше не потребує використання бібліотеки SafeMath, оскільки сам компілятор вже вбудував функції захисту від переповнень та недостач.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp(
) 9. Оптимізація модифікаторів
Код модифікатора вбудований у змінену функцію, і щоразу, коли використовується модифікатор, його код копіюється. Це збільшує розмір байткоду та підвищує споживання Gas.
Перетворивши логіку в внутрішню функцію, що дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, можна зменшити розмір байт-коду та знизити витрати на газ.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 10. Оптимізація короткого замикання
Для логічних операторів || та && відбувається коротке оцінювання, тобто, якщо перша умова вже може визначити результат логічного виразу, друга умова не оцінюється.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, так можна пропустити обчислення з високою вартістю.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-a141884dcdcdc56faff12eee2601b7b7.webp(
Додаткові загальні рекомендації
) 1. Видалити непотрібний код
Якщо в контракті є невикористані функції або змінні, рекомендується їх видалити. Це найпростіший спосіб зменшити витрати на розгортання контракту та зберегти малий обсяг контракту.
Ось кілька корисних порад:
Використовуйте найефективніші алгоритми для обчислень. Якщо в смартконтракті безпосередньо використовуються результати певних обчислень, то варто усунути ці зайві обчислювальні процеси. По суті, будь-які непотрібні обчислення мають бути видалені.
У Ethereum розробники можуть отримувати газові винагороди, звільняючи простір для зберігання. Якщо змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати витратних циклічних операцій, по можливості об'єднувати цикли та виносити повторювані обчислення з тіла циклу.
2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як шифрування та хешування. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, потрібно менше газу. Використання попередньо скомпільованих контрактів може заощадити газ, зменшуючи обсяг обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих контрактів включають алгоритм цифрового підпису еліптичних кривих ###ECDSA( та алгоритм хешування SHA2-256. Використовуючи ці попередньо скомпільовані контракти в смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи програм.
) 3. Використання внутрішньоінлінгового асемблерного коду
Вбудована асемблія ### in-line assembly ( дозволяє розробникам писати низькорівневий, але ефективний код, який може бути безпосередньо виконаний EVM, без необхідності використовувати дорогі операції Solidity. Вбудована асемблія також дозволяє точніше контролювати використання пам'яті та сховища, що ще більше зменшує витрати на газ. Крім того, вбудована асемблія може виконувати деякі складні операції, які важко реалізувати лише за допомогою Solidity, що забезпечує більшу гнучкість для оптимізації споживання газу.
Проте використання вбудованого асемблера також може бути ризикованим і легко призвести до помилок. Тому його слід використовувати обережно, лише досвідченим розробникам.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Оптимізаційні стратегії та найкращі практики Gas-кошту смартконтрактів Ethereum
Стратегії оптимізації витрат Gas у розробці смартконтрактів
Проблема вартості Gas в основній мережі Ethereum завжди була в центрі уваги розробників і користувачів, особливо під час перевантаження мережі. У пікові моменти транзакцій користувачі часто змушені платити високі збори. Тому оптимізація вартості Gas на етапі розробки смартконтрактів є надзвичайно важливою. Оптимізація споживання Gas не тільки може ефективно знизити витрати на транзакції, але й підвищити ефективність транзакцій, забезпечуючи користувачам більш економічний і ефективний досвід використання блокчейну.
У цій статті буде розглянуто механізм плати за газ в Ethereum Virtual Machine (EVM), пов'язані ключові концепції, а також найкращі практики оптимізації плати за газ під час розробки смартконтрактів. Сподіваємось, що цей матеріал надасть натхнення та корисну допомогу розробникам, а також допоможе звичайним користувачам краще зрозуміти, як працює плата за газ в EVM, щоб спільно долати виклики в екосистемі блокчейну.
Вступ до механізму Gas-оплат EVM
У мережах, що підтримують EVM, Gas є одиницею, що використовується для вимірювання обчислювальної потужності, необхідної для виконання певних операцій.
У структурі EVM споживання Gas переважно ділиться на три частини: виконання операцій, виклики зовнішніх повідомлень, а також читання та запис пам'яті і зберігання.
Оскільки виконання кожної транзакції вимагає обчислювальних ресурсів, стягується певна плата для запобігання безкінечним циклам і атакам відмови в обслуговуванні ( DoS ). Плата, необхідна для завершення транзакції, називається Gas платою.
З моменту набуття чинності лондонським хардфорком EIP-1559( ), плата за газ розраховується за наступною формулою:
Газовий збір = одиниці використаного газу * (базовий збір + пріоритетний збір)
Базовий збір буде знищено, а пріоритетний збір буде використано як стимул, щоб заохотити валідаторів додавати транзакції до блокчейну. Встановлення вищого пріоритетного збору під час надсилання транзакції може підвищити ймовірність її включення до наступного блоку.
Розуміння оптимізації Gas в EVM
Коли компілюється смартконтракт на Solidity, контракт перетворюється на ряд операційних кодів (opcodes).
Будь-яка операція з кодом (, наприклад, створення смартконтракту, виконання викликів повідомлень, доступ до сховища облікових записів та виконання операцій на віртуальній машині ) має визнану вартість споживання Gas, ці витрати зафіксовані в жовтій книзі Ethereum.
Після багатьох змін EIP, вартість Gas деяких опкодів була скоригована і може відрізнятися від зазначеної в жовтій книзі.
Основні концепції оптимізації газу
Основна ідея оптимізації Gas полягає в пріоритетному виборі операцій з високою вартісною ефективністю на блокчейні EVM, уникаючи дорогих за Gas операцій.
У EVM наступні операції мають нижчу вартість:
Операції з високими витратами включають:
Оптимізація витрат газу EVM: найкращі практики
На основі вищезазначених базових концепцій ми підготували для спільноти розробників список найкращих практик оптимізації плати за газ. Дотримуючись цих практик, розробники можуть знизити витрати на газ для смартконтрактів, зменшити витрати на транзакції та створити більш ефективні та дружні до користувача додатки.
1. Намагайтеся мінімізувати використання пам'яті
У Solidity, Storage( зберігання) є обмеженим ресурсом, витрати Gas на яке значно вищі, ніж у Memory( пам'яті). Кожен раз, коли смартконтракти читають або записують дані з/в зберігання, виникають великі витрати Gas.
Згідно з визначенням з жовтої книги Ethereum, вартість операцій зберігання перевищує вартість операцій пам'яті більш ніж у 100 разів. Наприклад, команди OPcodesmload і mstore витрачають лише 3 одиниці Gas, тоді як операції зберігання, такі як sload і sstore, навіть у найбільш ідеальних умовах, коштують як мінімум 100 одиниць.
Обмеження методів використання сховища включає:
2. Упаковка змінних
Кількість слотів зберігання (, що використовуються в смартконтрактах, а також спосіб, яким розробники представляють дані, суттєво вплине на витрати газу.
Компилятор Solidity під час компіляції упаковує послідовні змінні зберігання та використовує 32-байтовий слот зберігання як основну одиницю зберігання змінних. Упаковка змінних означає раціональне розміщення змінних, що дозволяє кільком змінним вміститися в один слот зберігання.
Завдяки цій детальній корекції розробники можуть зекономити 20 000 одиниць Gas), оскільки зберігання невикористаного сховища вимагає 20 000 Gas(.
Оскільки кожен слот зберігання споживає Gas, упаковка змінних оптимізує використання Gas, зменшуючи кількість необхідних слотів зберігання.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum])https://img-cdn.gateio.im/webp-social/moments-30f0bc370a7b9ca65f3d623c31262b76.webp(
) 3. Оптимізація типів даних
Змінна може бути представлена різними типами даних, але вартість операцій, пов'язаних з різними типами даних, також різна. Вибір відповідного типу даних допомагає оптимізувати використання Gas.
Наприклад, у Solidity цілі числа можна розділити на різні розміри: uint8, uint16, uint32 тощо. Оскільки EVM виконує операції в одиницях по 256 біт, використання uint8 означає, що EVM спочатку повинна перетворити його на uint256, а це перетворення додатково витрачає Gas.
Окремо, використання uint256 дешевше, ніж uint8. Однак, якщо використовувати упаковку змінних для оптимізації, то це інша справа. Якщо розробник зможе упакувати чотири змінні uint8 в один слот пам'яті, то загальна вартість їх ітерації буде нижчою, ніж у чотирьох змінних uint256. Таким чином, смартконтракти можуть читати і записувати один слот пам'яті, і за одну операцію помістити чотири змінні uint8 в пам'ять/сховище.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-995905cb414526d4d991899d0c2e6443.webp(
) 4. Використання змінних фіксованого розміру замість динамічних змінних
Якщо дані можна контролювати в межах 32 байтів, рекомендується використовувати тип даних bytes32 замість bytes або strings. Загалом, змінні фіксованого розміру споживають менше газу, ніж змінні змінного розміру. Якщо довжину байтів можна обмежити, намагайтеся вибрати мінімальну довжину від bytes1 до bytes32.
![Топ-10 найкращих практик оптимізації газу для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-55fcdb765912ef9cd238c46b1d248cff.webp(
) 5. Відображення та масиви
Список даних Solidity може бути представленим двома типами даних: масиви ### Arrays ( та відображення ) Mappings (, але їх синтаксис і структура кардинально відрізняються.
У більшості випадків відображення є більш ефективним та дешевшим, але масиви мають ітерабельність і підтримують упаковку типів даних. Тому рекомендується надавати перевагу відображенню при управлінні списками даних, якщо не потрібно ітерувати або якщо можна оптимізувати споживання газу за допомогою упаковки типів даних.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum])https://img-cdn.gateio.im/webp-social/moments-5f3d7e103e47c886f50599cffe35c707.webp(
) 6. Використання calldata замість memory
Змінні, оголошені в параметрах функції, можуть зберігатися в calldata або memory. Головна відмінність між ними полягає в тому, що memory може бути зміненою функцією, тоді як calldata є незмінною.
Запам'ятайте цей принцип: якщо параметри функції є лише для читання, слід надавати перевагу використанню calldata, а не memory. Це дозволяє уникнути непотрібних операцій копіювання з функціонального calldata до memory.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-9c566626ab499ef65d6f5089a2876ad3.webp(
) 7. Якомога більше використовуйте ключові слова Constant/Immutable
Константні/незмінні змінні не зберігаються у сховищі контракту. Ці змінні обчислюються під час компіляції та зберігаються в байт-коді контракту. Тому їх вартість доступу значно нижча в порівнянні зі сховищем, рекомендовано використовувати ключові слова Constant або Immutable якомога більше.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-c0701f9e09280a1667495d54e262dd2f.webp(
) 8. Використовуйте Unchecked, щоб забезпечити, що переповнення/недостатність не відбудеться.
Коли розробники можуть впевнитися, що арфметичні операції не призведуть до переповнення або недоповнення, вони можуть використовувати ключове слово unchecked, введене в Solidity v0.8.0, щоб уникнути зайвих перевірок на переповнення або недоповнення, таким чином заощаджуючи витрати на Gas.
Крім того, компілятор версії 0.8.0 та вище більше не потребує використання бібліотеки SafeMath, оскільки сам компілятор вже вбудував функції захисту від переповнень та недостач.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-a823fb7761aafa6529a6c45304e0314b.webp(
) 9. Оптимізація модифікаторів
Код модифікатора вбудований у змінену функцію, і щоразу, коли використовується модифікатор, його код копіюється. Це збільшує розмір байткоду та підвищує споживання Gas.
Перетворивши логіку в внутрішню функцію, що дозволяє повторно використовувати цю внутрішню функцію в модифікаторах, можна зменшити розмір байт-коду та знизити витрати на газ.
![Топ-10 найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-839b91e2f02389949aa698d460a497d8.webp(
) 10. Оптимізація короткого замикання
Для логічних операторів || та && відбувається коротке оцінювання, тобто, якщо перша умова вже може визначити результат логічного виразу, друга умова не оцінюється.
Щоб оптимізувати споживання Gas, слід розміщувати умови з низькою вартістю обчислень на початку, так можна пропустити обчислення з високою вартістю.
![Десять найкращих практик оптимізації Gas для смартконтрактів Ethereum]###https://img-cdn.gateio.im/webp-social/moments-a141884dcdcdc56faff12eee2601b7b7.webp(
Додаткові загальні рекомендації
) 1. Видалити непотрібний код
Якщо в контракті є невикористані функції або змінні, рекомендується їх видалити. Це найпростіший спосіб зменшити витрати на розгортання контракту та зберегти малий обсяг контракту.
Ось кілька корисних порад:
Використовуйте найефективніші алгоритми для обчислень. Якщо в смартконтракті безпосередньо використовуються результати певних обчислень, то варто усунути ці зайві обчислювальні процеси. По суті, будь-які непотрібні обчислення мають бути видалені.
У Ethereum розробники можуть отримувати газові винагороди, звільняючи простір для зберігання. Якщо змінна більше не потрібна, слід використовувати ключове слово delete для її видалення або встановити її на значення за замовчуванням.
Оптимізація циклів: уникати витратних циклічних операцій, по можливості об'єднувати цикли та виносити повторювані обчислення з тіла циклу.
2. Використання попередньо скомпільованих смартконтрактів
Попередньо скомпільовані контракти надають складні бібліотечні функції, такі як шифрування та хешування. Оскільки код не виконується на EVM, а виконується локально на клієнтському вузлі, потрібно менше газу. Використання попередньо скомпільованих контрактів може заощадити газ, зменшуючи обсяг обчислювальних робіт, необхідних для виконання смартконтрактів.
Приклади попередньо скомпільованих контрактів включають алгоритм цифрового підпису еліптичних кривих ###ECDSA( та алгоритм хешування SHA2-256. Використовуючи ці попередньо скомпільовані контракти в смартконтрактах, розробники можуть знизити витрати на Gas і підвищити ефективність роботи програм.
) 3. Використання внутрішньоінлінгового асемблерного коду
Вбудована асемблія ### in-line assembly ( дозволяє розробникам писати низькорівневий, але ефективний код, який може бути безпосередньо виконаний EVM, без необхідності використовувати дорогі операції Solidity. Вбудована асемблія також дозволяє точніше контролювати використання пам'яті та сховища, що ще більше зменшує витрати на газ. Крім того, вбудована асемблія може виконувати деякі складні операції, які важко реалізувати лише за допомогою Solidity, що забезпечує більшу гнучкість для оптимізації споживання газу.
Проте використання вбудованого асемблера також може бути ризикованим і легко призвести до помилок. Тому його слід використовувати обережно, лише досвідченим розробникам.
) 4. Використання рішень Layer 2
зробити