Только в образовательных целях; не является инвестиционной рекомендацией или советом по безопасности. Право обновления позволяет привилегированным лицам менять поведение контракта и может привести к убыткам.
Краткий ответ
Обновляемый смарт-контракт меняет действующую логику без нового основного адреса и потери состояния. Обычно прокси хранит состояние и через delegatecall исполняет код реализации. Обновление меняет реализацию, сохраняя адрес, хранилище и баланс прокси.
Это не перезапись неизменяемого байткода, а дополнительный уровень косвенности. Он помогает исправлять ошибки, но создаёт привилегированный путь для изменения выводов, комиссий, прав и учёта. Важны текущий код и правила выбора будущего кода.
Не каждый прокси обновляем. Возможны миграция в новый контракт или окончательное отключение обновлений; решающими остаются фактическая архитектура и полномочия в сети.
Как это работает
Прокси читает адрес реализации и через delegatecall выполняет её код в своём хранилище. ERC-1967 стандартизирует слоты реализации, Beacon и администратора. Transparent-прокси разделяет вызовы администратора и пользователей; UUPS хранит логику обновления в реализации и использует ERC-1822; один Beacon может менять много прокси.
Перестановка, удаление или смена типа переменных и изменение наследования могут повредить состояние. Добавление только в конец, резервные промежутки и пространства имён ERC-7201 помогают, но требуют межверсионной проверки.
Конструктор не инициализирует хранилище прокси, поэтому initialize вызывают один раз. Прямую инициализацию реализации блокируют, а миграции ограничивают.
Надёжный процесс:
- Зафиксировать исходники, компилятор, зависимости, схемы хранения, адреса и ожидаемый байткод обеих реализаций.
- Проверить изменения, совместимость, миграцию, полномочия, зависимости и откат; испытать всю транзакцию на форке.
- Опубликовать предложение и адрес, применив заявленные multisig, управление и timelock без скрытого обхода.
- После исполнения проверить слот реализации или Beacon, события, байткод, состояние, роли и инварианты на записанном блоке.
- Отслеживать слоты, роли и параметры и не считать откат всегда безопасным.
Пример
Прокси кредитного протокола использует реализацию A. Команда развёртывает B, которая лишь добавляет хранилище, публикует байткод и ставит обновление за timelock на 48 часов. После выполнения тот же адрес использует B, а балансы остаются в прокси.
Пользователь проверяет переход слота с A на B, однократную миграцию, роли и балансы. Возможность хранителя обойти timelock или подписанта заменить B произвольным кодом входит в реальную модель доверия.
Риски
- Привилегированная замена: администратор, multisig, governor или украденный ключ могут установить вредоносный код.
- Повреждение хранения: несовместимая схема искажает балансы, владельцев, mapping или учёт.
- Ошибка инициализации: пропущенная, повторная или открытая инициализация передаёт контроль.
- Особенности схемы: Transparent, UUPS, Beacon и собственные прокси ломаются по-разному.
- Имитация управления: возможны аварийный обход, короткая задержка, концентрация голосов или слабые подписанты.
- Опасная миграция или откат: необратимое состояние может потерять прежний смысл.
- Пробел проверки: проверенный исходник не доказывает цель прокси, администратора и начальное состояние.
- Риск мониторинга: сервисы могут следить за старой реализацией или пропустить смену Beacon.
Заблуждения
- «Контракт по адресу неизменяем». Байткод прокси может быть неизменным, но слот реализации или Beacon меняет поведение.
- «Multisig децентрализует обновления». Это зависит от независимости подписантов, порога, операций и замены.
- «Timelock блокирует вредоносное обновление». Он лишь даёт время наблюдать и выйти.
- «Проверка хранения доказывает безопасность». Она не проверяет логику, полномочия, оракулы, миграцию и экономику.
- «Отказ от обновлений всегда убирает контроль». Проверяют администратора, Beacon, governor, UUPS и альтернативные пути.
Связанные темы
Источники
- ERC-1967: Proxy Storage Slots - Ethereum Improvement Proposals (проверено: 2026-08-22)
- ERC-1822: Universal Upgradeable Proxy Standard (UUPS) - Ethereum Improvement Proposals (проверено: 2026-08-22)
- ERC-7201: Namespaced Storage Layout - Ethereum Improvement Proposals (проверено: 2026-08-22)
- Proxy Upgrade Pattern - OpenZeppelin Docs (проверено: 2026-08-22)
- Writing Upgradeable Contracts - OpenZeppelin Docs (проверено: 2026-08-22)
- Proxy - OpenZeppelin Docs (проверено: 2026-08-22)
- Layout of State Variables in Storage and Transient Storage - Solidity Documentation (проверено: 2026-08-22)