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

Прокси-контракт

Прокси-контракт перенаправляет вызовы коду реализации, сохраняя адрес и состояние прокси. Узнайте, как работают прокси и где возникают риски обновления, хранения и администрирования.

Обновлено

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

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

Прокси-контракт — это промежуточный контракт, который перенаправляет вызовы другому контракту, обычно называемому контрактом реализации или логики. В распространённой архитектуре EVM прокси использует delegatecall, поэтому код реализации исполняется в контексте прокси, а состояние и балансы остаются по адресу прокси.

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

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

Как это работает

Когда вызов поступает в прокси, резервный маршрут копирует или перенаправляет данные вызова реализации. При delegatecall значением address(this) является прокси, чтение и запись хранилища затрагивают прокси, а исходные msg.sender и msg.value сохраняются. Затем прокси возвращает данные реализации или откатывает вызов вместе с ней.

Поскольку метаданные прокси делят его пространство хранения с состоянием приложения, стандартизированные слоты помогают избежать случайных коллизий. ERC-1967 определяет слоты для адреса реализации, адреса маяка и необязательного администратора, а также рекомендует события при изменении этих значений. Стандарт упрощает проверку прокси, но сам по себе не делает обновление безопасным.

В распространённых схемах полномочия на обновление находятся в разных местах:

  • Прозрачный прокси: прокси отличает административные вызовы от обычных пользовательских, как правило, с помощью отдельного контракта администратора.
  • UUPS-прокси: логика обновления находится в реализации, которая должна авторизовать изменения и сохранять совместимость с ожидаемым интерфейсом обновления.
  • Прокси с маяком: прокси запрашивает реализацию у маяка; изменение одного маяка может затронуть все следующие за ним прокси.
  • Минимальный клон: множество небольших прокси делегируют общему коду, часто вообще без возможности обновления.

Пример

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

Позднее управление меняет слот реализации ERC-1967 на реализацию B. Адрес прокси и записанные балансы не перемещаются, но последующие вызовы исполняют код B. Если B сохраняет структуру хранения и реализует задуманные правила, пользователи получают новое поведение по тому же адресу.

Если B меняет порядок переменных хранения, пропускает проверку полномочий или добавляет контролируемый инициатором обновления путь вывода, то это же обновление может нарушить учёт или подвергнуть активы риску. Поэтому важно не только установить, что контракт является прокси, но и выяснить, кто, с какой задержкой и после какой проверки может изменить путь исполнения.

Риски

  • Компрометация ключа обновления: администратор, мультиподпись или процесс управления могут установить вредоносный либо дефектный код.
  • Несовместимость структуры хранения: изменение порядка, типов или наследования переменных может заставить новый код неправильно читать или перезаписывать существующее состояние.
  • Ошибка инициализации: конструкторы не инициализируют хранилище прокси; отсутствующая или повторно используемая защита может позволить другому аккаунту получить привилегированные роли.
  • Неожиданная маршрутизация вызовов: коллизии селекторов, отдельный маршрут администратора или неожиданный маяк могут сделать фактический путь исполнения отличным от видимого интерфейса.
  • Широкая область воздействия общего обновления: одно решение по маяку или реализации может одновременно изменить множество экземпляров контрактов.

До внесения активов или выдачи разрешений определите в блокчейне текущую реализацию или маяк, полномочия на обновление и таймлок, изучите проверенный исходный код и совместимость хранилища, а при необходимости проверьте недавние события Upgraded, BeaconUpgraded и AdminChanged. После первой проверки мониторинг по-прежнему необходим, поскольку путь исполнения может измениться.

Распространённые заблуждения

  • «Прокси не хранит значимого состояния». При delegatecall состояние приложения и зачастую активы принадлежат прокси, хотя логика поступает с другого адреса.
  • «Проверенная реализация делает систему не требующей доверия». Ключи обновления, управление, маяки, инициализация и будущие реализации остаются частью модели доверия.
  • «Любой прокси можно обновить». Клоны и другие фиксированные прокси могут делегировать постоянно; обновляемость зависит от конкретной архитектуры и кода авторизации.

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

Источники

Навигация

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