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

Что такое прокси-контракт?

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

В криптовалютных системах прокси-контракты главным образом используют для обновления смарт-контрактов без изменения публичного адреса контракта и сохранения его состояния.

Контракт, с которым взаимодействуют пользователи, обычно называют прокси-контрактом или просто прокси.

Контракт, содержащий текущую логику, обычно называют контрактом реализации, логическим контрактом или мастер-копией.

В описании шаблона обновления прокси OpenZeppelin поясняется, что в прокси-системах возможность обновления обеспечивается разделением хранилища данных и логики контракта.

Это разделение важно, поскольку смарт-контракты после развертывания обычно сложно или невозможно изменить.

Если проект развернул обычный контракт, а позднее обнаружил ошибку, команде может потребоваться создать новый контракт по новому адресу.

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

Пользователи, кошельки и приложения продолжают взаимодействовать с адресом прокси, а логика за этим адресом может измениться.

Проще всего понять прокси-контракт так: это постоянный вход, а контракт реализации — заменяемый механизм за ним.

Зачем нужны прокси-контракты

Прокси-контракты появились потому, что неизменность блокчейна одновременно повышает безопасность и создает сложности.

Неизменность полезна: пользователи могут рассчитывать, что развернутый код нельзя тайно отредактировать, как обычное веб-программное обеспечение.

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

Без прокси обновление смарт-контракта часто означает развертывание нового контракта и необходимость перенести в него активы или разрешения пользователей.

Такой перенос может быть дорогим, запутанным, рискованным и неудобным.

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

Это важно для DeFi-протоколов, коллекций NFT, DAO, токенов, мостов, систем стейкинга, игровых активов и кошельков с абстракцией аккаунтов.

Прокси может упростить работу пользователей: интеграциям не нужно менять адреса контрактов после каждого обновления логики.

Кроме того, он может повысить безопасность, поскольку позволяет быстрее развертывать срочные исправления.

Однако возможность обновления предполагает доверие: кто-то или какой-то процесс управления должен иметь право менять контракт реализации.

Как работает прокси-контракт

Прокси-контракт хранит состояние и перенаправляет вызовы функций контракту реализации.

Когда пользователь вызывает прокси, сам прокси обычно не выполняет основную логику приложения.

Вместо этого он перенаправляет вызов контракту реализации с помощью низкоуровневого механизма EVM, например

.

Код реализации выполняется, но изменяются данные в хранилище прокси.

Именно эта особенность позволяет создавать обновляемые прокси-системы.

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

Контракт реализации содержит код, который умеет читать и изменять это состояние.

При обновлении системы развертывается новый контракт реализации с новой логикой.

Затем прокси меняет указатель на контракт реализации.

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

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

— низкоуровневый механизм, на котором основана работа многих прокси-контрактов.

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

При вызове

код вызванного контракта выполняется в контексте хранилища вызывающего контракта.

Для прокси это означает, что код контракта реализации может изменять хранилище самого прокси.

Это дает важные преимущества: прокси сохраняет состояние, но при этом может использовать другой код реализации.

Однако это также опасно: код реализации необходимо писать с учетом структуры хранилища прокси.

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

Если прокси перенаправляет вызовы вредоносному контракту реализации, тот может вывести активы или изменить разрешения.

В предупреждении SWC-112 о delegatecall разработчикам рекомендуют осторожно использовать

и не вызывать ненадежные контракты.

В прокси-системах

— не просто техническая деталь, а ключевой элемент модели безопасности.

Прокси-контракт и контракт реализации

Прокси-контракт и контракт реализации выполняют разные задачи.

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

Контракт реализации содержит функции и правила, определяющие, как меняется это состояние.

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

Когда требуется новая функция, разработчики развертывают новый контракт реализации.

После этого прокси обновляют так, чтобы он указывал на новую реализацию.

Адрес прокси остается прежним, поэтому пользователям и интеграциям не нужно переходить на новый адрес.

Эта модель полезна, но пользователям следует выяснить, кто контролирует обновления.

Если администратор прокси контролируется одним приватным ключом, этот ключ может давать владельцу огромные полномочия над контрактом.

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

Прокси-контракт и обычный смарт-контракт

Обычный смарт-контракт обычно содержит и хранилище данных, и логику в одном контракте.

