Налаштування 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 форк 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 репортів. Замовте налаштування — отримайте консультацію безкоштовно.

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

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

Такі випадки — не рідкість. Смарт-контракт — це фінансова логіка без можливості пропатчити її вночі. Наша команда розробляє контракти під ключ, вбудовуючи захист від reentrancy, MEV та gas-атак на ранніх етапах. Reentrancy attack — одна з найпоширеніших вразливостей, що потребує глибокого розуміння EVM.

Як ми розробляємо смарт-контракти під ключ?

Починаємо з аудиту бізнес-логіки та вибору стеку. 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 деплой погано спроектованого контракту може коштувати значну суму тільки через неоптимальний storage layout. Переупаковка структури Proposal з 7 слотів до 4 заощадила 18k gas на кожному голосуванні — економія на масштабі протоколу з тисячами голосувань на день дає відчутну річну вигоду.

Типові помилки в 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-тестів. Echidna перевіряє інваріанти («сума всіх балансів ≤ totalSupply»).
3. Ручний code review — наші інженери з досвідом 10+ років у блокчейні виявляють логічні помилки, які не ловлять інструменти. Для протоколів з високим TVL обов'язковий зовнішній аудит з боку Trail of Bits, Consensys Diligence або OpenZeppelin. Термін — 2-4 тижні.

Будь-який апгрейдуємий протокол повинен мати timelock. TimelockController з OpenZeppelin: операція пропонується → чекає мінімальний delay (48-72 години) → виконується. Без timelock один скомпрометований deployer wallet = втрата всього пулу.

OpenZeppelin Security Audits підтверджують, що 80% вразливостей, знайдених у деплоїних контрактах, пов'язані з відсутністю перевірок доступу або reentrancy. Ми включаємо ці перевірки в CI ще до першого деплою.

Які патерни апгрейду обираємо?

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 тижнів і йде паралельно з фінальним тестуванням де можливо. Вартість розраховується індивідуально — зв'яжіться з нами, і ми оцінимо ваш проект безкоштовно. Економія на газі завдяки нашій оптимізації може сягати 30% на рік для високонавантажених протоколів.

Зв'яжіться з нами для оцінки вашого проекту. Замовте розробку смарт-контракту — отримайте консультацію з архітектури та захисту від reentrancy, MEV та gas-атак. Напишіть нам — ми підберемо оптимальний стек під вашу задачу.