---
title: "Как отслеживать обновления прокси-контрактов"
description: "Отслеживайте изменения реализации, маяка и управления обновляемыми прокси, а после исполнения проверяйте код, совместимость хранилища, инициализацию, права и критическое поведение."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Как отслеживать обновления прокси-контрактов
> Только для образовательных целей; не является инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Отслеживайте не только адрес прокси, но и путь управления обновляемой системой. Оповещение должно показывать, кто может разрешить и выполнить обновление, обязательную задержку, прежнюю и новую реализации и calldata инициализации. После исполнения независимо прочитайте конфигурацию в блокчейне и проверьте критическое поведение.
Адрес прокси и его балансы могут остаться прежними, хотя делегированный код изменит права, комиссии, учет, приостановку или логику вывода. Предыдущий аудит не распространяется автоматически на новую реализацию и ее инициализацию.
## Как это работает
Сначала определите тип прокси. ERC-1967 задает отдельные слоты хранения для `eip1967.proxy.implementation`, `eip1967.proxy.beacon` и необязательного `eip1967.proxy.admin`. Прямая смена реализации должна создавать событие `Upgraded`, смена адреса маяка — `BeaconUpgraded`, а смена слота администратора — `AdminChanged`. Для прокси с маяком также вызывайте `implementation()` маяка: он может сменить реализацию, хотя слот маяка в прокси останется прежним.
Не выводите полную модель полномочий только из слота администратора. Прокси Transparent может управляться через `ProxyAdmin`, а разрешение обновлений UUPS реализовано в текущем контракте логики через `_authorizeUpgrade`. Проследите владельцев, роли, пороги мультиподписи, таймлоки, контракты управления, аварийные пути и право менять эти средства контроля.
Используйте подписки на события вместе с периодическим чтением состояния. ERC-1967 рекомендует события, но не требует от каждой реализации их создавать. Через независимые RPC зафиксируйте сеть, блок, транзакцию, прокси, реализацию или маяк, хеш исполняемого кода, исполнителя и связанное состояние управления. Оповещайте о запланированных, отмененных и исполненных операциях и дождитесь принятой для сети политики подтверждения или финальности, прежде чем считать состояние окончательным.
## Пример
Прокси протокола кредитования управляется мультиподписью 3 из 5 через таймлок на 24 часа. При планировании обновления система мониторинга записывает идентификатор предложения, цель, calldata, самое раннее время исполнения, текущую и предлагаемую реализации и статус проверки исходного кода. Проверяющие сравнивают код и схемы хранения, изучают вызов инициализации и проверяют изменения ролей, внешних вызовов, комиссий, правил приостановки и путей вывода.
После исполнения система снова читает нужный слот ERC-1967, проверяет развернутый исполняемый код и ожидаемые постусловия: версию реализации, администраторов или владельцев ролей, статус приостановки, учет активов и доступный только для чтения предварительный расчет вывода. Повторное оповещение срабатывает, если наблюдаемый адрес или хеш кода отличается от проверенного предложения либо периодический опрос обнаруживает изменение без события.
## Риски
- **Риск управления:** Формальную мультиподпись может обойти другой владелец, роль, модуль, контракт управления, аварийный ключ или изменяемый таймлок. Проследите каждый путь до конечных подписантов и задержки.
- **Риск кода и хранения:** Непроверенный код, несовместимые схемы хранения, небезопасная инициализация или измененная зависимость могут повредить состояние или предоставить непредусмотренные права. Проверяйте точно развернутый артефакт, а не только ветку репозитория или название аудита.
- **Риск мониторинга:** Единственный RPC, индексатор только событий, интерфейс или обозреватель блоков может запаздывать или ошибаться. Сверяйте события, хранилище, байткод, квитанции транзакций и состояние протокола по независимым источникам.
- **Риск реагирования:** Оповещение без ответственного и проверенной процедуры может прийти слишком поздно. Определите, кто во время задержки проверяет, приостанавливает интеграции, сообщает или выходит, и учитывайте дополнительный риск поспешных подтверждений и неофициальных ссылок восстановления.
Минимальный регламент:
1. Учтите каждый прокси, маяк, реализацию, администратора, роль и точку входа обновления в каждой сети.
2. Сохраните заведомо исправную базовую линию слотов, хешей кода, состояния управления и критических результатов только для чтения.
3. Оповещайте до исполнения, если это позволяет планирование управления или таймлока, и повторно при исполнении или отмене.
4. Сравните фактически исполненные цель, calldata, реализацию, байткод, схему хранения и состояние после обновления с проверенным предложением.
5. Эскалируйте неожиданные изменения, невыполненные постусловия, отсутствие проверки исходного кода, сокращенную или обойденную задержку; не считайте неизменный адрес прокси доказательством безопасности.
## Распространенные заблуждения
- **Миф 1: «Достаточно следить за `Upgraded`».** Смена реализации маяка и нестандартные прокси могут потребовать мониторинга другого контракта или опроса состояния; сверяйте события с прямым чтением.
- **Миф 2: «Слот администратора показывает, кто контролирует любое обновление».** Слот необязателен, а схемы Transparent, UUPS, маяка, управления и собственные решения размещают полномочия в разных контрактах и функциях.
- **Миф 3: «Проверенный исходный код или прошлый аудит доказывает безопасность обновления».** Для точной версии проверьте развернутый байткод, допущения компилятора и конструктора, совместимость хранилища, инициализацию, конфигурацию и поведение.
## Связанные темы
- [Риск модулей мультиподписи](/ru/crypto/multisig-module-risk/)
- [Прокси-контракт](/ru/crypto/proxy-contract/)
- [Коллизия хранилища прокси](/ru/crypto/proxy-storage-collision/)
- [Аварийная приостановка протокола](/ru/crypto/protocol-emergency-pause/)
- [Обновляемый контракт](/ru/crypto/upgradeable-contract/)
## Источники
- [ERC-1967: слоты хранения прокси](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (дата обращения: 2026-08-21)
- [Прокси](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (дата обращения: 2026-08-21)
- [Разработка обновляемых контрактов](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (дата обращения: 2026-08-21)
- [Управление доступом](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (дата обращения: 2026-08-21)
Source: https://wiki.fcontext.com/ru/crypto/proxy-upgrade-monitoring/index.mdx