Отладка и тестирование Solidity: настройка Foundry, Hardhat, Anvil

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Отладка и тестирование Solidity: настройка Foundry, Hardhat, Anvil
Средний
~1 день
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Проблема: тесты падают, доверия нет

Представьте: вы деплоите контракт в mainnet, но через час обнаруживаете reentrancy-уязвимость. Пользователи потеряли средства — репутация подорвана, аудит не помог. Каждый час простоя обходится в $5,000, а ущерб от reentrancy-атак превышает $100M. Или типичная ситуация: новый разработчик тратит полдня на установку зависимостей и запуск первого теста. CI-пайплайн упал, но никто не знает почему — логи пусты.

Наша команда с 5-летним опытом в блокчейн-разработке настроила такие среды для 50+ проектов, включая протоколы с суммарным TVL > $1B. В результате время деплоя сократилось на 40%, а число багов в продакшене — на 70%. Это не просто тулчейн — это гарантия стабильности и воспроизводимости.

Какой фреймворк выбрать под задачу?

Для Solidity-проектов сейчас два реальных варианта: Foundry и Hardhat. Они решают разные задачи и часто используются вместе. Выбор зависит от того, что вы тестируете: логику контракта или интеграцию с фронтендом.

Параметр Foundry Hardhat
Язык тестов Solidity TypeScript/JavaScript
Скорость выполнения Очень быстро (revm на Rust) Медленнее (до 5x)
Fuzz-тестирование Встроено (differential, invariant) Только через плагины
Mainnet fork vm.createFork() --fork-url
Frontend интеграция Сложнее Проще (ethers.js, Wagmi)
Скрипты деплоя Solidity scripts TypeScript + ethers.js
Отладка транзакций forge debug console.log() в контракте

Наш стандарт: Foundry для unit и fuzz-тестов, Hardhat для скриптов деплоя и интеграции с frontend. Оба конфига сосуществуют в одном репозитории — это позволяет писать тесты на Solidity, а деплоить через TypeScript.

Как устроена структура проекта?

Используем разделение на модули: contracts/core, contracts/interfaces, test/unit, test/integration, test/invariant, script (Foundry), deploy (Hardhat) и fixtures. Такая организация позволяет отделить модульные тесты (без RPC) от интеграционных (с форком). Unit-тесты должны выполняться за считанные секунды, а интеграционные — только при мерже в main.

Настройка локальной сети, моков и фикстур

Локальная сеть: Anvil вместо Ganache

Anvil (входит в Foundry) — локальный EVM-нод на Rust. Быстрее Ganache в 10 раз, активно поддерживается. Для разработки запускаем в режиме форка mainnet или testnet:

# Форк Ethereum mainnet с конкретным блоком (воспроизводимость)
anvil --fork-url $MAINNET_RPC --fork-block-number 19500000

# Форк с предопределёнными аккаунтами и балансами
anvil --fork-url $MAINNET_RPC --accounts 10 --balance 10000

Форк-тестирование — единственный способ проверить интеграцию с Uniswap, Aave, Chainlink без деплоя на testnet. Транзакция в локальном форке — мгновенно. На Sepolia — 12-15 секунд. Экономия времени на каждой итерации: вместо 15 секунд — 0.1 секунды. Используйте Ethereum testnets для знакомства с сетями.

Моки и фикстуры: изоляция без хрупкости

Для изоляции тестов используем иерархию фикстур:

// BaseFixture.sol — общие зависимости
abstract contract BaseFixture is Test {
    MockERC20 token;
    MockChainlinkOracle oracle;

    function setUp() public virtual {
        token = new MockERC20("Test", "TST", 18);
        oracle = new MockChainlinkOracle(2000e8); // $2000 price
    }
}

// ProtocolFixture.sol — деплой тестируемого протокола
contract ProtocolFixture is BaseFixture {
    Protocol protocol;

    function setUp() public override {
        super.setUp();
        protocol = new Protocol(address(token), address(oracle));
    }
}

Не используем vm.mockCall для основных зависимостей — это хрупко и не проверяет интерфейс. Создаём полноценные mock-контракты с минимальной реализацией. Такой подход снижает число ложных срабатываний на 30%.

Пошаговая настройка и CI/CD

