Коротко: отметка о проверенном исходном коде означает, что предоставленные файлы и настройки компиляции сопоставлены с кодом по адресу контракта. Она упрощает анализ, но не является аудитом и не гарантирует отсутствие ошибок. Подтвердите сеть и адрес, проверьте параметры сборки, а затем выясните, не ведёт ли адрес к proxy.
Что означает верификация
В EVM-сети контракт хранит байткод – инструкции для виртуальной машины. Исходный код удобен для чтения, но в блокчейне он не хранится как обычный текстовый файл. При верификации обозреватель компилирует предоставленные файлы и сравнивает результат с байткодом по адресу. Совпадение позволяет обозревателю показать исходники и детали сборки. Результат относится к конкретной сети и адресу.
На сверку влияют версия компилятора, оптимизатор и его настройки, целевая версия EVM, структура файлов и подключённые библиотеки. Если хотя бы один параметр отличается, подходящий исходник может не пройти проверку. Статус Verified значит, что материал соответствует коду при заданной конфигурации, но не оценивает экономическую логику, безопасность проекта или репутацию его авторов.
Сначала установите сеть, в которой была выполнена транзакция. Один hex-адрес может существовать в нескольких сетях и содержать разные данные. Выберите обозреватель нужной сети, затем сверьте весь адрес, а не только первые и последние символы. Используйте официальный список развёртываний. Для просмотра кода не нужно подключать кошелёк или подписывать сообщение.
Как читать страницу контракта
Найдите строку о статусе исходников и откройте все относящиеся к контракту файлы. Сверьте имя, компилятор, оптимизацию и библиотеки с подтверждённым релизом проекта. Если файлов несколько, изучите импорты и наследование: основной файл может вызывать функции из других модулей. Начните с методов, меняющих балансы, права, лимиты и адреса зависимостей. Проверяйте условия в коде, а не только комментарии разработчика.
Сопоставьте ABI и список доступных методов с исходниками. ABI описывает вызовы, но не раскрывает автоматически их последствия. События помогают видеть историю, хотя контракт не обязан записывать каждое внутреннее изменение удобным журналом. О том, как сопоставить запись журнала и транзакцию, читайте в материале о событиях смарт-контракта.
Для токена отдельно подтвердите адрес и сеть по официальным каналам проекта. Название и символ не уникальны: поддельный актив может показывать те же данные. Проверить адрес поможет инструкция по контракту токена. Если адрес расходится с официальными сведениями, не полагайтесь на значок, название или популярность токена.
Почему proxy требует отдельной проверки
Proxy может принимать пользовательские вызовы, а затем передавать их другой реализации. Верификация только proxy-адреса показывает оболочку и не обязательно основную логику. Найдите адрес реализации, если он доступен, и проверьте его код отдельно. Обозреватель может распознавать знакомые шаблоны автоматически, но такая метка не является доказательством. Отсутствие надписи Proxy не всегда исключает обновляемую схему.
Выясните, кто может заменить реализацию и через какой механизм. Права могут находиться у администратора, multisig или отдельного контроллера. Сверьте адреса и историю обновлений. Инструкция о proxy-admin и implementation объясняет, где искать эти поля. В обновляемом приложении важно понимать не только текущий код, но и правила его будущей замены.
Проверьте внешние вызовы и библиотеки. Контракт может полагаться на оракул, мост, токен или другой адрес. Исходники одного контракта не раскрывают доверенные предположения всех зависимостей. Проследите важные обращения и проверьте права управления. Если контракт хранит средства, обратите внимание на аварийные методы, ограничения и возможность администратора менять их.
Что верификация не доказывает
Она не подтверждает, что аудит актуален, команда заслуживает доверия или интерфейс показывает правильные данные. Она не гарантирует отсутствие ошибок в коде, оракуле, экономической модели или внешней библиотеке. Она не исключает изменения через proxy. Даже точная воспроизводимая сборка отвечает лишь на ограниченный вопрос: соответствует ли предоставленный исходник байткоду конкретного адреса в данной сети.
Не считайте число транзакций, возраст адреса или наличие сайта заменой анализа. Найдите аудит именно той версии и реализации, которой пользуетесь. Проверьте административные права, внешние зависимости и историю событий. Материал о timelock и паузе в DeFi рассказывает, как оценить задержки и аварийные ограничения. Метка в обозревателе – только начало проверки.
Порядок проверки
Определите сеть и полный адрес; откройте его в обозревателе; проверьте статус исходников и параметры компиляции; изучите ABI и важные методы; найдите proxy, реализацию, библиотеки и управляющие адреса; сравните их с официальной документацией и аудитом. Запишите сеть, адрес и блок, на котором посмотрели состояние, поскольку реализация и права могли измениться позднее.
Если исходники не проверены, это не единственный повод объявить проект опасным. Для независимого сравнения придётся повторить сборку с точными версиями инструментов и зависимостей. Если вы не умеете сопоставлять байткод и полномочия, ограничьте сумму взаимодействия и не подписывайте непонятные вызовы. Обозреватель даёт доступ к данным, но вывод о риске требует нескольких источников и понимания конкретной архитектуры.
