Тестирование смарт-контрактов (интеграционные тесты)

Тестирование смарт-контрактов (интеграционные тесты)

В реальной разработке unit-тесты часто пропускают критические ошибки. Типичный пример: контракт стейкинга с reward-дистрибьюцией проходит все unit-тесты, но на mainnet через неделю обнаруживается — если вызвать compound() и withdraw() в одной транзакции через агрегатор, пользователь получает двойное вознаграждение за один epoch. Причина — race condition между чтением и записью состояния в разных контрактах. Именно такие баги мы ловим в интеграционных тестах.

Наш опыт: более 80% критических уязвимостей в DeFi-протоколах возникают на стыке контрактов, а не внутри отдельных функций. Согласно OpenZeppelin, интеграционное тестирование на форке mainnet — единственный способ выявить их до деплоя. Наши данные показывают, что интеграционные тесты на форке mainnet выявляют в 3 раза больше критических ошибок, чем изолированные unit-тесты. Одна уязвимость reentrancy может стоить протоколу до $2 млн — мы предотвращаем такие потери.

Как mainnet fork делает тесты реалистичными?

Вместо моков мы используем реальное состояние блокчейна. Через Hardhat или Foundry форкаем mainnet на конкретном блоке (фиксация block number гарантирует воспроизводимость). Тестируем взаимодействие с живыми пулами Uniswap V3, Aave V3, Chainlink — не с тестовыми заглушками. Это покрывает все тонкости реальных токенов: fee-on-transfer (USDT), rebase (stETH), blacklist (USDC).

// hardhat.config.ts
networks: {
  hardhat: {
    forking: {
      url: process.env.ALCHEMY_URL,
      blockNumber: 19500000,
    }
  }
}

Почему интеграционное тестирование критически важно для DeFi?

DeFi-протоколы состоят из десятков взаимодействующих контрактов, и каждый стык — потенциальная уязвимость. Мы тестируем не отдельные функции, а сквозные сценарии:

• Multi-step DeFi: deposit → approve LP → stake → harvest → compound. Тест проверяет итоговое состояние после цепочки.
• Flash loan attack: через Aave V3 flashLoanSimple() имитируем заем и пытаемся манипулировать ценой в AMM. Если контракт использует spot price без TWAP — он уязвим.
• Reentrancy: создаем контракт-атакер с callback-функциями (onERC721Received), который рекурсивно вызывает контракт до обновления состояния.
• Sandwich attack: симулируем движение цены между approve() и swap(), проверяем slippage-защиту.

Результаты таких тестов предотвращают потери в сотни тысяч долларов для клиентов. Около 90% уязвимостей, найденных нами, относятся к категориям, которые не покрывают unit-тесты.

Сравнение инструментов: Foundry vs Hardhat

Foundry выполняет 200 тестов за 15–30 секунд, Hardhat — за 3–5 минут. Но Hardhat удобнее для сложных JavaScript-сценариев и точного контроля газа. Мы используем оба: Foundry для быстрого fuzzing, Hardhat для многошаговых сценариев. Foundry встроенный fuzz-движок ускоряет поиск инвариантных нарушений в 10–20 раз относительно Hardhat с плагинами.

Как тестировать reentrancy на форке mainnet?

Создаём контракт-атакер, который перевызывает исходный контракт через callback. Тест на форке mainnet даёт реальную стоимость газа — если в мок-среде тест проходит, на mainnet может не хватить лимита. Пример:

contract Attacker {
    IVulnerable target;
    constructor(IVulnerable _target) { target = _target; }
    function onERC721Received(address, address, uint256, bytes calldata) external returns(bytes4) {
        target.withdraw(); // рекурсивный вызов
        return this.onERC721Received.selector;
    }
}

Типичные ошибки, обнаруженные в проектах

1. Предположение о порядке событий в блоке. Если контракт использует block.number для расчёта наград, а два вызова в одном блоке — block.number одинаков для обоих. Нужен block.timestamp или счётчик.
2. Моки вместо реальных токенов. Мок-токен всегда возвращает true на transfer(). USDT на Ethereum не возвращает значение (не соответствует ERC-20). Тест с моком пройдёт, деплой с USDT — нет.
3. Игнорирование лимита газа. Интеграционный тест должен замерять gas consumption. Если агрегатор вызывает 10 пулов Curve в одной транзакции, можно упереться в block gas limit (30 млн газа).
4. Нет тестов на edge case токенов. Fee-on-transfer (PAXG), rebase (stETH), pausable (USDC), blacklist — каждая категория требует отдельного тест-сьюта. Экономия на таких тестах ведёт к потере средств.

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

• Анализ контрактов и выявление критических путей.
• Написание интеграционного тест-сьюта на Foundry или Hardhat.
• Прогон на форке mainnet с фиксацией block number.
• Документирование найденных проблем с рекомендациями.
• Повторный прогон после исправлений (гарантия качества).
• Обучение команды заказчика запуску и поддержке тестов.

Сроки: интеграционное тестирование существующего протокола занимает от 2 до 5 рабочих дней в зависимости от сложности. Если тесты пишутся параллельно с контрактами — закладываем 30–40% времени разработки. Стоимость рассчитывается индивидуально. Наша команда имеет 10+ лет опыта в блокчейн-разработке и провела интеграционное тестирование для 50+ DeFi-протоколов.

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

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

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