Верификация исходного кода контрактов
Верификация исходного кода — это механизм доверия, позволяющий любому пользователю убедиться, что деплоенный контракт соответствует опубликованному исходному коду. Без верификации пользователи вынуждены слепо доверять разработчику, что противоречит принципам децентрализации.
После деплоя смарт-контракта на блокчейн TON пользователи видят только скомпилированный байткод — набор инструкций TVM, который невозможно прочитать. Как убедиться, что контракт делает именно то, что заявлено? Ответ — верификация исходного кода: процесс, при котором разработчик доказывает, что опубликованный исходный код соответствует развёрнутому контракту.
Верифицированные контракты получают специальный значок на эксплорерах, а пользователи могут самостоятельно проверить логику контракта перед взаимодействием с ним.
Как работает верификация
Процесс верификации основан на детерминированной компиляции: один и тот же исходный код с одинаковыми настройками компилятора всегда даёт одинаковый байткод.
Алгоритм верификации:
- Разработчик отправляет исходный код, версию компилятора и настройки
- Бэкенд верификатора компилирует исходный код с указанными параметрами
- Полученный code cell hash сравнивается с хешем байткода контракта на блокчейне
- Если хеши совпадают — контракт считается верифицированным
- Результат записывается через реестровые контракты on-chain
- Исходный код сохраняется в IPFS для долговременного хранения
Верификация перманентна: code cell hash неизменен для задеплоенного контракта. Если контракт не является обновляемым (upgradeable), верификация остаётся действительной навсегда.
verifier.ton.org — веб-интерфейс
verifier.ton.org — это официальный веб-интерфейс для верификации смарт-контрактов на TON. Он предоставляет удобный UI для загрузки исходного кода и проверки контрактов.
Поддерживаемые языки
| Язык | Статус |
|---|---|
| FunC | Полная поддержка |
| Tact | Полная поддержка |
| Tolk | Поддерживается |
Пошаговый процесс
- Откройте verifier.ton.org
- Укажите адрес развёрнутого контракта
- Загрузите файлы исходного кода
- Выберите версию компилятора, использованную при деплое
- Укажите настройки компиляции (если отличаются от стандартных)
- Нажмите Verify — система скомпилирует код и сравнит результат с on-chain байткодом
- При успешной верификации контракт получает статус “Verified” на эксплорерах
Результаты верификации автоматически отображаются на Tonviewer и других совместимых эксплорерах в виде значка “verified”.
Blueprint verify — CLI-верификация
Если вы используете Blueprint для разработки (а именно его мы рассматривали в модуле о смарт-контрактах), верификацию можно выполнить прямо из командной строки:
npx blueprint verify
Blueprint поддерживает верификацию контрактов на Tact, FunC и Tolk. Команда компилирует исходный код и сравнивает code cell hash с развёрнутым контрактом на блокчейне.
Верификация в mainnet с кастомным API-ключом
npx blueprint verify \
--custom https://toncenter.com/api/v2/jsonRPC \
--custom-version v2 \
--custom-type mainnet \
--custom-key YOUR_API_KEY
Полезные флаги
| Флаг | Назначение |
|---|---|
--custom | URL кастомного API-эндпоинта |
--custom-version | Версия API (v2) |
--custom-type | Тип сети (mainnet / testnet) |
--custom-key | API-ключ для доступа |
--compiler-version | Точная версия компилятора для воспроизводимости |
Сохраняйте точную версию компилятора! Если при деплое использовалась одна версия компилятора, а при верификации — другая, code cell hash может отличаться, и верификация провалится. Всегда фиксируйте версию компилятора в конфигурации проекта.
Post-deployment workflow
Верификация — неотъемлемая часть процесса деплоя. Рекомендуемый порядок действий:
Чек-лист верификации
Перед запуском верификации убедитесь:
- Исходный код совпадает — вы используете именно тот код, который был скомпилирован при деплое. Ни одна строка не была изменена
- Версия компилятора совпадает — точная версия Tact, FunC или Tolk, включая минорную версию
- Настройки компилятора совпадают — флаги оптимизации, целевая сеть и другие параметры идентичны деплою
- Зависимости совпадают — версии библиотек (например,
@stdlibдля Tact) должны быть теми же
Наиболее частая причина провала верификации — несовпадение версии компилятора. Даже минорное обновление (например, Tact 1.5.0 -> 1.5.1) может изменить генерируемый байткод. Фиксируйте версии в package.json и сохраняйте lock-файл.
Интеграция с эксплорерами
Что видит пользователь
После успешной верификации контракт получает специальное отображение на эксплорерах:
| Эксплорер | Что отображается |
|---|---|
| Tonviewer | Вкладка “Source” с подсветкой синтаксиса, значок “Verified” |
| tonscan.org | Статус верификации контракта |
| Другие эксплореры | Зависит от интеграции с верификатором |
На Tonviewer пользователь может:
- Видеть зелёный значок “Verified” рядом с адресом контракта
- Открыть вкладку с полным исходным кодом
- Читать код с подсветкой синтаксиса
- Убедиться, что контракт делает именно то, что заявлено
SDK для кастомной интеграции
Для разработчиков эксплореров и dApp существует @ton-community/contract-verifier-sdk — библиотека, которая позволяет интегрировать проверку верификации в собственные приложения. С помощью SDK можно:
- Проверять статус верификации контракта
- Получать исходный код верифицированных контрактов
- Отображать информацию о верификации в собственном интерфейсе
Ключевые выводы
- Верификация = доказательство соответствия — исходный код компилируется и сравнивается с on-chain байткодом по code cell hash
- verifier.ton.org — официальный веб-интерфейс, поддерживает FunC, Tact и Tolk
npx blueprint verify— CLI-команда для верификации прямо из проекта Blueprint- Верифицируйте сразу после деплоя — пока версия компилятора и исходный код точно совпадают с деплоем
- Верификация перманентна — code cell hash неизменен, поэтому результат верификации остаётся навсегда (для необновляемых контрактов)
Частые ошибки
- Деплоят контракт с другой версией компилятора, чем использовали при верификации: даже минимальная разница в версии может привести к различию в байткоде.
- Не фиксируют зависимости (lock-файлы): обновление зависимости может изменить скомпилированный код.
- Забывают включить все файлы проекта в верификацию: отсутствие одного import-файла приведёт к несовпадению хешей.
- Не верифицируют контракт сразу после деплоя: со временем найти точную конфигурацию сборки становится сложнее.
Проверка знанийЧто произойдёт, если при верификации исходный код не совпадает с on-chain байткодом контракта?
Check Your Understanding
Finished the lesson?
Mark it as complete to track your progress
Войдите чтобы оценить урок