После развертывания код такого контракта, как правило, остается неизменным.

В прокси-системе хранилище и логика разделены как минимум между двумя контрактами.

Прокси хранит состояние и перенаправляет вызовы.

Контракт реализации содержит логику, которую можно заменить, если механизм обновления это позволяет.

Благодаря этому прокси-система гибче обычного контракта.

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

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

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

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

Прокси-контракт и возможность обновления

Возможность обновления — самая распространенная причина использования прокси-контракта.

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

Это может быть полезно для исправления ошибок, добавления функций, оптимизации газа, новых интеграций, изменений управления или обновления протокола.

Однако возможность обновления меняет модель доверия.

Контракт, который можно обновить, не является полностью неизменным в том же смысле, что и контракт без возможности обновления.

Пользователи рассчитывают, что уполномоченная сторона не станет внедрять вредоносные или небрежно подготовленные изменения.

Право на обновление может принадлежать одному владельцу, кошельку с мультиподписью, DAO, контроллеру с временной задержкой или другому управляющему контракту.

Более безопасные решения делают полномочия по обновлению прозрачными и усложняют их злоупотребление.

Например, временная задержка может дать пользователям возможность вывести средства до вступления крупного обновления в силу.

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

Стандарт прокси ERC-1967

ERC-1967 — широко используемый стандарт слотов хранилища для прокси.

В стандарте ERC-1967 определены конкретные слоты хранилища для данных прокси, например адреса реализации, администратора и beacon-контракта.

Цель стандарта — предотвратить конфликты слотов между прокси и контрактом реализации.

Конфликт хранилища возникает, когда две переменные непреднамеренно используют один и тот же слот.

В прокси-системах это особенно опасно, поскольку хранилище прокси и логика реализации взаимодействуют через

.

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

Благодаря этому прокси-системы проще изучать и проверять.

Во многих распространенных шаблонах обновляемых прокси используются слоты ERC-1967.

Само по себе использование известного стандарта не гарантирует безопасность прокси.

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

Прозрачный прокси

Прозрачный прокси — это шаблон прокси, который разделяет административные вызовы и вызовы пользователей.

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

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

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

В документации OpenZeppelin о прокси контракт

описан как прокси со встроенным администратором и интерфейсом обновления.

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

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

Кроме того, необходимо тщательно управлять администратором прокси.

Если администратор прокси будет скомпрометирован, злоумышленник может заменить контракт на вредоносную реализацию.

Безопасность прозрачного прокси зависит от кода реализации и защиты административных прав.

Прокси UUPS

UUPS означает Universal Upgradeable Proxy Standard — универсальный стандарт обновляемого прокси.

В стандарте ERC-1822 UUPS описана конструкция прокси, в которой совместимость с обновлениями обеспечивается логикой реализации.

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

Это может снизить стоимость развертывания и сложность прокси.

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

При ошибках в контроле доступа злоумышленник может получить возможность обновить систему.

Если новая реализация удалит функцию обновления или нарушит ее работу, повторное обновление прокси может стать затруднительным или невозможным.

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

Прокси UUPS эффективны благодаря гибкости и экономичности.

Они становятся рискованными, если команда не до конца понимает, где находятся полномочия по обновлению.

Beacon-прокси

Beacon-прокси получает адрес реализации от отдельного beacon-контракта.

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

После обновления beacon все использующие его прокси могут начать работать с новой реализацией.

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

Например, фабрика контрактов может создавать множество пользовательских хранилищ, пулов, аккаунтов или контрактов, связанных с NFT, использующих одну и ту же логику.

Beacon-прокси упрощает массовые обновления.

Однако риски также могут возрасти, поскольку одно обновление beacon способно повлиять сразу на множество экземпляров прокси.

Администратора beacon необходимо тщательно защищать.

Пользователям следует выяснить, зависит ли их контракт от beacon: его изменение может повлиять на поведение множества контрактов.

Beacon-прокси эффективны при управлении множеством контрактов, но концентрируют полномочия по обновлению в beacon.

Минимальный прокси и ERC-1167

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

В стандарте минимального прокси ERC-1167 определен шаблон компактного байт-кода для недорогих копий контрактов, перенаправляющих вызовы фиксированной реализации.

Минимальные прокси часто называют клонами.

