Проблема: чёрный ящик после деплоя
После деплоя контракта на 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 hardhat-verify | Средняя (10 мин) | Да (через verify:true) | Требует линковки адресов |
| Foundry forge verify-contract | Высокая (5 мин) | Да (автоматическая детекция) | Автоматическая линковка |
| Sourcify | Средняя (15 мин) | Ограниченная | Требует IPFS Hash |
Для простых контрактов достаточно Hardhat, для сложных с прокси и библиотеками — Foundry лучше в 2 раза быстрее.
Как мы справляемся со сложными случаями?
У нас за плечами 7+ лет в блокчейне и более 50 успешных верификаций. Мы сталкивались с прокси-контрактами (UUPS, Transparent), сложными связками библиотек и флеш-займами. Для каждого проекта готовим Standard JSON Input — это снижает вероятность ошибки до нуля. Если контракт использует immutable переменные или calldata со сложными структурами, мы вручную проверяем совпадение constructor-arguments. Верификация через Foundry позволяет сократить время настройки в 3 раза по сравнению с ручным вводом параметров.
Почему верификация важна для безопасности?
Неверифицированный контракт — чёрная дыра для аудиторов. Ни один серьёзный аудит не начнётся без verified-статуса. Верификация — первый шаг к формальной верификации и статическому анализу (Slither, Mythril). Представьте: вы нашли баг, но контракт не верифицирован — исправить и передеплоить невозможно. Экономия на верификации оборачивается миллионными потерями при взломах. Мы гарантируем, что после нашей работы контракт проходит любые проверки.
Как избежать частых ошибок при верификации?
Типичные ошибки и их решения
| Причина | Решение |
|---|---|
| Несовпадение версии компилятора | Указывать точную версию pragma solidity 0.8.19, на эксплорере — ту же |
| Несовпадение настроек оптимизации (runs) | Сохранять конфиг solc отдельно, использовать get-hardhat-config для логирования |
| Использование библиотек без адресов | Указывать адреса линкованных библиотек при верификации |
| Прокси-контракты | Сначала верифицировать implementation, затем proxy — нажать «Verify as proxy» на Etherscan |
| Метаданные (metadata hash) | Добавить --metadata-hash none в solc или отключить в hardhat |
Для прокси-контрактов 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 час. Получите консультацию по настройке верификации — сделаем ваши контракты прозрачными.
Свяжитесь с нами, чтобы обсудить детали вашего проекта — мы ответим в течение часа.