Проблема: чорний ящик після деплою
Після деплою контракту на 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 годину. Отримайте консультацію з налаштування верифікації — зробимо ваші контракти прозорими.
Зв'яжіться з нами, щоб обговорити деталі вашого проекту — ми відповімо протягом години.