Перейти к содержанию
Financial Context Wiki

Как отслеживать обновления прокси-контрактов

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

Обновлено

Только для образовательных целей; не является инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Отслеживайте не только адрес прокси, но и путь управления обновляемой системой. Оповещение должно показывать, кто может разрешить и выполнить обновление, обязательную задержку, прежнюю и новую реализации и 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: «Проверенный исходный код или прошлый аудит доказывает безопасность обновления». Для точной версии проверьте развернутый байткод, допущения компилятора и конструктора, совместимость хранилища, инициализацию, конфигурацию и поведение.

Связанные темы

Источники

Навигация

Поиск по вики...