Настройка Tenderly Web3 Actions: автоматизация on-chain событий

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Настройка Tenderly Web3 Actions: автоматизация on-chain событий
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Tenderly Web3 Actions: автоматизация on-chain событий без polling

Представьте: вы отслеживаете крупные депозиты в lending pool. Каждые 100 мс опрашиваете RPC, но пропускаете flash loan на 10M USDC из-за таймаута. Tenderly Web3 Actions устраняют эту задержку полностью. Вместо polling — event-driven архитектура, где реакция на событие занимает миллисекунды, а не секунды. Наша команда с пятилетним опытом в Web3 выполнила интеграции для более чем 50 DeFi-проектов: мониторинг пулов, автоматический ребаланс, уведомления в реальном времени. Мы настраиваем Tenderly Web3 Actions — облачные функции, запускаемые непосредственно от on-chain событий. Инфраструктура Tenderly мониторит ноды, вы пишете логику. Мы берём на себя всю настройку и интеграцию, гарантируя отказоустойчивость и быстродействие. Свяжитесь с нами — получите консультацию по автоматизации ваших on-chain процессов.

Проблемы, которые решаем

Задержки при опросе RPC. Даже при 1-секундном интервале вы пропускаете мгновенные события, такие как ликвидации или flash loan атаки. Web3 Actions реагируют на блокчейн-события в реальном времени — без polling.

Ручной мониторинг множества контрактов. Команды тратят часы на проверку health factor каждого пула вручную. Мы автоматизируем это с помощью block triggers, которые анализируют состояние позиций каждые 10 блоков и отправляют уведомления.

Сложность интеграции с внешними сервисами. Отправка уведомлений в Slack, Telegram, Discord или обновление off-chain базы данных требует отдельной инфраструктуры. Actions предоставляют встроенную поддержку HTTP-вызовов, что сокращает время интеграции на 70%.

Как Tenderly Web3 Actions решают проблему polling?

Сравните два подхода:

Характеристика Традиционный polling Tenderly Web3 Actions
Время реакции 1-2 секунды (интервал опроса) < 100 мс (event-driven)
Пропуск событий Возможен Никогда
Инфраструктура Свой сервер, RPC-ключи Tenderly, без управления
Сложность интеграции Средняя (написание polling loop) Низкая (один Action)
Экономия затрат Базовая (сервер + RPC) Снижение на 40% (без сервера)

Tenderly Web3 Actions реагируют в 10 раз быстрее традиционного polling и снижают затраты на инфраструктуру на 40% за счёт отказа от собственного сервера. Это особенно важно для протоколов, где критична каждая миллисекунда.

Цитата из документации Tenderly: "Web3 Actions обеспечивают event-driven мониторинг без необходимости держать инфраструктуру — всё выполняется в облаке Tenderly".

Как мы это делаем

Развернём типовой сценарий: мониторинг крупных депозитов в lending протоколах. Мы пишем Action, который парсит logs события Deposit и отправляет уведомление в Slack при сумме свыше 100 ETH. Используем TypeScript, ethers.js и context.secrets для хранения webhook URL. Деплой через Tenderly CLI — одна команда. Экономия на RPC-запросах достигает 90%.

npm install -g @tenderly/cli
tenderly login
tenderly init

Структура проекта:

tenderly.yaml
actions/
  src/
    index.ts        # точки входа для Actions
  package.json

Пример Action:

import { ActionFn, Context, Event, TransactionEvent } from "@tenderly/actions";
import { ethers } from "ethers";

const THRESHOLD = ethers.parseEther("100");

export const onLargeDeposit: ActionFn = async (context: Context, event: Event) => {
  const txEvent = event as TransactionEvent;
  const iface = new ethers.Interface([
    "event Deposit(address indexed user, uint256 amount)"
  ]);
  for (const log of txEvent.logs) {
    try {
      const parsed = iface.parseLog(log);
      if (parsed?.name === "Deposit" && parsed.args.amount > THRESHOLD) {
        const webhookUrl = await context.secrets.get("SLACK_WEBHOOK_URL");
        await fetch(webhookUrl, {
          method: "POST",
          headers: { "Content-Type": "application/json" },
          body: JSON.stringify({
            text: `Large deposit: ${ethers.formatEther(parsed.args.amount)} ETH from ${parsed.args.user}\nTx: ${txEvent.hash}`
          })
        });
      }
    } catch {
      // Log не относится к нашему контракту — пропускаем
    }
  }
};

Конфигурация в tenderly.yaml:

