Tenderly Web3 Actions: де ламається ручна обробка подій
Поки подій у мережі небагато, обробка подій у мережі тримається на ручних скриптах для контрактів: задача за розкладом обходить журнал, звіряє висоту останнього блоку зі збереженою позначкою і розсилає повідомлення.
Схема робоча рівно доти, доки процес живий, а черговий інженер пам’ятає, на якому місці він зупинився.
Ламається це передбачувано. Перезапуск після падіння обнуляє позначку — частину викликів обробляють повторно, частина губиться в проміжку між проходами, і з’являються пропущені події контракту.
Відновлювати доводиться вручну: піднімати історію, зіставляти записи, дописувати компенсувальні дії.
На піковому навантаженні цикл не встигає за потоком, і затримка реакції на транзакції зростає від інтервалу обходу до моменту, коли розходження хтось помітить.
Зовні це виглядає як «система іноді не спрацьовує» — без відтворюваного сценарію і без межі, за якою відмова стає критичною.
Окрема стаття — перебудова ланцюжка: уже оброблений виклик може перестати бути частиною основної гілки, а скрипт про це не дізнається і продовжує вважати стан узгодженим.
Такий клас розходжень ручною звіркою закривається найповільніше, бо шукати потрібно не збій, а хибне припущення.
Автоматизація подій блокчейну через Tenderly Web3 Actions переносить точку запуску на саму подію: реакція стартує в момент підтвердження, а не за розкладом, і стан обробки зберігається в сервісі. Далі розбираємо, як це закривається і що саме перестає залежати від чергового інженера.
Що дає автоматизація реакцій на події мережі
Ручний моніторинг — це опитування: скрипт раз на кілька хвилин забирає події та реагує постфактум, тому між подією і реакцією минає від хвилини до кількох годин.
Увесь цей час завислі транзакції та необроблені заявки накопичуються мовчки, а розходження між станом мережі та станом сервісу зростає.
Подієва модель прибирає і опитування, і затримку.
Підписка на адресу контракту та сигнатуру події запускає обробник у момент включення блоку — час реакції падає до секунд, а частка ручних операцій скорочується до кола винятків: типові реакції живуть у коді, інженер розбирає лише те, що обробник позначив як нетипове.
Заодно зникає цілий клас відмов — пропущене вікно, повторна обробка тієї самої події після збою, дія за застарілим станом.
Повторні спроби та ідемпотентність закладені в модель виконання, а журнал запусків зберігає вхід, вихід і причину помилки, тому інцидент розбирається за фактами, а не за розрізненими логами.
Tenderly Web3 Actions закриває це без власного парку обробників: код розгортається поруч із вузлом, бачить стан мережі та перевіряється локально, а ключі й секрети зберігаються поза репозиторієм.
Сервіс працює цілодобово — нічна заявка обробляється так само, як денна, і стабільність перестає залежати від того, чи чергує хтось у момент події.
Режими запуску Web3-обробників: порівняння підходів
Перед увімкненням автоматизації обирають не інструмент, а режим запуску обробників: він задає затримку реакції, доступні бібліотеки та те, хто відповідає за доступність.
Один сценарій — наприклад, переведення коштів у резерв під час виведення ліквідності — реалізується всіма чотирма способами, але клас відмов і обсяг супроводу в них різні.
Вбудовані тригери Tenderly Web3 Actions закривають випадок, коли логіка вкладається в готові умови за адресою контракту, темою події та обсягом.
Щойно потрібен доступ до внутрішньої бази або власна черга повторів, однієї платформи не вистачає — її доповнюють гібридною схемою або замінюють власним обробником подій.
| Режим запуску | Коли підходить | Обмеження |
|---|---|---|
| Вбудовані тригери платформи | Реакція на подію контракту за фільтром: повідомлення, запис у чергу, виклик зовнішньої адреси | Немає власних бібліотек, тривалих задач і локального стану |
| Власний обробник подій | Потрібні власні залежності, черга повторів і доступ до внутрішніх систем | Доступність, моніторинг і синхронізацію з ланцюжком тримаємо самі |
| Гібридна схема автоматизації | Швидка реакція на подію плюс важка логіка у власному контурі | Два контури: обов’язкові ідемпотентність і контроль розходжень |
| Запуск за розкладом | Пакетна звірка, звіти, добір пропущених подій, разові міграції | Реакція із затримкою, не годиться там, де важлива швидкість |
Режими сумісні між собою, і на практиці їх комбінують: вбудований тригер ловить подію та передає задачу у свій сервіс, а розклад добирає пропущене. Контракти змінювати не потрібно — автоматизація будується поверх уже розгорнутих.
Порядок впровадження: від аудиту подій до передачі
Автоматизація на Tenderly Web3 Actions ламається не на коді обробника, а на неповній карті подій контракту. Пропущений переказ, який емітить не логіка контракту, а токен, залишає сценарій невідпрацьованим — і спливає це через розходження в обліку. Тому починаємо з інвентаризації.
- Аудит подій контракту. Розбираємо ABI та логи: повний список сигнатур, індексовані поля для фільтрів, окремо — події з проксі, бібліотек і пов’язаних токенів.
- Схема обробки подій. Позначаємо, що запускає дію, а що лише пишеться в журнал, і задаємо ключ ідемпотентності «хеш транзакції + індекс логу» — повторна доставка не подвоїть операцію.
- Побічні ефекти. Визначаємо, куди йде результат: зовнішній HTTP-виклик, запис у базу, повідомлення. Секрети — лише у змінних середовища, запити — у межах ліміту часу виконання дії.
- Перевірка обробника в тестовій мережі. Обкатуємо на форку: потрібні події, повторна емісія, відкат блоку, недоступний зовнішній сервіс. Кожен сценарій — запуск з очікуваним результатом.
- Впровадження автоматизації в робочу мережу. Увімкнюємо поступово: одна адреса або тип події, далі розширюємо. Журнал запусків і алерт на невдалі спрацювання показують помилку фільтра в перші хвилини.
- Передача рішення команді. Віддаємо репозиторій, схему подій і фільтрів, змінні середовища, права доступу й регламент: як додати подію, вимкнути дію, повернутися до попередньої версії.
Після передачі команда сама додає події та змінює фільтри, а ми підключаємося на змінах контрактів.
Що залишається в репозиторії після впровадження
Після впровадження автоматизації на Tenderly Web3 Actions у репозиторії залишається не лише код обробників, а й увесь контур їх супроводу. Сенс у тому, щоб черговий інженер або новий розробник розібрався в потоках подій без автора. Нижче — перелік артефактів, які ми передаємо та перевіряємо на прийманні.
- Конфігурації обробників. Для кожного тригера зафіксовано мережу, адресу контракту, сигнатуру події, умови фільтрації та набір дій. Зміни проходять рев’ю, а не редагуються руками у веб-інтерфейсі.
- Схема потоків подій. Діаграма «контракт → обробник → побічний ефект»: запис у базу, повідомлення, виклик іншого контракту. На ній позначено точки відмови та поведінку при повторному запуску.
- Політики доступу до секретів. Перелік ключів і токенів: що лежить у захищених змінних, у кого є доступ, як проходить ротація і що робити при компрометації.
- Журналювання. Єдиний формат записів: ідентифікатор події, адреса контракту, хеш транзакції. Розбір інциденту починається з пошуку за журналом, а не із здогадів.
- Регламент обробки збоїв. Розділено помилки, які повторюємо з наростаючою паузою, і ті, що глушимо одразу; задано ліміти спроб і адресати повідомлень.
- Тестовий контур. Сценарії на локальному стенді та прогін на форку мережі: повторний запуск, порожня відповідь, недоступність зовнішнього сервісу.
- Документація з автоматизації. Карта обробників, список змінних середовища, порядок розгортання та інструкція для чергової зміни: що дивитися в перші хвилини і які дії безпечні.
Кейс: автоматизація виплат за подіями стейкінгу
Проєкт — стейкінг-пул, де нагороди нараховувалися вручну: оператор раз на добу вивантажував список подій, звіряв адреси та запускав перекази пакетом.
На піках черга зростала, затримка між подією та виплатою розтягувалася до кількох годин, а кожна виплата потребувала окремого підтвердження — десятки ручних операцій на день.
Вузьке місце знайшли не в переказах, а у відсутності ідемпотентності: при повторній доставці події обробник міг відправити нагороду двічі, тому оператор звіряв кожен хеш руками.
Першим кроком зробили журнал оброблених подій з унікальним ключем і статусом — повторний запуск перестав бути ризиком.
Автоматизацію зібрали на Tenderly Web3 Actions: тригер на подію контракту викликає обробник, той перевіряє подію за ключем, ставить блокування та ініціює виплату.
Якщо транзакція не проходить, обробник повторює спробу за розкладом з обмеженням кількості спроб і пише в лог причину відмови — оператор підключається лише до позначених випадків.
Метрики до і після
Час від події до виплати скоротився з годин до секунд, частка ручних підтверджень упала до кількох відсотків — залишилися лише збої, що потребують рішення.
Повторних запусків стало більше, але це безпечні повтори: ключ ідемпотентності не пропустив у мережу жодного дубля, розходжень на звірці балансів не залишилося.
Чим підписка на події відрізняється від періодичного опитування
Періодичне опитування мережі — це цикл за розкладом: сервіс сам раз на N секунд запитує вузол, чи з’явилися нові блоки та логи за потрібними адресами. Підписка на події перевертає схему — вузол сам віддає дані, щойно транзакція потрапила в блок, а обробник запускається за фактом.
Різниця не в зручності, а в тому, як кожна модель розподіляє затримку, навантаження та ризик втратити подію.
Затримка виявлення події при опитуванні не може бути меншою за інтервал циклу. Стиснути інтервал — означає помножити кількість запитів: на активних адресах і в піки вузол починає віддавати помилки обмеження частоти, і частина запитів просто не доходить.
При підписці подія йде в обробник одразу після включення транзакції в блок, тому затримка вимірюється секундами блоку, а не довжиною циклу.
Навантаження на вузол влаштовано інакше. Опитування витрачає запити марно: більшу частину часу нових подій немає, але трафік іде постійно та зростає лінійно з кількістю відстежуваних адрес.
Підписка тримає одне з’єднання та передає лише корисні дані — за того самого обсягу логіки вузол навантажений у рази менше.
Повнота обробки даних — головний аргумент. Опитування з курсором останнього обробленого блоку пропускає подію, якщо процес упав між записом курсора та обробкою або якщо ланцюжок перебудувався.
Підписка сама по собі теж не гарантія: обробник має бути ідемпотентним, а події — дедуплікуватися за хешем транзакції та індексом логу.
На практиці ми тримаємо підписку основним каналом, а періодичну звірку за діапазоном блоків — страховкою, що закриває пропуски та реорганізації.
Tenderly Web3 Actions дає обидві сторони: тригери за подіями та викликами контрактів, повторний запуск при збої та журнал виконання, за яким видно, на якому блоці обробка зупинилася.
Часті технічні сумніви перед стартом
Автоматизація реакцій на події в Tenderly Web3 Actions здається простою, поки не починаєш рахувати відмови: обробник упав на середині, подія прийшла двічі, вузол віддав таймаут. Нижче — сумніви, які інженери порушують до старту, і те, як ми закриваємо їх на рівні конфігурації.
Що якщо обробник подій упаде на середині?
Невдалий запуск не губиться: зберігаються вхідна подія та стек помилки. Повтори йдуть із наростаючою затримкою та лімітом спроб, після чого подія йде в окрему чергу на розбір — потік не блокується.
Чи може обробник запуститися повторно на тій самій події?
Так — при повторі після таймауту або при переіндексації блоку. Тому дії проєктуємо ідемпотентними: ключем слугують хеш транзакції та номер події, повтор оновлює той самий стан, а не створює дубль.
Чи отримуєте ви доступ до приватних ключів?
Ні. Секрети зберігаються в захищеному сховищі та підставляються в середовище обробника, а не в код. Підпис виносимо в окремий гаманець-релеєр з обмеженими правами: дія формує намір, ключ залишається поза зоною виконання.
Чи працюватиме автоматизація з уже розгорнутими контрактами?
Код змінювати не потрібно: дія підписується на події за адресою та описом інтерфейсу. Минулі події розбираємо проходом за діапазоном блоків, потім вмикається жива підписка.
Що буде при перевантаженні мережі або піку подій?
Задаємо ліміт одночасних запусків і об’єднуємо читання в пакети, щоб не впиратися в обмеження вузла. При таймауті запуск повторюється із затримкою, черга розбирається за пріоритетом.
Обговоримо вашу задачу та повернемося з планом
Щоб оцінка обсягу робіт із налаштування Tenderly Web3 Actions була предметною, а не приблизною, нам потрібен контекст щодо вашої мережі та контрактів.
Розбір задачі займає один-два дзвінки з інженером, який вестиме впровадження, — після цього ми повертаємося з планом робіт за етапами та строками. Нижче — вихідні дані для старту; частину пунктів можна закрити прямо в розмові.
- Адреси контрактів, мережі та події, реакцію на які потрібно автоматизувати, — за ними визначимо склад тригерів.
- Як ви дізнаєтеся про події зараз: ручний моніторинг, власні скрипти, зовнішні сервіси — це покаже, що саме замінюємо, а що залишаємо.
- Які дії мають виконуватися у відповідь: повідомлення, запис у базу, виклик внутрішнього сервісу, відправлення транзакції.
- Вимоги до надійності: скільки повторів при збої, чи потрібні ідемпотентність, журнал виконання та оповіщення про помилки.
- Доступи та обмеження: тестові мережі, приватні вузли, політика безпеки, хто власник ключів підпису.
- Бажані строки впровадження та дата, до якої автоматизація має працювати в робочій мережі.
Повертаємося з оцінкою обсягу робіт, схемою тригерів і послідовністю етапів: що викочуємо першим, а що можна додати після запуску. Опишіть задачу автоматизації у вільній формі — решту уточнимо на дзвінку.
