КриптоЛампа
Обновляемый токен proxy: что проверить без подписи кошелька
Как отличить адрес токена от реализации, найти полномочия обновления и понять границы проверки опубликованного кода и административных ролей.
Сверены открытые первичные документы по механике и ограничениям. Кошелёк не подключался, действия в текущем интерфейсе и операции с реальными средствами не проверялись. Числа в примерах условные.
Один адрес может использовать меняющуюся логику
В proxy-модели пользователь взаимодействует с контрактом-посредником, а логика выполняется через связанную реализацию. При обновлении ссылка на реализацию может измениться, сохраняя привычный адрес входа. Поэтому проверенный когда-то код токена не всегда описывает его нынешнюю логику.
Не каждый proxy автоматически обновляем. OpenZeppelin описывает разные схемы, включая Transparent, UUPS и beacon. Название proxy в обозревателе — начало проверки, а не готовый вывод о полномочиях администратора или безопасности актива.
Что можно прочитать публично
Сначала сверяйте адрес токена и сеть с официальным источником. Затем найдите в обозревателе сведения о proxy и связанной реализации. Проверьте, опубликован ли код обеих частей и как определяется право обновления. Для beacon может требоваться отдельная проверка адреса маяка.
- Запишите proxy, implementation и связанные управляющие адреса.
- Посмотрите события обновлений и время последней смены логики.
- Уточните, кто контролирует административные роли.
- Найдите описание multisig, timelock или управления, если они заявлены.
Как интерпретировать результат
Условный пример: аудит относится к реализации А, но сейчас proxy указывает на Б. Наличие отчёта не доказывает, что версия Б проверена в том же объёме. Нужна связь между отчётом, коммитом и развёрнутым кодом. Совпадение названия проекта этого пробела не закрывает.
Timelock может давать время до выполнения изменения, но не доказывает, что любое запланированное действие безопасно. Multisig меняет модель контроля, однако число подписантов без знания порога и независимости участников мало что объясняет. Зафиксируйте неизвестные элементы, не заменяя их догадкой.
Граница такой проверки
Публичное чтение не требует approve, подключения кошелька или «активации проверки». Если сайт просит подпись ради просмотра реализации, используйте официальный обозреватель и документацию. Не вызывайте функции записи для эксперимента с правами администратора.
Даже подробная карта ролей не является полным аудитом. Она отвечает на более узкий вопрос: что сейчас исполняется и кто может изменить это поведение. При будущей операции сведения нужно сверять заново, особенно после сообщения об обновлении. Итог записи должен содержать адреса, время и неподтверждённые части, чтобы вывод оставался проверяемым, а не превращался в вечный ярлык «контракт безопасен».