Они полезны, когда проекту нужно развернуть множество копий одной и той же логики, например кошельки, хранилища, пулы, аккаунты или экземпляры маркетплейса.

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

Это позволяет экономить газ, поскольку полный код реализации не приходится развертывать заново для каждого экземпляра.

Не каждый минимальный прокси можно обновлять.

Многие клоны ERC-1167 указывают на фиксированную реализацию, и заменить ее адрес нельзя, если дополнительная логика обновления не добавлена в другом месте.

Это различие важно: минимальный прокси предназначен для недорогого создания клонов, а обновляемый прокси — для замены логики.

В некоторых системах сочетаются оба подхода, но путать их не следует.

Структура хранилища в прокси-контрактах

Структура хранилища — один из важнейших аспектов проектирования прокси-контрактов.

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

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

Например, отображение балансов можно случайно заменить переменной владельца, а значение настройки — перезаписать новой переменной.

Это может нарушить работу контракта или создать уязвимости.

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

Иногда для резервирования места под будущие переменные используют свободные слоты хранилища.

Проверка структуры хранилища позволяет выявить многие ошибки обновления до развертывания.

Разработчикам следует считать структуру хранилища частью публичной модели безопасности контракта.

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

Инициализация прокси-контрактов

В обновляемых прокси-контрактах вместо конструкторов часто используют функции инициализации.

Конструктор выполняется только при развертывании контракта реализации.

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

Поэтому настройка обычно выполняется через функцию инициализации, вызванную через прокси.

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

Если забыть инициализировать прокси, он может остаться незащищенным.

Если злоумышленник вызовет функцию инициализации первым, он может стать владельцем или администратором.

Если функцию инициализации можно вызвать несколько раз, критически важные настройки могут быть перезаписаны.

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

Ошибки инициализации — одни из самых распространенных и опасных проблем обновляемых контрактов.

Администратор прокси и полномочия по обновлению

Администратор прокси — это аккаунт или контракт, который может обновлять реализацию прокси.

Эти полномочия могут контролироваться одним кошельком, кошельком с мультиподписью, голосованием DAO, контрактом с временной задержкой или управляющим контрактом.

Роль администратора крайне важна, поскольку он может менять код, который управляет активами пользователей.

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

Если административный ключ украдут, злоумышленник может заменить контракт реализации.

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

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

Временная задержка может повысить доверие, поскольку обновление вступает в силу не сразу после объявления.

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

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

Прокси-контракт и обозреватели блокчейна

Обозреватели блокчейна часто помогают пользователям изучать прокси-контракты.

Хороший обозреватель может определить, что адрес принадлежит прокси, и показать адрес текущего контракта реализации.

Если прокси соответствует известному стандарту, например ERC-1967, обозреватель также может показать данные об администраторе.

Это помогает пользователям и аудиторам проверить код, который фактически выполняется.

Если обозреватель не распознает прокси, пользователи могут изучить только байт-код самого прокси и не заметить логику контракта реализации.

Это может создать ложное чувство уверенности, поскольку прокси может содержать лишь небольшую часть видимого кода приложения.

Проверьте, подтвержден ли исходный код контракта реализации.

Также выясните, менялся ли контракт реализации со временем.

Старый аудит может быть неактуален, если прокси обновили и он использует новую логику.

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

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

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

Адрес обновляемого токена может оставаться прежним, даже если меняются правила переводов, комиссии, логика выпуска или сжигания токенов, работа мостов, требования соответствия или функции управления.

Это может быть полезно, если токену требуется со временем адаптироваться.

В то же время это риск: правила, на которые рассчитывают пользователи, могут измениться после покупки или получения токена.

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

Прежде чем считать правила токена постоянными, выясните, можно ли обновлять его контракт.

Также проверьте, кто контролирует обновления и предусматривает ли система управления задержку перед вступлением изменений в силу.

Токен с прокси-контрактом не обязательно является небезопасным.

У него просто иная модель доверия по сравнению с полностью неизменяемым контрактом токена.

Важно выяснить, прозрачно ли организованы полномочия по обновлению и хорошо ли они защищены.

Прокси-контракты и DeFi-протоколы

DeFi-протоколы часто используют прокси-контракты, поскольку финансовым приложениям требуется обслуживание.

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

Прокси-контракты позволяют совершенствовать такие системы, не заставляя каждого пользователя переносить свои позиции.

