Настройка форка mainnet для тестирования смарт-контрактов

При тестировании смарт-контрактов моки часто не воспроизводят реальную экономику протоколов. Мок 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 даёт стабильность?

Без фиксации каждый запуск теста использует последний блок, состояние пулов и цены могут измениться. Тест, который прошёл вчера, может упасть сегодня из-за изменения ликвидности или курса. Фиксация даёт изолированную среду, где все параметры стабильны. Это особенно важно при регрессионном тестировании: вы можете быть уверены, что падение вызвано изменениями в коде, а не внешними факторами.

Какие манипуляции доступны в форке?

Форк даёт реальные данные, но для тестов часто нужно их менять. Вот что мы используем:

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

Мы рекомендуем Foundry для сложных сценариев — он быстрее и позволяет писать тесты на Solidity, что снижает порог входа для Solidity-разработчиков. По данным официальной документации, кэширование ускоряет повторные запуски на 70–80%. Если вам нужна помощь в настройке форка в CI, свяжитесь с нами — мы поможем оптимизировать процесс.

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

1. Проектирование: анализ сценариев тестирования, определение необходимых манипуляций.
2. Настройка RPC и кэширования: выбор провайдера (Alchemy, QuickNode), конфигурация CI с кэшем. Для форка mainnet рекомендуется использовать архивный RPC-узел, чтобы получить доступ к любому состоянию с момента генезиса.
3. Реализация: код тестов, скрипты манипуляции состоянием, имитация атак.
4. Документация: инструкция по запуску и поддержке тестовой среды.
5. Обучение: передача знаний команде, демонстрация.

Для постоянных интеграционных тестов оптимизируйте RPC запросы и кэширование. В CI настройте кэширование папок cache для Hardhat или ~/.foundry/cache для Foundry. Размер кэша может достигать 2 ГБ, поэтому используйте action/cache с ключом по blockNumber. Это сокращает время первого запуска на 30–50%.

Настройка среды с форком занимает от 1 дня. Стоимость рассчитывается индивидуально. Закажите настройку тестовой среды с форком — получите бесплатную консультацию в течение 24 часов. Опыт наших инженеров — более 5 лет в блокчейн-разработке, выполнено более 40 проектов с форками mainnet.

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

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