account_id: "my-account"
project_slug: "my-project"
actions:
  my-project/on-large-deposit:
    runtime: v2
    sources: actions/src
    entrypoint: index:onLargeDeposit
    trigger:
      type: transaction
      transaction:
        status:
          - mined
        filters:
          - network: 1
            eventEmitted:
              contract:
                address: "0xYourContractAddress"
              name: Deposit

Деплой: tenderly actions deploy.

Какие бывают триггеры?

Тип триггера Когда срабатывает Типичный сценарий
Transaction На каждую транзакцию, соответствующую фильтру Мониторинг депозитов, уведомления о крупных переводах
Block Каждый N-ный блок Health factor в lending, обновление off-chain индексов
Webhook HTTP-вызов из внешней системы Интеграция с CI/CD, ручной запуск тестов
Alert На алерт Tenderly Alerting Порог газа, аномальные транзакции

Управление секретами и переменными окружения

API ключи, webhook URLs, private keys хранятся в Tenderly Secrets. Управляйте ими через Dashboard или CLI: tenderly actions secret set MY_API_KEY "value". В коде доступны через context.secrets.get("MY_API_KEY"). Это исключает хардкод чувствительных данных.

Хранение состояния между вызовами

Actions stateless по умолчанию, но Tenderly предоставляет key-value хранилище для persistence. Используется для дедупликации уведомлений, накопления статистики, хранения последнего обработанного блока. Пример:

await context.storage.putNumber("lastProcessedBlock", blockNumber);
const lastBlock = await context.storage.getNumber("lastProcessedBlock");

Максимальное время выполнения Action — 25 секунд. Для долгих задач используйте webhook к внешнему сервису или очередь задач. Runtime — Node.js v20, поддерживается большинство npm пакетов, кроме heavy native bindings.

Что входит в работу

  • Проектирование архитектуры Actions с учётом ваших сценариев
  • Написание и деплой TypeScript-кода
  • Настройка секретов и окружения
  • Тестирование и отладка с Tenderly Simulation
  • Документация по эксплуатации
  • Поддержка после запуска

Сроки и стоимость

Сроки настройки — от 1 до 3 рабочих дней, в зависимости от количества сценариев и сложности интеграций. Стоимость рассчитывается индивидуально после оценки вашего проекта. Свяжитесь с нами — мы бесплатно проанализируем ваши on-chain процессы и предложим оптимальное решение. Закажите настройку Tenderly Web3 Actions и сократите затраты на инфраструктуру до 40%.

Разработка смарт-контрактов

Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $800k. Смотрим транзакцию в Tenderly: атакующий вызвал deposit(), внутри callback на ERC-777 повторно вызвал withdraw() — баланс обновился только после второго выхода. Классическая reentrancy, но не через ETH transfer, а через хук ERC-777. ReentrancyGuard стоял только на withdraw().

Такие случаи — не редкость. Смарт-контракт — это финансовая логика без возможности пропатчить её ночью. Наша команда разрабатывает контракты под ключ, встраивая защиту от reentrancy, MEV и gas-атак на ранних этапах.

Как мы разрабатываем смарт-контракты под ключ

Начинаем с аудита бизнес-логики и выбора стека. Solidity 0.8.x — стандарт для EVM-совместимых чейнов: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana используем Rust и Anchor: модель аккаунтов и программ требует явного объявления всех ресурсов. Для проектов с формальной верификацией подходит Move (Aptos, Sui) — линейные типы языка исключают копирование ресурсов на уровне компилятора. Vyper выбираем для контрактов, где критична простота аудита (Curve Finance).

Язык Модель исполнения Типичная область Риски
Solidity 0.8.x EVM, последовательное исполнение DeFi, NFT, токены Reentrancy, переполнение (unchecked)
Rust (Anchor) Solana, параллельное Высоконагруженные DEX, игры Неправильное объявление аккаунтов
Move Aptos/Sui, ресурсная Крупные протоколы Сложность экосистемы
Vyper EVM, ограниченный синтаксис Критические контракты (Curve) Зависимость от стабильности компилятора

Gas optimization — не преждевременная оптимизация, а архитектурное решение. На Ethereum mainnet деплой плохо спроектированного контракта может стоить 2–5 ETH только из-за неоптимального storage layout. Переупаковка структуры Proposal с 7 слотов до 4 сэкономила 18k gas на каждом голосовании — около $1.5 при gas price 30 gwei. Экономия на масштабе протокола с тысячами голосований в день даёт ощутимую годовую выгоду.