Это удобно, поскольку позиции в DeFi могут быть сложными и связанными с множеством протоколов.

Однако возможность обновления также создает системные риски.

Неудачное обновление широко используемого контракта DeFi может одновременно затронуть множество пользователей и интеграций.

В обновляемом DeFi-протоколе необходимы надежные тестирование, аудиты, мониторинг, механизмы управления и процедуры на случай чрезвычайных ситуаций.

Не ограничивайтесь вопросом о том, прошел ли протокол аудит.

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

В DeFi прокси-контракты упрощают обслуживание, но повышают важность управления.

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

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

Прокси NFT позволяет проекту добавлять функции уже после запуска.

Если контракт реализации управляет логикой URI токенов, он также может позволить менять поведение метаданных.

Это может быть полезно, если проект развивается от коллекционных предметов к играм, программам членства или цифровым системам идентификации.

Но это может вызвать споры, если коллекционеры рассчитывают на неизменные правила или постоянные метаданные.

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

Также выясните, кто контролирует администратора обновлений.

И полностью неизменяемые NFT, и обновляемые NFT могут быть добросовестными, но они обеспечивают разные гарантии.

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

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

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

DAO могут использовать прокси-контракты для обновления модулей управления, инструментов казначейства, систем голосования, контрактов стейкинга или параметров протокола.

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

Однако управление через DAO само по себе не гарантирует безопасность обновлений.

Низкая активность избирателей, покупка голосов, атаки на систему управления, поспешные предложения или неясные изменения кода все равно создают риски.

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

Участникам DAO следует знать, какие контракты можно обновлять и какими полномочиями обладает система управления.

Если управляющий орган может обновлять контракты казначейства, токенов или основную логику протокола, голосующие несут ответственность за серьезные решения в области безопасности.

Прокси-контракты помогают DAO адаптироваться со временем.

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

Возможность обновления в DAO должна быть заметной, документированной и тщательно контролироваться.

Преимущества прокси-контрактов

Первое преимущество прокси-контракта — возможность обновления.

Проекты могут исправлять ошибки, добавлять функции и улучшать логику, не меняя основной адрес контракта.

Второе преимущество — сохранение состояния.

Балансы, позиции, разрешения и настройки пользователей могут оставаться в прокси при смене логики реализации.

Третье преимущество — стабильность интеграций.

Кошельки, dApp, индексаторы и другие контракты могут продолжать использовать тот же адрес.

Четвертое преимущество — упрощение переноса.

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

Пятое преимущество — снижение затрат на газ при использовании клонов.

Минимальные прокси позволяют дешевле развертывать множество похожих контрактов, чем повторно размещать полный код для каждого из них.

Шестое преимущество — модульная архитектура.

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

Эти преимущества полезны только в том случае, если прокси-контракты тщательно спроектированы, проверены аудитом, находятся под надлежащим управлением и мониторингом.

Риски прокси-контрактов

Первый риск — вредоносные обновления.

Если полномочия по обновлению будут скомпрометированы или использованы недобросовестно, безопасную логику могут заменить вредоносной.

Второй риск — конфликт хранилища.

Ошибки в структуре хранилища при обновлении могут повредить важное состояние контракта.

Третий риск — ошибка инициализации.

Злоумышленник может захватить неинициализированный прокси или контракт реализации.

Четвертый риск — конфликт селекторов функций.

При неудачной архитектуре функции администратора прокси и функции реализации могут конфликтовать.

Пятый риск — несоответствие аудиту.

Контракт мог пройти аудит раньше, но его текущая реализация может отличаться от проверенной версии.

Шестой риск — скрытая сложность.

Пользователи могут не понимать, что взаимодействуют с прокси, а не с простым неизменяемым контрактом.

Седьмой риск — захват управления.

Злоумышленник может повлиять на процесс обновления с помощью голосов, доступа администратора или социальной инженерии.

Восьмой риск — неправильное отображение данных инструментами.

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

Как проверить прокси-контракт перед взаимодействием

Сначала проверьте, помечен ли адрес контракта как прокси в обозревателе блокчейна.

Найдите адрес текущей реализации.

Убедитесь, что исходный код контракта реализации опубликован и проверен.

Проверьте, менялся ли контракт реализации недавно.

