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

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1 услугВсе 1306 услуг
Верификация смарт-контрактов на блок-эксплорерах
Простая
~2-3 часа
Часто задаваемые вопросы
Направления блокчейн-разработки
Этапы блокчейн-разработки
Последние работы
  • image_website-b2b-advance_0.png
    Разработка сайта компании B2B ADVANCE
    1221
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1163
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    855
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1056
  • image_logo-advance_0.png
    Разработка логотипа компании B2B Advance
    561
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    828

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

Задеплоенный контракт без верификации — это чёрный ящик. Пользователи видят байткод, но не исходники. Etherscan показывает «Contract» вместо имён функций. Никто не может проверить, что контракт делает то, что написано в документации. Для любого публичного протокола это репутационная проблема и барьер для интеграций — другие протоколы не будут вызывать контракт, который нельзя проверить.

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

Блок-эксплорер принимает исходники и параметры компилятора, компилирует локально и сравнивает bytecode с тем, что в чейне. Матч — контракт считается верифицированным, исходники публикуются.

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

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

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 поддерживает деплой с одновременной верификацией через Sourcify:

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

Частые причины провала верификации

  • Несовпадение версии компилятора: в коде pragma solidity ^0.8.0, задеплоено компилятором 0.8.21, на эксплорере указали 0.8.0
  • Настройки оптимизации не совпадают с теми, что были при деплое
  • Контракт использует библиотеки — они должны быть либо встроены (inline), либо задеплоены и адреса указаны при верификации
  • Прокси-паттерн: верифицируется имплементация, но эксплорер видит прокси — нужна дополнительная верификация прокси через «Is this a proxy?» на Etherscan

Для прокси-контрактов (Transparent, UUPS) Etherscan поддерживает верификацию через ABI proxy detection — нажать кнопку «Verify as proxy» после верификации обеих частей (proxy + implementation).

Срок: 2-3 часа на верификацию стандартного контракта, включая диагностику причин провала и повторные попытки.