Proxy-контракт и admin keys: проверка апгрейда

Один адрес принимает вызов, другой поставляет код

Путь обычной операции через proxy

1. Transaction
Пользователь вызывает proxy
Кошелёк отправляет calldata и value на знакомый адрес приложения.
2. Fallback
Proxy находит implementation
Адрес логики читается из предусмотренного pattern слота либо через beacon.
3. Delegatecall
Логика исполняется в контексте proxy
Код implementation работает с storage proxy; исходный msg.sender сохраняется для вызываемой логики.
4. Return
Proxy возвращает результат
Для интерфейса операция выглядит как ответ того же стабильного адреса.

Обычный смарт-контракт связывает address с неизменяемым bytecode. Proxy pattern добавляет косвенность: код самого proxy не переписывают, зато меняют адрес, к которому он делегирует вызовы. Token balances, roles и параметры обычно остаются в storage proxy, поэтому смена логики не требует переносить их на новый пользовательский адрес.

Где находится право апгрейда в распространённых схемах
Схема	Где upgrade logic	Кто обычно авторизует	Особенность проверки
Transparent	Proxy и ProxyAdmin	Owner ProxyAdmin	Admin не проходит через fallback как обычный пользователь
UUPS	В implementation	_authorizeUpgrade в логике	Новая версия должна сохранять upgrade compatibility
Beacon	UpgradeableBeacon	Owner beacon	Один beacon может переключить implementation для многих proxies
Minimal clone	Fixed target в clone bytecode	Апгрейд не является свойством ERC-1167 clone	Не путать дешёвый delegate proxy с upgradeable proxy

Где находится право апгрейда в распространённых схемах

Схема: Transparent
Где upgrade logic: Proxy и ProxyAdmin
Кто обычно авторизует: Owner ProxyAdmin
Особенность проверки: Admin не проходит через fallback как обычный пользователь

Схема: UUPS
Где upgrade logic: В implementation
Кто обычно авторизует: _authorizeUpgrade в логике
Особенность проверки: Новая версия должна сохранять upgrade compatibility

Схема: Beacon
Где upgrade logic: UpgradeableBeacon
Кто обычно авторизует: Owner beacon
Особенность проверки: Один beacon может переключить implementation для многих proxies

Схема: Minimal clone
Где upgrade logic: Fixed target в clone bytecode
Кто обычно авторизует: Апгрейд не является свойством ERC-1167 clone
Особенность проверки: Не путать дешёвый delegate proxy с upgradeable proxy

Explorer label нужно подтвердить storage и событиями

ERC-1967 задаёт отдельные storage slots для implementation, beacon и admin, выбранные так, чтобы не пересекаться с обычной compiler layout. Совместимый explorer может показать их автоматически, но проверяемым источником остаётся значение storage на конкретном block. Для beacon сначала читают beacon address, затем вызывают его implementation() и отдельно находят owner.

Минимальный паспорт upgradeability

chain, proxy address и block number проверки;
текущая implementation либо beacon и bytecode каждого адреса;
тип proxy pattern и функция, которая действительно меняет target;
admin, owner, role members, multisig threshold и signers;
timelock delay, proposer, executor, guardian или emergency path;
последние Upgraded, BeaconUpgraded и AdminChanged events;
ссылка на verified source и audit именно текущей версии.

RPC-узел позволяет получить storage и logs, но ответ одного endpoint не превращает label интерфейса в истину. Для важного решения полезно повторить eth_getStorageAt через независимый provider и убедиться, что block hash совпадает. Если implementation неизвестна или source не соответствует bytecode, область непроверенного кода нужно обозначить прямо.

Admin address важен меньше, чем полный маршрут полномочия

Одинаковое право upgrade может иметь разную операционную защиту
Контроль	Что снижает риск	Что остаётся проверить
Один EOA	Hardware signer и строгая процедура	Компрометация одного ключа и отсутствие on-chain задержки
Multisig	Несколько независимых approvals	Threshold, фактическая независимость signers и modules
Timelock	Публичное окно до исполнения	Кто может cancel, изменить delay или обойти очередь
DAO	Публичный proposal и vote	Quorum, delegation, executor и emergency roles
Неапгрейдный контракт	Нет пути сменить implementation	Другие privileged roles, pause и миграционный front end

Одинаковое право upgrade может иметь разную операционную защиту

Контроль: Один EOA
Что снижает риск: Hardware signer и строгая процедура
Что остаётся проверить: Компрометация одного ключа и отсутствие on-chain задержки

Контроль: Multisig
Что снижает риск: Несколько независимых approvals
Что остаётся проверить: Threshold, фактическая независимость signers и modules

Контроль: Timelock
Что снижает риск: Публичное окно до исполнения
Что остаётся проверить: Кто может cancel, изменить delay или обойти очередь

Контроль: DAO
Что снижает риск: Публичный proposal и vote
Что остаётся проверить: Quorum, delegation, executor и emergency roles

Контроль: Неапгрейдный контракт
Что снижает риск: Нет пути сменить implementation
Что остаётся проверить: Другие privileged roles, pause и миграционный front end

DAO-голосование полезно только если proposal payload действительно достигает upgrade function. Иногда vote является сигналом, а финальную transaction подписывает отдельный multisig. В другом дизайне timelock исполняет exact calldata после задержки. Формулировка «управляется DAO» без executor path не описывает границу доверия.

Ошибочный апгрейд способен повредить данные, даже если доступ легитимен

При delegatecall новая логика читает старое storage. Если разработчик поменял порядок переменных или их типы без совместимой миграции, прежние значения могут интерпретироваться иначе. OpenZeppelin отдельно предупреждает: constructor logic не инициализирует proxy, поэтому setup переносят в защищённый initializer; повторно доступный initializer способен выдать роли постороннему адресу.

Сравнить storage layout текущей и новой реализации, включая inheritance.
Проверить initializer и reinitializer: кто вызывает, один ли раз и в той ли transaction.
Прочитать upgrade-and-call calldata: смена target и настройка state могут происходить атомарно.
Убедиться, что новая implementation не ломает upgrade path и ожидаемые interfaces.
Заранее определить rollback: новый upgrade, pause, migration или отсутствие доступного восстановления.

Перед подписью взаимодействия важно понять, что подписывает кошелёк сегодня и какой код исполнит transaction. После апгрейда повторяют allowance, roles, paused state и критические limits: стабильный proxy address не означает стабильные правила. Проверяемый итог — implementation и admin path на указанном block, а не зелёная галочка возле одного контракта.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

OpenZeppelin Upgrades — Proxy Upgrade Pattern OpenZeppelin · Проверено 18 августа 2026 г. в 22:31 GMT+5
OpenZeppelin Contracts 5.x — Proxy API OpenZeppelin · Проверено 18 августа 2026 г. в 22:31 GMT+5
ERC-1967: Proxy Storage Slots Ethereum Improvement Proposals · Проверено 18 августа 2026 г. в 22:31 GMT+5
ERC-1822: Universal Upgradeable Proxy Standard Ethereum Improvement Proposals · Проверено 18 августа 2026 г. в 22:31 GMT+5
OpenZeppelin Upgrades — Writing Upgradeable Contracts OpenZeppelin · Проверено 18 августа 2026 г. в 22:31 GMT+5

Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.