Обновляемый контракт

Что такое обновляемый контракт?

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

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

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

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

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

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

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

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

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

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

Как работают обновляемые контракты

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

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

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

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

для выполнения кода контракта реализации.

При использовании

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Паттерн прокси

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

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

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

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

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

Эта архитектура подробно описана в документации Ethereum по обновлению смарт-контрактов.

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

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

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

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

Контракт реализации

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

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

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

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

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

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

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

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

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

Структура хранилища

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

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

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

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

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

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

Документация Solidity по структуре хранилища объясняет, как Solidity организует переменные состояния в постоянном хранилище.

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

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

Слоты хранилища прокси ERC-1967

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

Цель ERC-1967 — уменьшить коллизии хранилища между прокси и контрактом реализации.

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

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

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

Официальная спецификация ERC-1967 определяет эти соглашения о слотах хранилища прокси.

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

Для разработчиков ERC-1967 предоставляет более безопасный и стандартизированный способ хранения метаданных прокси.

Хранилище с пространствами имен ERC-7201

ERC-7201 — новый стандарт структуры хранилища с пространствами имен в смарт-контрактах.

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

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

OpenZeppelin Contracts 5.x использует паттерны обновляемых контрактов, которые включают пространства имен хранилища в стиле ERC-7201 в обновляемых вариантах.

Официальная спецификация ERC-7201 описывает соглашение по документированию расположений хранилища с пространствами имен в исходном коде Solidity.

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

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

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

Инициализаторы вместо конструкторов

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

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

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

.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прокси UUPS

UUPS означает Universal Upgradeable Proxy Standard.

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

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

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

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

Прокси UUPS популярны, но требуют тщательного контроля доступа и тестирования.

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

Beacon-прокси

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

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

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

Главное преимущество — операционная эффективность, поскольку одно обновление beacon может обновить множество прокси.

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

Владение beacon и разрешения на обновление должны быть защищены надежным управлением и мониторингом.

Паттерн Diamond

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

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

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

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

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

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

Преимущества обновляемых контрактов

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

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

Второе преимущество — расширение функциональности.

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

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

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

Четвертое преимущество — пользовательский опыт.

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

Пятое преимущество — экстренное реагирование.

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

Риски обновляемых контрактов

Крупнейший риск обновляемого контракта — злоупотребление правами администратора.

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

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

Другой существенный риск — повреждение хранилища.

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

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

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

Четвертый риск — недостаточный мониторинг.

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

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

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

Как пользователи могут оценить обновляемый контракт

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

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

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

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

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

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

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

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

Лучшие практики для разработчиков

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

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

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

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

Следует защищать инициализаторы и избегать незащищенных функций настройки.

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

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

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

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

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

Обновляемый контракт и неизменяемый контракт

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

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

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

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

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

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

Ни одна из этих архитектур не всегда лучше другой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третье заблуждение — что аудиты устраняют риск обновления.

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

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

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

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

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

FAQ

Что такое обновляемый контракт в криптоиндустрии?

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

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

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

Безопасны ли обновляемые контракты?

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

Каков главный риск обновляемого контракта?

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

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

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

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

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

Почему обновляемые контракты используют инициализаторы?

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

Что такое коллизия хранилища?

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Важные стандарты и практики, такие как слоты хранилища прокси ERC-1967, хранилище с пространствами имен ERC-7201, функции инициализации, аудиты, timelock и прозрачный контроль администратора, могут снизить эти риски.

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

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