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 была предметной, а не приблизительной, нам нужен контекст по вашей сети и контрактам. Разбор задачи занимает один-два созвона с инженером, который будет вести внедрение, — после этого мы возвращаемся с планом работ по этапам и сроками. Ниже — исходные данные для старта; часть пунктов можно закрыть прямо в разговоре.
- Адреса контрактов, сети и события, реакцию на которые нужно автоматизировать, — по ним определим состав триггеров.
- Как вы узнаёте о событиях сейчас: ручной мониторинг, собственные скрипты, внешние сервисы — это покажет, что именно заменяем, а что оставляем.
- Какие действия должны выполняться в ответ: уведомление, запись в базу, вызов внутреннего сервиса, отправка транзакции.
- Требования к надёжности: сколько повторов при сбое, нужны ли идемпотентность, журнал выполнения и оповещение об ошибках.
- Доступы и ограничения: тестовые сети, приватные узлы, политика безопасности, кто владелец ключей подписи.
- Желаемые сроки внедрения и дата, к которой автоматизация должна работать на рабочей сети.
Возвращаемся с оценкой объёма работ, схемой триггеров и последовательностью этапов: что выкатываем первым, а что можно добавить после запуска. Опишите задачу автоматизации в свободной форме — остальное уточним на созвоне.
