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

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

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

Обновлено

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

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

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

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

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

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

Прокси читает адрес реализации и через delegatecall выполняет её код в своём хранилище. ERC-1967 стандартизирует слоты реализации, Beacon и администратора. Transparent-прокси разделяет вызовы администратора и пользователей; UUPS хранит логику обновления в реализации и использует ERC-1822; один Beacon может менять много прокси.

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

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

Надёжный процесс:

  1. Зафиксировать исходники, компилятор, зависимости, схемы хранения, адреса и ожидаемый байткод обеих реализаций.
  2. Проверить изменения, совместимость, миграцию, полномочия, зависимости и откат; испытать всю транзакцию на форке.
  3. Опубликовать предложение и адрес, применив заявленные multisig, управление и timelock без скрытого обхода.
  4. После исполнения проверить слот реализации или Beacon, события, байткод, состояние, роли и инварианты на записанном блоке.
  5. Отслеживать слоты, роли и параметры и не считать откат всегда безопасным.

Пример

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

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

Риски

  • Привилегированная замена: администратор, multisig, governor или украденный ключ могут установить вредоносный код.
  • Повреждение хранения: несовместимая схема искажает балансы, владельцев, mapping или учёт.
  • Ошибка инициализации: пропущенная, повторная или открытая инициализация передаёт контроль.
  • Особенности схемы: Transparent, UUPS, Beacon и собственные прокси ломаются по-разному.
  • Имитация управления: возможны аварийный обход, короткая задержка, концентрация голосов или слабые подписанты.
  • Опасная миграция или откат: необратимое состояние может потерять прежний смысл.
  • Пробел проверки: проверенный исходник не доказывает цель прокси, администратора и начальное состояние.
  • Риск мониторинга: сервисы могут следить за старой реализацией или пропустить смену Beacon.

Заблуждения

  • «Контракт по адресу неизменяем». Байткод прокси может быть неизменным, но слот реализации или Beacon меняет поведение.
  • «Multisig децентрализует обновления». Это зависит от независимости подписантов, порога, операций и замены.
  • «Timelock блокирует вредоносное обновление». Он лишь даёт время наблюдать и выйти.
  • «Проверка хранения доказывает безопасность». Она не проверяет логику, полномочия, оракулы, миграцию и экономику.
  • «Отказ от обновлений всегда убирает контроль». Проверяют администратора, Beacon, governor, UUPS и альтернативные пути.

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

Источники

Навигация

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