ГЛАВНАЯ / ИНСТРУКЦИИ / PROXY CONTRACT И IMPLEMENTATION: КАКОЙ АДРЕС СМАРТ-КОНТРАКТА ПРОВЕРЯТЬ
Proxy contract и implementation: какой адрес смарт-контракта проверять
В upgradeable-системе адрес, с которым взаимодействует пользователь, может быть прокси, а исполняемая логика находиться в реализации. Проверяйте оба уровня и выясняйте, кто и как может менять реализацию.
Прокси хранит состояние и передаёт вызов логике implementation
Распространённая прокси-схема использует delegatecall: пользователь вызывает адрес proxy, а он выполняет код implementation в контексте собственного состояния и баланса.
Поэтому для просмотра пользовательского баланса или взаимодействия часто важен адрес прокси. При этом анализ одной лишь прокси-страницы может не показать логику: нужно отдельно открыть реализацию, на которую она указывает.
- proxy – часто точка пользовательского вызова;
- implementation – код, на который делегируется выполнение;
- данные пользователя обычно хранятся в контексте прокси.
Начните с официального адреса, затем выясните тип прокси
Сначала независимо получите адрес приложения из его официальной документации. Затем изучите страницу этого адреса в обозревателе блоков и проверьте, распознан ли контракт как proxy.
Для прокси, совместимого с ERC-1967, реализация или beacon хранится в определённых слотах. Beacon-схема требует прочитать адрес beacon и запросить у него текущую реализацию. Другие схемы могут использовать иной механизм, поэтому не предполагайте универсальное поле.
- адрес приложения найден в первичном источнике;
- тип proxy подтверждён, а не угадан;
- для beacon отдельно проверен адрес и текущая реализация.
Читайте исходный код реализации и административные полномочия
После определения реализации проверьте её опубликованный исходный код, совместимость с нужной версией приложения и доступные функции. Одновременно исследуйте полномочия администратора, владельца или управляющего адреса.
Права обновления имеют практическое значение: код, к которому делегирует proxy, может измениться, если архитектура и доступы это позволяют. События обновления и история адреса помогают отслеживать изменения, но сами по себе не подтверждают добросовестность оператора.
- исходный код реализации открыт и сопоставлен с адресом;
- проверен механизм и субъект обновления;
- изучены события и история смены реализации.
Не взаимодействуйте с адресом реализации как с адресом приложения без причины
Адрес реализации не обязательно является адресом, где находятся пользовательские данные или куда официальное приложение направляет вызовы. Подпись транзакции для произвольного адреса может обойти ожидаемый интерфейс.
Перед подписью сопоставьте сеть, адрес proxy, вызываемую функцию и источник адреса. Если обозреватель не распознал схему или показывает противоречивые данные, остановитесь и найдите описание архитектуры в документации проекта.
- сеть совпадает с документацией;
- proxy-адрес не подменён похожим;
- назначение транзакции понятно до подписи.
Частые вопросы
Какой адрес обычно вводить в dApp?
Используйте адрес, который документация проекта указывает для сети; для proxy-системы это обычно адрес прокси.
Implementation может измениться?
В обновляемых архитектурах – да. Проверяйте событие и текущее значение реализации.
Verified implementation означает, что proxy безопасен?
Нет. Нужно проверять оба адреса, полномочия обновления, код и риск приложения.
У всех прокси одинаковый способ найти логику?
Нет. ERC-1967 стандартизует слоты для совместимых схем, но существуют другие варианты.
Чек-лист: proxy contract и implementation: какой адрес смарт-контракта проверять
- сеть и официальный адрес proxy сверены;
- тип прокси определён;
- актуальная implementation или beacon установлена;
- исходный код реализации проверен;
- права обновления изучены;
- адрес транзакции соответствует назначению.
Материал подготовлен редакцией сайта и проверен 30 сентября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.