Кальтер / Блог

Как проверить proxy-контракт и полномочия его администратора

Сверь сеть, implementation/beacon/admin slots и фактический upgrade path, не считая одного storage slot полным аудитом.

Материал подготовлен с помощью ИИ. Источники, учебные примеры и расчёты проверены редакцией перед публикацией.

Условные уровни проверки proxy по EIP-1967; значения слотов и фактические полномочия нужно сверять в сети.
Условные уровни проверки proxy по EIP-1967; значения слотов и фактические полномочия нужно сверять в сети.

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

Пройди адреса в правильной сети

Сначала найди адрес и сеть, затем проверь, что обозреватель действительно распознаёт прокси. ERC-1967 описывает отдельные storage slots для implementation, beacon и optional admin; implementation slot указывает на делегируемую логику, а beacon может вернуть текущую implementation. Стандарт рекомендует события при изменении слотов (ERC-1967). Это стандартный паттерн: не каждый прокси ему следует.

Заполни карту:

Элемент Что проверить Что остаётся неизвестным
Proxy address сеть и точный контракт совпадает ли адрес с тем, с которым работает приложение
Implementation slot текущий адрес логики соответствует ли verified source именно bytecode
Beacon slot задан ли beacon вместо implementation меняется ли implementation через beacon
Admin slot заполнен ли optional admin slot есть ли другие роли/механизмы обновления
Upgrade path функции, роли, timelock, multisig весь ли контроль раскрыт и актуален

Если слот пустой, это не всегда означает «контракт неизменяемый»: механизм может быть другой, или паттерн не ERC-1967. Если admin-адрес задан, это не доказывает злонамеренность. Установи, кто контролирует адрес и какие функции реально доступны.

Пример разбора без реального контракта

Учебный снимок показывает proxy 0x…P, implementation 0x…I, admin slot 0x…A и событие Upgraded в истории. Осторожный вывод: «В этом снимке прокси указывает на implementation I, а admin slot содержит A; перед оценкой обновляемости надо проверить исходники обоих контрактов, код управления A и события с момента снимка». Нельзя заключить, что контракт безопасен, потому что source verified, или вредоносен только из-за наличия admin.

ИИ может оформить данные:

Разложи снимок по proxy, implementation, beacon и admin.
Не называй код проверенным или безопасным по одному полю обозревателя.
Для каждого вывода укажи, какой слот/событие его поддерживает и что ещё неизвестно.
Если это не ERC-1967-паттерн или данные неполные, скажи об этом.
Сеть, адрес, дата снимка и слоты: [..]

Перед любым решением проверь также роли, multisig и timelock, если они есть; один admin slot не показывает полный набор путей к изменению состояния. Для базовых понятий смотри руководство по смарт-контрактам, а общие риски протокольных контрактов разобраны в материале о рисках DeFi. Это справочные шаги, не аудит и не финансовый совет.