ГЛАВНАЯ / ИНСТРУКЦИИ / ADMIN KEY И UPGRADE AUTHORITY: КТО МОЖЕТ ИЗМЕНИТЬ СМАРТ-КОНТРАКТ
Admin key и upgrade authority: кто может изменить смарт-контракт
Административный ключ – условное название доступа к привилегированным действиям. Управляющим может быть обычный адрес, multisig, timelock или другая система контрактов. Для оценки риска нужно установить, кто вправе менять логику и параметры сейчас, а не только кто когда-то создал проект.
Разделите обновление кода и управление параметрами
Смена implementation у обновляемого контракта и изменение комиссии у неизменяемого – разные полномочия. Даже если нельзя заменить логику, отдельный адрес может управлять лимитами, оракулом, выпуском токенов или паузой. Перечень действий нужно получить из реализации, а не из рекламного слова decentralized.
Материал использует примеры EVM. В других сетях и архитектурах понятие upgrade authority проверяется по своим правилам. Не переносите функцию owner() или расположение служебного слота на произвольный контракт только потому, что интерфейс обозревателя выглядит знакомо.
| Право | Что может меняться | Что проверить |
|---|---|---|
| Upgrade | Исполняемая логика | Путь авторизации обновления |
| Параметры | Комиссии, лимиты, адреса зависимостей | Ограничения конкретной функции |
| Pause | Доступность отдельных действий | Роли остановки и возобновления |
| Управление ролями | Получатели других полномочий | Кто назначает и отзывает роли |
У Transparent, UUPS и beacon разные пути контроля
В распространённой Transparent-схеме проверьте административный контракт ProxyAdmin и его управляющего. В UUPS разрешение на обновление обычно определяется логикой реализации, например проверкой в _authorizeUpgrade. Для beacon-подхода важно, кто способен менять implementation у самого beacon: это может повлиять на несколько связанных прокси.
Слоты ERC-1967 помогают установить адрес реализации, beacon или административные сведения у соответствующих прокси. Но одного чтения admin slot недостаточно для любой архитектуры. Сопоставьте версию, исходный код и фактический путь обновления. Пустой слот или отсутствие owner() сами по себе не доказывают отсутствие административного доступа.
- модель прокси подтверждена по коду;
- найдена функция, разрешающая обновление;
- прочитан текущий управляющий адрес;
- контракт администратора исследован отдельно.
Адрес контракта администратора ещё не завершает проверку
Если управляющий – другой контракт, выясните, кто контролирует его. Для multisig это могут быть владельцы, порог и дополнительные пути исполнения; для timelock – роли и порядок изменения конфигурации. Один адрес в поле owner может скрывать несколько уровней управления.
Роли также образуют иерархию: право назначить администратора иногда важнее текущего списка исполнителей. В AccessControl отдельная роль управляет выдачей других ролей, а стандартная DEFAULT_ADMIN_ROLE требует особого внимания. Название роли не заменяет проверку того, какие функции она действительно ограничивает.
RenounceOwnership нужно оценивать в контексте всей системы
Отказ от ownership в обычном Ownable закрывает доступ к действиям, защищённым onlyOwner. Он не обязан отзывать отдельные роли другого контракта, полномочия ProxyAdmin или управление beacon. Проверьте, на каком именно адресе выполнен отказ и какие пути контроля после него остались.
Зафиксируйте сеть, рабочий адрес, реализацию и блок чтения ролей. События передачи прав помогают восстановить историю, но текущую конфигурацию следует подтвердить состоянием и кодом. После обновления или передачи управления прежний вывод нужно перепроверить: снимок полномочий не является бессрочной характеристикой бренда.
- отказ относится к нужному контракту;
- права обновления проверены отдельно;
- сохранены действующие роли и управляющие адреса;
- неизвестные элементы не объявлены отсутствующими;
- после изменений предусмотрена повторная проверка.
Частые вопросы
Admin key – всегда один приватный ключ?
Нет. Полномочия могут принадлежать multisig, timelock или другой системе контрактов.
Owner совпадает с upgrade authority?
Не обязательно. Проверяйте реальную авторизацию функции обновления.
Пустой admin slot доказывает неизменяемость?
Нет. У разных моделей, включая UUPS, различается путь контроля.
RenounceOwnership удаляет все права проекта?
Нет. Он относится к конкретной модели ownership и не заменяет проверку остальных контрактов и ролей.
Можно определить независимость команды по числу адресов?
Нет. Адреса не доказывают, сколько независимых людей контролируют ключи.
Чек-лист: admin key и upgrade authority: кто может изменить смарт-контракт
- рабочий адрес и сеть подтверждены;
- модель обновления установлена;
- реализация и авторизация прочитаны;
- управление администратором прослежено;
- чувствительные роли разделены;
- отказ от ownership не переоценён;
- блок и ограничения проверки сохранены.
Материал подготовлен редакцией сайта и проверен 26 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.