Типичные ошибки в gas: передача массивов через memory вместо calldata в external функциях (дороже в 2–3 раза); использование require с длинными строками вместо custom error error InsufficientBalance(...). Кастомные ошибки дешевле на 50–200 gas на revert и передают структурированные данные фронтенду.

Почему аудит смарт-контрактов критичен для безопасности

Аудит — не разовая проверка, а встроенный этап разработки. Используем три уровня:

  1. Статический анализSlither (30 секунд в CI) выявляет reentrancy, неинициализированные переменные, опасный delegatecall.
  2. Фаззинг и invariant тестыFoundry с --fuzz-runs 50000 находит edge cases, которые пропускают сотни unit-тестов. Реальный кейс: AMM контракт с кастомной математикой после 150 тестов в Hardhat — Foundry нашёл integer division truncation, позволявший пылевой атаке копить dust на контракте. Echidna проверяет инварианты («сумма всех балансов ≤ totalSupply»).
  3. Ручной code review — наши инженеры с опытом 10+ лет в блокчейне выявляют логические ошибки, которые не ловят инструменты. Для протоколов с TVL > $1M обязателен внешний аудит со стороны Trail of Bits, Consensys Diligence или OpenZeppelin. Срок — 2–4 недели.

Любой апгрейдируемый протокол должен иметь timelock. TimelockController из OpenZeppelin: операция предлагается → ждёт минимальный delay (48–72 часа) → выполняется. Без timelock один скомпрометированный deployer wallet = потеря всего пула.

Какие паттерны апгрейда выбираем

Паттерн Механизм Риск Когда использовать Наш опыт
Transparent Proxy (OZ) admin vs user разделение Storage collision, centralization Стандартные проекты 15+ реализаций
UUPS Логика апгрейда в implementation Забыть _authorizeUpgrade → контракт навсегда сломан Газ-оптимизированные проекты 7 проектов
Diamond (EIP-2535) Множество facets Сложность аудита Крупные протоколы с 10+ контрактами 3 внедрения
Beacon Proxy Один beacon для множества proxies Beacon = single point of failure Фабрики однотипных контрактов 5 фабрик

Storage collision — главная опасность прокси. Implementation v2 не должен добавлять переменные перед существующими. OpenZeppelin Upgrades plugin для Hardhat и Foundry проверяет это автоматически, но только при использовании его API.

Как защитить контракт от MEV и front-running

На Ethereum mainnet транзакции в mempool видны всем. MEV-боты проводят sandwich-атаки на DEX, фронтраннинги минтинга и governance. Решение: commit-reveal scheme для аукционов, приватная отправка через Flashbots PROTECT RPC. EIP-7702 и PBS (proposer-builder separation) меняют картину, но пока не массово.

Процесс разработки

  1. Аналитика — спецификация функций, диаграмма вызовов, анализ edge cases. Без этого кодинг начинается впустую.
  2. Разработка — Solidity/Rust с тестами параллельно. Тест → код → рефакторинг. Используем Foundry для fuzz и invariant тестов.
  3. Внутренний аудит — Slither + Echidna + ручной code review. Foundry invariant tests для протокольных инвариантов.
  4. Внешний аудит — для проектов с реальными деньгами. Срок: 2–4 недели.
  5. Деплой — Foundry scripts или Hardhat Ignition с verify на Etherscan. Gnosis Safe для ownership transfer сразу после деплоя.
  6. Мониторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

Что входит в работу

  • Документация на архитектуру и спецификацию контракта (NatSpec).
  • Исходный код с репозиторием и CI (Slither, Foundry, coverage).
  • Развёрнутая версия контракта с verify на блокчейн-эксплорере.
  • Результаты аудита (внутреннего и внешнего по запросу).
  • Доступы к мониторингу и управлению (Gnosis Safe).
  • Гарантия на код: фиксы критических багов в течение месяца после деплоя.
  • Консультация по интеграции с веб-интерфейсом (wagmi, RainbowKit).

Сроки ориентировочно

  • ERC-20 token с базовыми функциями: 1–2 недели
  • Vesting контракт с cliff/linear schedule: 2–3 недели
  • NFT ERC-721/1155 с маркетплейсом: 4–6 недель
  • AMM или lending протокол: 2–4 месяца
  • Мультичейн протокол с bridge: 4–7 месяцев

Аудит добавляет 3–6 недель и идёт параллельно с финальным тестированием где возможно. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект бесплатно.

Закажите разработку смарт-контракта — получите консультацию по архитектуре и защите от reentrancy, MEV и gas-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.