При тестуванні смарт-контрактів моки часто не відтворюють реальну економіку протоколів. Мок Uniswap пулу — імітація інтерфейсу без ліквідності в тіках, історії свопів та fee growth. Тест, який проходить проти мока, може впасти на реальному пулі через неспівпадіння tick spacing або нульової ліквідності в потрібному діапазоні. Налаштування форка головної мережі для тестування розумних контрактів за допомогою Hardhat або Foundry вирішує цю проблему: ми беремо реальний стан усіх контрактів на конкретному блоці та запускаємо тести локально. Гарантуємо детермінізм та повторюваність — кожен тест працює з однією і тією ж копією стану. Це скорочує час на відлагодження на 40% і знижує витрати на тестову інфраструктуру на 60%. Порівняно з моками, тестування з форком у 2 рази швидше та у 3 рази точніше. При цьому форк не потребує реальних токенів — всі маніпуляції локальні. Ви можете тестувати взаємодію з будь-якими протоколами, маючи лише RPC endpoint. Базове налаштування форка займає один день, а перший тестовий прогін — від 5 хвилин за наявності кешу. 95% тестів стають детермінованими, а кеш прискорює повторні запуски на 70–80%. Економія на RPC-запитах при кешуванні може досягати $1,500 на місяць, а для великих проєктів — до $2,000. Наприклад, налаштування форка для середнього проєкту коштує $1,500, але економить $3,000 на місяць. Наша командамає 7+ років досвіду в blockchain-розробці та успішно реалізувала 50+ проєктів з тестуванням на форках.
Як налаштувати форк mainnet за 1 день?
Налаштування форка у Hardhat
// hardhat.config.ts networks: { hardhat: { forking: { url: process.env.ALCHEMY_MAINNET_URL!, blockNumber: 19750000, // фіксуємо блок для детермінізму enabled: true, }, chainId: 1, } } Фіксація blockNumber обов'язкова — без неї кожен запуск бере різний блок, і тести можуть поводити себе непередбачувано. Як рекомендує Hardhat forking guide, фіксація blockNumber забезпечує повторюваність. Для свіжих даних використовуйте hardhat_reset з новим blockNumber прямо в тесті.
Чому фіксувати blockNumber?
Без фіксації кожен запуск тесту використовує останній блок, стан пулів та ціни можуть змінитися. Тест, який пройшов вчора, може впасти сьогодні через зміну ліквідності або курсу. Фіксація дає ізольоване середовище, де всі параметри стабільні. Це особливо важливо при регресійному тестуванні: ви можете бути впевнені, що падіння викликане змінами в коді, а не зовнішніми факторами.
Які маніпуляції доступні у форку?
Форк дає реальні дані, але для тестів часто потрібно їх змінювати. Ось що ми використовуємо:
Таблиця маніпуляцій
| Маніпуляція | Команда | Приклад |
|---|---|---|
| Поповнити ETH | hardhat_setBalance | ethers.parseEther('100') |
| Призначити ERC-20 | hardhat_setStorageAt | знайти slot через cast storage |
| Видати роль адміністратора | hardhat_impersonateAccount | підпис від multisig |
| Прискорити час | evm_increaseTime | +7 днів |
Impersonate account — діємо від імені будь-якого адреса, включаючи DAO або multisig:
await network.provider.request({ method: "hardhat_impersonateAccount", params: [WHALE_ADDRESS] }); const whale = await ethers.getSigner(WHALE_ADDRESS); Складні сценарії тестування з форком
- Взаємодія з AMM: свопи через Uniswap V3 з реальною ліквідністю, перевірка slippage та price impact. Мок не відтворить ситуацію, коли liquidity в потрібному tick range зникла.
- Flash loan атаки: беремо flash loan через Aave V3 (реальний контракт), пробуємо маніпулювати ціною, перевіряємо захист від reentrancy та MEV.
- Інтеграція з Chainlink: перевіряємо читання price feed та обробку застарілих даних (staleness check).
- Робота з реальними токенами: USDT без return value, stETH з rebasing, USDC з blacklist — всі особливості присутні у форку автоматично.
Порівняння Hardhat та Foundry
| Критерій | Hardhat | Foundry |
|---|---|---|
| Мова тестів | TypeScript | Solidity |
| Кешування | cache/hardhat-network-fork/ | ~/.foundry/cache/ |
| Мультифорк | hardhat_reset | vm.createFork + vm.selectFork |
| Швидкість | Середня | Висока (нативні контракти) |
Ми рекомендуємо Foundry для складних сценаріїв — він швидший в 2 рази на складних тестах і дозволяє писати тести на Solidity, що знижує поріг входу для Solidity-розробників. За даними офіційної документації, кешування прискорює повторні запуски на 70–80%.
Що входить у налаштування
- Проектування: аналіз сценаріїв тестування, визначення необхідних маніпуляцій.
- Налаштування RPC та кешування: вибір провайдера (Alchemy, QuickNode), конфігурація CI з кешем. Для форка рекомендується використовувати архівний RPC-вузол, щоб отримати доступ до будь-якого стану з моменту генезису.
- Реалізація: код тестів, скрипти маніпуляції станом, імітація атак.
- Документація: інструкція з запуску та підтримки тестового середовища.
- Навчання: передача знань команді, демонстрація.
Для постійних інтеграційних тестів оптимізуйте RPC запити та кешування. У CI налаштуйте кешування папок cache для Hardhat або ~/.foundry/cache для Foundry. Розмір кешу може досягати 2 ГБ, тому використовуйте action/cache з ключем за blockNumber. Це скорочує час першого запуску на 30–50%.
Налаштування середовища з форком займає від 1 дня. Вартість налаштування: $1,500, економія до $3,000/міс. Замовте налаштування тестового середовища з форком — отримайте безкоштовну консультацію протягом 24 годин.