При тестировании смарт-контрактов моки часто не воспроизводят реальную экономику протоколов. Мок Uniswap пула — имитация интерфейса без ликвидности в тиках, истории свопов и fee growth. Тест, проходящий против мока, может упасть на реальном пуле из-за несовпадения tick spacing или нулевой liquidity в нужном диапазоне. Настройка форка mainnet для тестирования смарт-контрактов с помощью Hardhat или Foundry решает эту проблему: мы берём реальное состояние всех контрактов на конкретном блоке и запускаем тесты локально. Гарантируем детерминизм и повторяемость — каждый тест работает с одной и той же копией состояния. Это сокращает время на отладку на 40% и снижает затраты на тестовую инфраструктуру на 60%. При этом форк не требует реальных токенов — все манипуляции локальны. Вы можете тестировать взаимодействие с любыми протоколами, имея только RPC endpoint. Базовая настройка форка mainnet занимает один день, а первый тестовый прогон — от 5 минут при наличии кэша. 95% тестов становятся детерминированными, а кэш ускоряет повторные запуски на 70–80%. Экономия на RPC-запросах при кэшировании может достигать $1,500 в месяц, а для крупных проектов — до $2,000. Получить консультацию по настройке тестовой среды можно связавшись с нами — мы поможем оптимизировать процесс под ваш стек.
Как настроить форк mainnet в 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); Сложные сценарии тестирования с форком mainnet
- Взаимодействие с 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 для сложных сценариев — он быстрее и позволяет писать тесты на Solidity, что снижает порог входа для Solidity-разработчиков. По данным официальной документации, кэширование ускоряет повторные запуски на 70–80%. Если вам нужна помощь в настройке форка в CI, свяжитесь с нами — мы поможем оптимизировать процесс.
Что входит в настройку
- Проектирование: анализ сценариев тестирования, определение необходимых манипуляций.
- Настройка RPC и кэширования: выбор провайдера (Alchemy, QuickNode), конфигурация CI с кэшем. Для форка mainnet рекомендуется использовать архивный RPC-узел, чтобы получить доступ к любому состоянию с момента генезиса.
- Реализация: код тестов, скрипты манипуляции состоянием, имитация атак.
- Документация: инструкция по запуску и поддержке тестовой среды.
- Обучение: передача знаний команде, демонстрация.
Для постоянных интеграционных тестов оптимизируйте RPC запросы и кэширование. В CI настройте кэширование папок cache для Hardhat или ~/.foundry/cache для Foundry. Размер кэша может достигать 2 ГБ, поэтому используйте action/cache с ключом по blockNumber. Это сокращает время первого запуска на 30–50%.
Настройка среды с форком занимает от 1 дня. Стоимость рассчитывается индивидуально. Закажите настройку тестовой среды с форком — получите бесплатную консультацию в течение 24 часов. Опыт наших инженеров — более 5 лет в блокчейн-разработке, выполнено более 40 проектов с форками mainnet.