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

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

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

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

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

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

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

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

Когда реализация меняется, адрес прокси может оставаться прежним, а код за ним — измениться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прокси — это вход, а реализация — логика за этим входом.

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

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

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

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

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

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

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

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

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

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

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

Delegatecall

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

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

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

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

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

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

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

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

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

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

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

Структура хранилища — это порядок и расположение переменных в хранилище смарт-контракта.

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

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

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

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

Это называется риском конфликта хранилища или повреждения хранилища.

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

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

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

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

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

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

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

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

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

Многие современные системы прокси используют слоты, совместимые с ERC-1967.

Сам по себе стандарт не делает обновления безопасными.

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

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

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

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

Паттерн Transparent Proxy

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

Документация OpenZeppelin по прокси объясняет, что TransparentUpgradeableProxy имеет встроенный интерфейс администратора и обновлений.

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

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

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

Transparent Proxy широко используются, поскольку предоставляют понятную модель администратора.

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

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

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

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

Паттерн UUPS Proxy

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

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

Документация OpenZeppelin объясняет, что UUPSUpgradeable включает механизм обновления в контракт реализации, а не использует ту же встроенную структуру администратора прокси, что и transparent proxy.

Прокси UUPS могут быть легче transparent proxy, поскольку сам прокси может быть проще.

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

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

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

UUPS может быть эффективным и гибким при использовании зрелых библиотек и инструментов проверки.

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

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

Паттерн Beacon Proxy

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

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

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

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

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

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

Документация OpenZeppelin по прокси включает BeaconProxy и UpgradeableBeacon как компоненты, связанные с прокси.

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

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

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

Паттерн Diamond Proxy

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

Официальный стандарт EIP-2535 Diamond определяет модульную систему смарт-контрактов, в которой функции можно добавлять, заменять или удалять через facets.

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

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

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

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

Обновление diamond может заменить только часть системы, поэтому важно отслеживать изменения.

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

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

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

Пространства имен в хранилище

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

Официальный стандарт ERC-7201 Namespaced Storage Layout определяет соглашение для документирования мест хранения при namespaced storage в исходном коде Solidity.

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

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

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

Руководство OpenZeppelin по написанию обновляемых контрактов отмечает, что для проверки его плагинами обновлений layouts namespaced storage с необходимой информацией компилятора требуется Solidity 0.8.20 или выше.

Namespaced storage не устраняет потребность в аудитах.

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

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

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

Инициализаторы

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

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

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

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

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

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

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

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

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

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

Полномочия на обновление

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

Полномочия на обновление — одно из важнейших предположений о доверии в обновляемом контракте.

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

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

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

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

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

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

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

В обновляемых системах дизайн управления — это дизайн безопасности.

Timelock

Timelock задерживает выполнение после предложения или одобрения обновления.

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

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

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

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

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

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

Хороший протокол ясно объясняет свои правила timelock.

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

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

Обновления под контролем управления

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

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

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

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

Голосование управления не означает автоматически, что изменение технически безопасно.

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

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

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

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

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

Неизменяемые и обновляемые смарт-контракты

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

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

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

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

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

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

Ни одна из моделей не всегда лучше другой.

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

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

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

Миграция и возможность обновления

Миграция означает развертывание нового контракта и перенос пользователей, активов или интеграций со старого контракта на новый.

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

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

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

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

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

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

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

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

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

Верификация исходного кода

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

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

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

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

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

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

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

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

Верификация — это шаг к прозрачности, а не полная гарантия безопасности.

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

Резервы хранилища

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

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

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

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

Резервы хранилища полезны, но требуют дисциплины.

Неправильное использование резерва все равно может вызвать проблемы структуры хранилища.

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

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

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

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

Тестирование обновлений

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

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

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

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

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

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

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

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

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

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

Аудиты обновлений

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

Аудит обновления должен сравнивать старую версию с новой.

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

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

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

Аудит не гарантирует безопасность, но снижает риск.

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

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

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

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

Совместимость ABI

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

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

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

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

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

Разработчикам следует четко документировать изменения ABI до обновлений.

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

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

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

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

Риск ключа администратора

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

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

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

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

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

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

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

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

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

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

Экстренные обновления

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

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

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

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

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

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

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

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

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

Лучший дизайн сочетает быструю защиту с прозрачностью и подотчетностью.

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

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

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

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

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

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

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

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

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

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

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

Обновляемые DeFi-протоколы

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

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

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

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

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

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

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

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

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

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

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

Оракулы передают внешние данные, такие как цены активов, в смарт-контракты.

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

Официальная документация Ethereum по оракулам объясняет, что оракулы необходимы, поскольку смарт-контракты не могут самостоятельно получать прямой доступ к офчейн-данным.

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

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

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

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

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

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

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

Возможность обновления и мосты

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

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

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

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

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

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

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

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

Однако ни один процесс обновления не устраняет все риски мостов.

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

Возможность обновления и доверие пользователей

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

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

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

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

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

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

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

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

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

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

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

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

Затем проверьте адрес реализации, если обозреватель его показывает.

Изучите, использует ли прокси известный паттерн, например ERC-1967, Transparent Proxy, UUPS, Beacon Proxy или Diamond.

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

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

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

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

Изучите отчеты аудита, чтобы убедиться, что возможность обновления входила в объем аудита.

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

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

Распространенные ошибки при обновлении смарт-контрактов

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

Другая ошибка — забыть защитить функции инициализатора.

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

Четвертая ошибка — обновлять без timelock или публичного уведомления.

Пятая ошибка — развернуть новую реализацию без верификации исходного кода.

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

Седьмая ошибка — изменить ABI так, что это нарушает интеграции.

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

Девятая ошибка — использовать пользовательскую логику прокси без глубокого анализа.

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

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

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

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

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

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

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

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

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

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

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

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

Риски и ограничения возможности обновления смарт-контрактов

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

Второй риск — повреждение хранилища при небезопасном изменении реализации.

Третий риск — неправильное использование инициализатора или реинициализатора.

Четвертый риск — скрытая централизация через ключи администратора.

Пятый риск — нарушенные интеграции из-за изменений ABI или поведения.

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

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

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

Девятый риск — захват управления или поспешное голосование.

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

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

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

Выбирайте понятный паттерн обновления, такой как Transparent Proxy, UUPS, Beacon Proxy или Diamond, только после понимания его компромиссов.

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

Тщательно защищайте инициализаторы и реинициализаторы.

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

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

Верифицируйте исходный код каждой новой реализации.

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

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

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

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

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

Изучайте, кто контролирует полномочия обновления.

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

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

Не считайте, что старый аудит охватывает новую реализацию.

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

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

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

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

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

FAQ

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

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

Зачем обновляют смарт-контракты?

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

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

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

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

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

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

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

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

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

Что такое риск структуры хранилища?

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

Что такое timelock при обновлении?

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

Означает ли верифицированный исходный код, что обновляемый контракт безопасен?

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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