Подробная инструкция
  1. Установите Foundry: curl -L https://foundry.paradigm.xyz | bash.
  2. Создайте конфигурацию: forge init и настройте foundry.toml под ваш проект.
  3. Добавьте Hardhat: npm install --save-dev hardhat и сгенерируйте hardhat.config.ts.
  4. Запустите локальный нод: anvil в отдельном терминале.
  5. Напишите первый тест: используйте шаблон из fixture выше.
  6. Настройте CI: добавьте GitHub Actions workflow (см. ниже).

CI/CD: автоматизация без сюрпризов

Конфигурация GitHub Actions для Foundry:

name: Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Foundry
        uses: foundry-rs/foundry-toolchain@v1
      - name: Run unit tests
        run: forge test --match-path "test/unit/*" -vvv
      - name: Run integration tests
        run: forge test --match-path "test/integration/*" --fork-url ${{ secrets.MAINNET_RPC }}
      - name: Coverage check
        run: forge coverage --min-line-coverage 80

Разделяем unit и integration тесты — unit-тесты должны работать без RPC-ключей. Интеграционные — только на PR в main. Это сокращает время фидбэка до 2 минут.

Testnet и объём работ

Поддержка нескольких сетей

Настраиваем multi-network конфиг в Hardhat:

networks: {
  sepolia: {
    url: process.env.SEPOLIA_RPC,
    accounts: [process.env.DEPLOYER_KEY],
    chainId: 11155111,
  },
  polygon_amoy: {
    url: process.env.AMOY_RPC,
    accounts: [process.env.DEPLOYER_KEY],
    chainId: 80002,
  },
}
Testnet Chain ID Faucet Block Time
Sepolia 11155111 Alchemy / Chainlink 12 sec
Polygon Amoy 80002 Official Polygon 2 sec
BNB Testnet 97 Binance Faucet 3 sec

Объём работ и сроки

Отметим: что входит в настройку:

  • Конфигурация Foundry и Hardhat (foundry.toml, hardhat.config.ts)
  • Набор mock-контрактов (ERC-20, Chainlink Oracle)
  • Иерархия фикстур под ваш протокол
  • Локальный EVM-нод (Anvil) с форк-режимом
  • CI-пайплайн (GitHub Actions) с разделением unit/integration тестов
  • Настройка testnet (Sepolia, Polygon Amoy, BNB Chain testnet)
  • Документация по запуску и расширению
  • Обучение команды (1-2 часа)

Сроки: базовая настройка — 1 рабочий день. С кастомными моками и фикстурами — 1-2 дня. Для проектов с несколькими чейнами (EVM + Solana) — 2-3 дня. Результат: сокращение времени на тестирование до 60%, выявление уязвимостей на ранних стадиях, стабильный CI. Ежемесячная экономия от такого подхода может достигать $10,000.

Заказ настройки тестовой среды

Свяжитесь с нами — мы проведём бесплатный аудит вашего текущего процесса и предложим конфигурацию под ваш протокол. Получите консультацию по оптимизации тестового окружения. Гарантируем: после настройки каждый коммит будет проходить проверку без сюрпризов. Закажите настройку сегодня — начните тестировать с уверенностью.

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

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

Язык Модель исполнения Типичная область Риски
Solidity 0.8.x EVM, последовательное исполнение DeFi, NFT, токены Reentrancy, переполнение (unchecked)
Rust (Anchor) Solana, параллельное Высоконагруженные DEX, игры Неправильное объявление аккаунтов
Move Aptos/Sui, ресурсная Крупные протоколы Сложность экосистемы
Vyper EVM, ограниченный синтаксис Критические контракты (Curve) Зависимость от стабильности компилятора

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

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

Паттерн Механизм Риск Когда использовать Наш опыт
Transparent Proxy (OZ) admin vs user разделение Storage collision, centralization Стандартные проекты 15+ реализаций
UUPS Логика апгрейда в implementation Забыть _authorizeUpgrade → контракт навсегда сломан Газ-оптимизированные проекты 7 проектов
Diamond (EIP-2535) Множество facets Сложность аудита Крупные протоколы с 10+ контрактами 3 внедрения
Beacon Proxy Один beacon для множества proxies Beacon = single point of failure Фабрики однотипных контрактов 5 фабрик

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