Верификация смарт-контрактов на блок-эксплорерах под ключ

Проблема: чёрный ящик после деплоя

После деплоя контракта на mainnet пользователи видят только байткод. Etherscan показывает «Contract» вместо имён функций. Другие протоколы не вызывают такой контракт — слишком рискованно. Неверифицированный контракт может содержать backdoor или быть подменён через прокси. Ошибки в конфигурации компиляции (версия, оптимизация, метаданные) приводят к провалу верификации. Мы решаем эту проблему на системном уровне: настраиваем окружение, готовим Standard JSON Input и проходим верификацию с первого раза в 95% случаев.

Как работает верификация?

Блок-эксплорер принимает исходники и параметры компилятора, компилирует локально и сравнивает bytecode с тем, что в чейне. Совпадение — контракт верифицирован, исходники публикуются. Главное требование — детерминированность компиляции. Solidity-компилятор при одинаковых входных данных и настройках должен выдавать идентичный байткод. Расхождение в версии компилятора (например, 0.8.19 vs 0.8.20), флагах оптимизации (runs: 200 vs runs: 999), порядке файлов или метаданных — и верификация не проходит. Документация Solidity подробно описывает этот механизм.

Как сократить время верификации в 3 раза?

Используйте Foundry вместо ручного ввода параметров на эксплорере. forge verify-contract автоматически собирает Standard JSON Input и отправляет на Etherscan. По нашим данным, это сокращает время настройки с 30 минут до 5. Мы подготовили сравнительную таблицу инструментов:

Для простых контрактов достаточно Hardhat, для сложных с прокси и библиотеками — Foundry лучше в 2 раза быстрее.

Как мы справляемся со сложными случаями?

У нас за плечами 7+ лет в блокчейне и более 50 успешных верификаций. Мы сталкивались с прокси-контрактами (UUPS, Transparent), сложными связками библиотек и флеш-займами. Для каждого проекта готовим Standard JSON Input — это снижает вероятность ошибки до нуля. Если контракт использует immutable переменные или calldata со сложными структурами, мы вручную проверяем совпадение constructor-arguments. Верификация через Foundry позволяет сократить время настройки в 3 раза по сравнению с ручным вводом параметров.

Почему верификация важна для безопасности?

Неверифицированный контракт — чёрная дыра для аудиторов. Ни один серьёзный аудит не начнётся без verified-статуса. Верификация — первый шаг к формальной верификации и статическому анализу (Slither, Mythril). Представьте: вы нашли баг, но контракт не верифицирован — исправить и передеплоить невозможно. Экономия на верификации оборачивается миллионными потерями при взломах. Мы гарантируем, что после нашей работы контракт проходит любые проверки.

Как избежать частых ошибок при верификации?

Для прокси-контрактов Etherscan поддерживает детекцию через ABI proxy detection — после верификации обеих частей нажать кнопку «Is this a proxy?». Мы также подключаем @openzeppelin/contracts и используем upgradeable шаблоны.

Инструменты для верификации

Hardhat + hardhat-verify (бывший hardhat-etherscan). После деплоя:

npx hardhat verify --network mainnet 0xCONTRACT_ADDRESS "arg1" "arg2"

Плагин автоматически определяет версию компилятора из hardhat.config.ts, собирает Standard JSON Input и отправляет на Etherscan API. Работает для Ethereum, Polygon, BSC, Arbitrum, Optimism — через конфигурацию etherscan.apiUrl.

Foundry forge verify-contract — работает аналогично, но через Standard JSON Input напрямую:

forge verify-contract 0xCONTRACT_ADDRESS src/MyContract.sol:MyContract \
  --chain-id 1 \
  --etherscan-api-key $ETHERSCAN_KEY \
  --constructor-args $(cast abi-encode "constructor(address)" 0xADDR)

Sourcify — децентрализованная альтернатива. Хранит исходники на IPFS, поддерживается большинством эксплореров. Foundry поддерживает деплой с одновременной верификацией:

forge script Script --broadcast --verify --verifier sourcify

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

• Полная диагностика конфигурации компиляции
• Подготовка Standard JSON Input
• Верификация на блок-эксплорере (до 3 сетей по умолчанию)
• Если прокси — верификация обеих частей
• Повторные попытки при ошибках (включено в стоимость)
• Документация по настройке и развёртыванию
• Консультация по best practices gas optimization и безопасности

Сроки и стоимость

Срок: от 2 часов до 1 рабочего дня — зависит от сложности контракта (наличие библиотек, прокси, количество сетей). Стоимость рассчитывается индивидуально. Закажите верификацию вашего контракта уже сегодня — отправьте ссылку на контракт в любой сети (Etherscan, Polygonscan, Arbiscan) и получите расчёт за 1 час. Получите консультацию по настройке верификации — сделаем ваши контракты прозрачными.

Свяжитесь с нами, чтобы обсудить детали вашего проекта — мы ответим в течение часа.

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

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