Верификация исходного кода контрактов

Верификация исходного кода — это механизм доверия, позволяющий любому пользователю убедиться, что деплоенный контракт соответствует опубликованному исходному коду. Без верификации пользователи вынуждены слепо доверять разработчику, что противоречит принципам децентрализации.

После деплоя смарт-контракта на блокчейн TON пользователи видят только скомпилированный байткод — набор инструкций TVM, который невозможно прочитать. Как убедиться, что контракт делает именно то, что заявлено? Ответ — верификация исходного кода: процесс, при котором разработчик доказывает, что опубликованный исходный код соответствует развёрнутому контракту.

Верифицированные контракты получают специальный значок на эксплорерах, а пользователи могут самостоятельно проверить логику контракта перед взаимодействием с ним.

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

Процесс верификации основан на детерминированной компиляции: один и тот же исходный код с одинаковыми настройками компилятора всегда даёт одинаковый байткод.

Процесс верификации контракта

Исходный код + Версия компилятора + Настройки

Компиляция

Code Cell Hash (результат)

Сравнение с on-chain байткодом контракта

Совпадает → Verified ✓

Не совпадает → Failed ✗

Алгоритм верификации:

Разработчик отправляет исходный код, версию компилятора и настройки
Бэкенд верификатора компилирует исходный код с указанными параметрами
Полученный code cell hash сравнивается с хешем байткода контракта на блокчейне
Если хеши совпадают — контракт считается верифицированным
Результат записывается через реестровые контракты on-chain
Исходный код сохраняется в IPFS для долговременного хранения

TIP

Верификация перманентна: 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`	Точная версия компилятора для воспроизводимости

WARNING

Сохраняйте точную версию компилятора! Если при деплое использовалась одна версия компилятора, а при верификации — другая, code cell hash может отличаться, и верификация провалится. Всегда фиксируйте версию компилятора в конфигурации проекта.

Post-deployment workflow

Верификация — неотъемлемая часть процесса деплоя. Рекомендуемый порядок действий:

Пайплайн: деплой → верификация

1. Deploy to testnet

2. Тестирование на testnet

3. Deploy to mainnet

4. Верификация (сразу после деплоя!)

5. Проверка на эксплорере

Чек-лист верификации

Перед запуском верификации убедитесь:

Исходный код совпадает — вы используете именно тот код, который был скомпилирован при деплое. Ни одна строка не была изменена
Версия компилятора совпадает — точная версия Tact, FunC или Tolk, включая минорную версию
Настройки компилятора совпадают — флаги оптимизации, целевая сеть и другие параметры идентичны деплою
Зависимости совпадают — версии библиотек (например, @stdlib для Tact) должны быть теми же

WARNING

Наиболее частая причина провала верификации — несовпадение версии компилятора. Даже минорное обновление (например, 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-файла приведёт к несовпадению хешей.
Не верифицируют контракт сразу после деплоя: со временем найти точную конфигурацию сборки становится сложнее.

Проверка знанийKnowledge check

Что произойдёт, если при верификации исходный код не совпадает с on-chain байткодом контракта?

ОтветAnswer

Верификация провалится, потому что скомпилированный code cell hash будет отличаться от хеша байткода, хранящегося на блокчейне. Это может произойти из-за изменений в исходном коде, другой версии компилятора или других настроек компиляции.