Выясните, кто контролирует администратора прокси или полномочия по обновлению.

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

Сопоставьте даты аудитов с датами развертывания контрактов реализации.

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

Не считайте контракт неизменяемым только потому, что адрес прокси не менялся.

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

Рекомендации для разработчиков

Используйте хорошо проверенные платформы и инструменты для работы с прокси, а не пишите собственную логику прокси без экспертной проверки.

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

Защищайте функции обновления с помощью надежного контроля доступа.

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

Тщательно реализуйте функции инициализации и исключите возможность повторной инициализации.

Перед каждым обновлением проверяйте структуру хранилища.

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

Проверяйте исходный код контрактов реализации в обозревателях блокчейна.

Перед крупными изменениями публикуйте объявления об обновлениях, аудиты и технические пояснения.

Отслеживайте события обновления и будьте готовы быстро отреагировать, если обновление завершится с ошибкой.

Рекомендации для пользователей

Помните, что обновляемый прокси — это не то же самое, что полностью неизменяемый смарт-контракт.

Прежде чем вносить значительные средства, выясните, кто может обновлять прокси.

Проверьте, предусматривается ли задержка при обновлении.

Убедитесь, что последняя реализация подтверждена и прошла аудит.

Будьте осторожны, если администратором прокси управляет один неизвестный кошелек.

Если вы держите крупные позиции в протоколах, следите за событиями обновления.

Не выдавайте обновляемым контрактам неограниченные разрешения на использование токенов, если не понимаете связанные с этим риски.

После использования протокола отзывайте ненужные разрешения.

Помните, что обновление может изменить дальнейшую работу контракта, даже если раньше он работал безопасно.

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

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

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

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

Другое заблуждение — считать, что прокси автоматически безопасен, если он создан с помощью популярного инструментария.

Даже стандартный прокси может быть опасным, если контракт реализации вредоносен или администратор скомпрометирован.

Также ошибочно считать, что адрес прокси содержит всю необходимую для проверки логику.

На самом деле важная логика приложения часто находится в контракте реализации.

Еще одно заблуждение — думать, что аудит всегда охватывает текущую версию кода.

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

Также неверно считать, что минимальные прокси всегда можно обновлять.

Многие минимальные прокси — это лишь недорогие клоны, перенаправляющие вызовы к фиксированной логике.

FAQ

Что означает термин «прокси-контракт»?

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

Зачем криптовалютные проекты используют прокси-контракты?

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

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

Многие прокси-контракты можно обновлять, но не все: например, некоторые минимальные прокси указывают на фиксированную логику.

Что такое контракт реализации?

Контракт реализации содержит логику, которая выполняется через прокси посредством перенаправления вызовов или

.

Что такое delegatecall в прокси-контракте?

— операция EVM, которая позволяет прокси выполнять код контракта реализации, используя собственный контекст хранилища.

Что такое ERC-1967?

ERC-1967 — стандарт, определяющий конкретные слоты хранилища для данных прокси, например адресов реализации, администратора и beacon-контракта.

Что такое прозрачный прокси?

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

Что такое прокси UUPS?

Прокси UUPS — это шаблон обновляемого прокси, в котором логика обновления находится преимущественно в контракте реализации, а не в самом прокси.

Что такое beacon-прокси?

Beacon-прокси получает адрес реализации от beacon-контракта. Изменение beacon позволяет одновременно обновлять множество прокси.

Что такое минимальный прокси?

Минимальный прокси — это небольшой контракт-клон, часто основанный на ERC-1167, который перенаправляет вызовы к общей логике реализации и снижает стоимость развертывания.

Связаны ли прокси-контракты с рисками?

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

Как проверить, является ли контракт прокси?

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

Заключение

Прокси-контракт — это шаблон смарт-контракта, который отделяет адрес для взаимодействия с пользователями и хранимое состояние от логики, определяющей работу контракта.

В криптовалютных системах этот шаблон широко распространен: он позволяет обновлять смарт-контракты, не заставляя пользователей и интеграции переходить на новый адрес.

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

.

Такие стандарты, как ERC-1967, ERC-1822 и ERC-1167, помогают организовать распространенные архитектуры прокси, включая прозрачные прокси, UUPS-прокси, beacon-прокси и минимальные прокси.

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

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

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

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

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

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