Оптимізація газу: де транзакції втрачають ефективність
Вартість транзакції в мережі на базі Ethereum складається з трьох складників: обчислювальної роботи, обсягу записів у стан і поточного навантаження мережі. Одна й та сама функція у спокійний і в піковий момент коштує користувачеві по-різному. Тому оптимізація газу — це не разова правка, а робота з профілем виконання та гарячими шляхами.
Перше й найчастіше джерело перевитрат — сам контракт.
Цикл, який перебирає весь масив заради одного елемента, читання зі стану на кожній ітерації замість винесення значення в пам’ять, запис у сховище там, де вистачило б локальної змінної, — кожен такий рядок множиться на кількість викликів.
Додайте дублювальні перевірки та структури даних, обрані без заміру, і отримаєте контракт, який коштує в рази дорожче за необхідне.
Друге джерело — навантаження на мережу та поведінка клієнтського застосунку. Коли базова комісія зростає, транзакція або чекає в черзі, або виконується рівно до моменту, де газу перестає вистачати.
Невдалі операції газ при цьому вже витратили: користувач оплачує відкат і повторює виклик за новою ціною. Третє джерело — невдалі повтори з тим самим лімітом, які знову впираються в ту саму межу.
Розбираємо, як це закривається: де знімати вимірювання, які шляхи переписувати насамперед і як вибудувати логіку повторів, щоб вона не з’їдала газ марно.
Що дає оптимізація газу: вимірювані ефекти
Оптимізація газу — це не правка однієї функції, а набір рішень: як упаковані дані у викликах контракту, які гілки виконання дорожчі за інші, де операція впреться в ліміт блоку.
Працюємо з Ethereum-сумісними мережами та вимірюємо ефект до й після — за метриками, а не за відчуттями. Нижче п’ять результатів, які отримує замовник.
Зниження витрат на виконання
Вартість типової операції падає завдяки перепакуванню структур, повторному використанню вже прочитаних значень і винесенню важких розрахунків за межі ланцюжка. Витрати на сценарій скорочуються у 2–4 рази за того самого результату.
Частка успішних операцій
Оцінку вартості рахуємо під конкретний сценарій, з буфером на зміну стану, а не «на око». Частка операцій, які доходять до підтвердження з першої спроби, зростає з 80–85% до 97% і вище.
Час підтвердження
Точна оцінка та коректний пріоритет прибирають очікування в черзі й переплати за прискорення. Операція потрапляє в блок на першому-другому інтервалі замість повторних надсилань.
Відмови транзакцій
Окремо закриваємо класи відмов: гонки за стан, вичерпання ліміту газу, зриви зовнішніх викликів. Повторні надсилання та загублені операції зникають зі статистики.
Передбачуваність навантаження
Ліміти на операцію, черга та профіль піків роблять навантаження прогнозованим. Сплеск активності не здорожчує кожну наступну операцію та не зупиняє обробку.
Режими виконання транзакцій: порівняння підходів
Режим надсилання задає не лише вартість однієї операції, а й те, як систему супроводжувати.
Від нього залежить, де ставити повтори при відмові, як рахувати порядкові номери між гаманцями та що робити в момент пікового навантаження мережі — коли ціна включення в блок зростає в рази за хвилини.
| Варіант організації | Коли підходить | Обмеження схеми |
|---|---|---|
| Одиночне надсилання з ручним налаштуванням параметрів | Разові операції з високою цінністю, тестові контури | Не масштабується: оператор стає вузьким місцем, при затримці мережі операція «зависає» без автоматичного повтору |
| Безперервний потік з автоматичною оцінкою комісії | Рівномірне навантаження: передбачувана кількість операцій на годину | У спокійні періоди переплата за резерв; на піках оцінка відстає, частина операцій витісняється з черги |
| Пакетна обробка з об’єднанням викликів в одну операцію | Масові однотипні дії: виплати, реєстрації, випуск токенів | Відмова одного виклику відкочує весь пакет; частина газу йде на службові перевірки, розмір пакета обмежений обсягом блоку |
| Черга транзакцій з пріоритетами та контролем порядкових номерів | Високе навантаження, потік подій із зовнішніх систем | Потрібні окреме сховище стану черги та моніторинг: розсинхронізація номерів зупиняє весь потік |
Вибір між схемами — компроміс між вартістю та керованістю, і він не робиться один раз на старті. Ми починаємо із замірів на реальному профілі навантаження: розподіл операцій за годинами, частка витіснених транзакцій, поведінка черги на піках.
Після цього фіксуємо режим і залишаємо параметри налаштовуваними — при зростанні потоку пакетна обробка доповнюється чергою пріоритетів без переписування логіки.
Етапи впровадження: від замірів до передачі регламентів
Оптимізація газу починається не з правки коду, а із заміру того, як потік операцій реально витрачає газ. Поки немає розбивки за викликами, будь-яка зміна — це вгадування, а не інженерна робота. Ми ведемо проєкт шістьма етапами, і кожен закінчується артефактом, який можна перевірити.
- Аудит транзакцій. Вивантажуємо історію викликів за період, розкладаємо витрати за методами та окремо рахуємо три складові: запис у сховище, обчислення й передані дані. На виході — перелік операцій, які дають основну частку витрат.
- Схема обробки. Будуємо карту потоку операцій: де стан пишеться повторно, де дублюються перевірки, які виклики можна об’єднати в один або винести за межі мережі.
- Налаштування контрактів. Пакуємо поля в спільні слоти, переносимо обчислення зі сховища в пам’ять, кешуємо повторювані звернення, ставимо ліміти на масові операції.
- Тестовий контур. Розгортаємо копію стану мережі та прогоняємо сценарії з тим самим профілем навантаження. Порівнюємо витрати за кожним методом з вихідними — розбіжність у сценаріях видно до випуску.
- Заміри до та після. Фіксуємо вартість однієї операції в газі, а не «в середньому по системі»: звіт із розбивкою за методами та часткою, яку вдалося зняти з критичного шляху.
- Впровадження та передача регламентів. Розкочуємо зміни по контурах, віддаємо правила: які пороги вважати відхиленням, як відкотитися на попередню версію, що перевіряти перед кожним випуском.
Після передачі заміри залишаються у вашої команди — витрати за методами можна звіряти на кожному випуску, а не з’ясовувати постфактум, чому операції подорожчали.
Пакет передачі: конфігурації, схеми, регламенти
Пакет передачі — це не архів із файлами, а набір артефактів, за якими ваша команда зможе експлуатувати систему оптимізації газу самостійно: змінювати пороги, розгортати контур у новому середовищі, розбирати інциденти без нашої участі. Нижче — що саме передається на руки разом із працюючим контуром.
- Конфігурації розрахунку: параметри цільової вартості, ліміти на транзакцію, правила групування та пріоритезації — з коментарями, які значення безпечні, а які змінюють профіль витрат.
- Схеми потоків: шлях заявки від постановки в чергу до підтвердження в мережі, точки, де спрацьовують перерахунок ставки та повторне надсилання.
- Опис порогів і тригерів: за яких умов система підвищує ставку, коли знижує, що вважається аварійним відхиленням і як воно сигналізується.
- Правила доступу: ролі, хто має право змінювати пороги в продуктивному середовищі, хто тільки читає метрики, порядок узгодження змін.
- Панелі моніторингу: частка підтверджених транзакцій, середня вартість, час до підтвердження, кількість замін — з поясненням, як читати графіки та де шукати причину відхилення.
- Регламент супроводу: періодичність ревізії порогів, порядок оновлення конфігурацій, план відкату на попередній набір параметрів.
- Інструкції з інцидентів: типові збої, послідовність перевірок за кроками, умови ескалації до нас.
- Протоколи приймання: контрольні сценарії та заміри до й після включення оптимізації.
Кейс: зниження витрат на виконання операцій
Проєкт — сервіс регулярних взаєморозрахунків: кілька тисяч операцій на добу, кожна читає стан договору та записує результат у контракт на Ethereum.
Ціну виконання рахували за одним статичним множником «із запасом»: у години пік транзакції зависали, ціну піднімали вручну, переплата сягала 40% від розрахункової, а частка відмов трималася на 9–12%.
Що перебудували
Відмовилися від ручного керування. Прогноз базової комісії будується за динамікою останніх блоків, при затримці надсилається повтор із покроковим підвищенням ціни до підтвердження, ліміт рахується за фактичними витратами схожих операцій, а не за круглим числом із запасом.
Схему звернення до стану переписали повністю: значення, які всередині одного виклику читаються багаторазово, кешуються в пам’яті, чотири записи у сховищі згорнуті в одну, однотипні операції збираються в пакетний виклик замість десятків окремих транзакцій.
Результат
Переплата щодо розрахункової ціни впала з 38–40% до 5–7%, частка відмов — з 9–12% до менш ніж 1%, кількість звернень до стану на операцію скоротилася втричі, вартість типової операції — у 2,4 раза.
Впровадження зайняло шість тижнів: спочатку прогноз ціни та повторне надсилання, потім пакетна обробка, наприкінці — перебудова зберігання. Старий і новий шляхи працювали паралельно, перемикання — однією настройкою, тому відкат на попередню схему займав хвилини.
Чим пакетне надсилання відрізняється від одиночних викликів?
Одиночний виклик — це одна операція в одній транзакції: свій підпис, свій ліміт газу, свій результат. Пакетне надсилання збирає кілька однотипних операцій в один виклик контракту: базова частина газу платиться один раз, змінна зростає тільки на виконання. Виграш помітний там, де операції масові та однакові за структурою.
Стійкість до піків у підходів різна. Одиночні виклики чутливі до стрибка комісій: черга підписів розсипається, частина транзакцій зависає та потребує ручного розбору. Пакет збирається один раз, але потребує запасу за лімітом газу — інакше він падає повністю, а не частково.
Логіка відкатів теж відрізняється. Одиночний режим дає точковий відкат: повторюємо лише невдалу операцію. Пакет атомарний, тому в контракт закладають перевірки на дублікати, межу розміру пачки та зрозумілу причину відмови, а сервіс — повторне складання з невдалих елементів.
| Критерій | Пакетне надсилання | Одиночні виклики |
|---|---|---|
| Стійкість до піків | одне складання, потрібен запас газу | рветься черга підписів |
| Логіка відкатів | атомарно, весь пакет | точково, за операцією |
| Вимоги до контракту | цикл, ліміти, захист від дублів | одна функція на операцію |
| Супровід | складніше розбір відкатів | більше транзакцій у моніторингу |
На практиці частіше беруть гібрид: масові однотипні операції йдуть пачками, різнорідні — одиночними викликами. Вибір визначається профілем навантаження, а не розміром виграшу на окремому виклику.
Технічні обмеження та часті питання замовників
Оптимізація газу майже ніколи не означає «переписати все заново». Чинні контракти незмінні, тому змінюємо не код, а схему викликів: пакетне надсилання операцій, порядок запису в стан, відмову від проміжних збережень, винесення обчислень за межі перевіреної частини.
Іноді дешевше додати новий шар поруч, ніж чіпати перевірений контракт, — це і є головне обмеження схеми, з яким ми починаємо розбір.
Ефект фіксуємо замірами до та після на копії мережі: скільки операцій виконання припадає на одну бізнес-операцію, яка частка транзакцій падає через нестачу ліміту, як змінюється час підтвердження під навантаженням.
Без замірів оптимізація перетворюється на здогадки, а ризик інтеграцій — у непередбачуваність для гаманців і внутрішніх сервісів.
У нас уже працюють контракти — їх доведеться переписувати?
Ні, і найчастіше не можна: розгорнутий контракт не змінюється. Працюємо з тим, що навколо нього, — перерозподіляємо логіку між викликами, об’єднуємо операції в одну транзакцію, прибираємо зайві записи в стан. Новий код підключаємо окремим шаром і переводимо на нього потік поступово.
Що буде з інтеграціями — гаманці, біржі, внутрішні сервіси?
Зовнішні інтерфейси мають залишитися незмінними: ті самі методи, ті самі події, той самий формат відповідей. Якщо сигнатура виклику змінюється, оновлювати її доведеться всім контрагентам одночасно — це окремий ризик, який оцінюємо до початку робіт і за можливості обходимо.
Як ви доводите, що стало краще?
Замірами на копії мережі з реальним профілем навантаження: частка операцій виконання на одну бізнес-операцію, кількість відмов через нестачу ліміту, час підтвердження.
Порівняння до та після йде на одному й тому самому наборі сценаріїв, а зміни викочуємо так, щоб можна було повернутися до попередньої схеми.
Обговоримо задачу: з чого починається робота
Починаємо з розбору вихідних даних, а не із загальних обіцянок: без реальних цифр щодо витрат газу будь-яка оцінка проєкту залишається здогадкою. Чим конкретніші ввідні, тим точніше ми назвемо строки та обсяг робіт.
Що надіслати для первинного розбору:
- адреси контрактів та їх призначення: перекази, обмін, випуск токенів, розрахункові виклики;
- 5–10 хешів реальних транзакцій з різних сценаріїв — за ними видно, куди саме йде газ;
- приблизні обсяги: скільки операцій проходить на добу та скільки в пікові години;
- поточні метрики витрат: середнє та максимальне значення газу на одну операцію;
- схеми взаємодії контрактів, якщо логіка розподілена між кількома;
- вимоги до затримки підтвердження та до порядку обробки операцій;
- обмеження: мережа, доступний інструментарій, що не можна змінювати в логіці контрактів.
Далі ми розкладемо виклики за вартістю виконання та зазначимо, які зміни дають ефект одразу, а які потребують переробки логіки.
За підсумком повернемося з оцінкою проєкту та планом робіт: етапи, що потрібно з вашого боку на кожному, і цільові показники зниження газу — їх перевіряємо на тестовій мережі до викочування в основну.
Обговоримо задачу: опишіть її в повідомленні, відсутні дані зберемо разом із вашими інженерами.
