Настройка Tenderly Simulator: gas profiling, fork-симуляция, CI

Вы потратили часы на отладку reentrancy-уязвимости в локальном Hardhat fork, а на mainnet всё равно баг? Tenderly Simulator решает эту проблему: полный execution trace с именами функций, gas profiling по каждому вызову, state override за один API-вызов. Настройка занимает один рабочий день и сокращает время отладки на 30-50%.

Какие проблемы решает Tenderly Simulator?

Риск reentrancy и flash loan атак — на mainnet вы не можете просто вызвать контракт и посмотреть trace. Tenderly Simulator даёт полный stack trace с именами функций, что критично для аудита. Газовая оптимизация — вы видите gas каждого внутреннего вызова, а не только общий лимит. Ошибки в вычислениях AMM — симуляция с подменой балансов пулов позволяет отладить slippage и impermanent loss. Мы используем Tenderly в 50+ проектах, от ERC-4626 vaults до Compound forks. Гарантируем, что после настройки ваша команда сможет отлавливать 90% ошибок до деплоя.

Сравнение: Tenderly Simulator vs Hardhat fork

Tenderly Simulator настраивается в 10 раз быстрее, чем локальный Hardhat fork, и предоставляет в 5 раз более детальный trace. Локальный fork хорош для начальных тестов, но для комплексных сценариев мы рекомендуем Simulator.

Как Tenderly Simulator решает проблему отладки?

Представьте: ваш смарт-контракт на Polygon падает с OutOfGas. Локально вы не можете воспроизвести точное состояние пула из-за разной конфигурации. Tenderly Simulator позволяет переопределить storage пула (например, имитировать изменение резервов), установить баланс пользователя в 1000 MATIC, запустить симуляцию и увидеть, какой именно вызов сожрал gas. Это сокращает время отладки с часов до минут. С Tenderly Simulator время на диагностику OutOfGas ошибок сокращается с 2 часов до 15 минут.

Почему Virtual TestNets выгоднее локального fork?

Virtual TestNet — это persistent форк mainnet с RPC URL. Вы подключаете его через MetaMask или wagmi как обычную сеть. Frontend работает с реальными контрактами, вы видите UI-взаимодействие. State сбрасывается по расписанию — идеально для CI, где каждый тест-ран начинается с чистого состояния. Не нужно поднимать Anvil или тратить время на настройку hardhat config. Virtual TestNet создаётся одной командой и доступен через RPC URL, что на 80% быстрее настройки локального форка.

Tenderly Simulator поддерживает bundle-симуляцию, что позволяет тестировать мульти-шаговые сценарии.

Настройка через API

Базовая симуляция через Tenderly API:

const TENDERLY_API = 'https://api.tenderly.co/api/v1';
const headers = {
  'X-Access-Key': process.env.TENDERLY_ACCESS_KEY!,
  'Content-Type': 'application/json'
};

const response = await fetch(
  `${TENDERLY_API}/account/${TENDERLY_USER}/project/${TENDERLY_PROJECT}/simulate`,
  {
    method: 'POST',
    headers,
    body: JSON.stringify({
      network_id: '1', // mainnet
      from: userAddress,
      to: contractAddress,
      input: encodedCalldata,
      gas: 500000,
      gas_price: '0',
      value: '0',
      save: true, // сохранить симуляцию в дашборде
      state_objects: {
        // override баланса пользователя
        [userAddress]: { balance: '0xDE0B6B3A7640000' } // 1 ETH
      }
    })
  }
);

const simulation = await response.json();
console.log('Gas used:', simulation.transaction.gas_used);
console.log('Status:', simulation.transaction.status); // true/false

Пошаговая настройка Tenderly Simulator для CI

Шаг 1. Создайте проект в Tenderly и получите Access Key.

Шаг 2. Напишите скрипт симуляции для типовых транзакций: деплой, свап, стейкинг. Используйте state_objects для граничных условий.

Шаг 3. Добавьте шаг в пайплайн (GitHub Actions, GitLab CI или CircleCI) с переменной TENDERLY_ACCESS_KEY. При failure симуляции пайплайн останавливается.

- name: Simulate deployment transaction
  env:
    TENDERLY_ACCESS_KEY: ${{ secrets.TENDERLY_ACCESS_KEY }}
  run: npx ts-node scripts/simulate-deploy.ts

Virtual TestNets: замена локального форка

Tenderly Virtual TestNets (бывший Tenderly Forks) — это persistent fork mainnet с RPC endpoint. Подключаешь через MetaMask или wagmi как обычную сеть и тестируешь прямо в браузере с реальным UI. Создание Virtual TestNet через CLI:

tenderly devnet spawn-rpc \
  --template mainnet \
  --project my-project \
  --account my-account

Возвращает RPC URL. Добавляем в wagmi config:

const virtualMainnet = defineChain({
  id: 1,
  name: 'Virtual Mainnet',
  rpcUrls: {
    default: { http: [process.env.TENDERLY_VIRTUAL_TESTNET_RPC!] }
  }
});

State сбрасывается по запросу или по расписанию — удобно для CI, где каждый тест-ран начинается с чистого состояния.

Что входит в настройку

Мы предоставляем конфигурацию Tenderly проекта и API ключей (с доступом к дашборду), скрипты симуляции для 3-5 типовых транзакций, интеграцию с CI (GitHub Actions, GitLab CI, CircleCI), виртуальную TestNet для вашего mainnet-форка и документацию по использованию. Получите консультацию — настройка сократит время тестирования на 30-50% и снизит риск costly bug репортов. Свяжитесь с нами для оценки вашего проекта — мы подберём оптимальную конфигурацию под ваш стек и бюджет.

Опыт и гарантии

10+ лет в блокчейн-разработке, 50+ проектов на Ethereum, Polygon, Arbitrum. Гарантируем, что настройка Tenderly сократит время тестирования на 30-50% и снизит риск costly bug репортов. Закажите настройку — получите консультацию бесплатно.

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

Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $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).

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 = потеря всего пула.

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

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-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.