---
title: "Обновляемый смарт-контракт"
description: "Обновляемый смарт-контракт сохраняет адрес и состояние прокси, пока уполномоченные лица меняют его реализацию. Такая гибкость добавляет риски хранения, инициализации, управления и мониторинга."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Обновляемый смарт-контракт
> Только в образовательных целях; не является инвестиционной рекомендацией или советом по безопасности. Право обновления позволяет привилегированным лицам менять поведение контракта и может привести к убыткам.
## Краткий ответ
Обновляемый смарт-контракт меняет действующую логику без нового основного адреса и потери состояния. Обычно прокси хранит состояние и через `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 и альтернативные пути.
## Связанные темы
- [Смарт-контракт](/ru/crypto/smart-contract/)
- [Аудит смарт-контракта](/ru/crypto/contract-audit/)
- [Мультиподписной кошелёк](/ru/crypto/multisig-wallet/)
- [Timelock](/ru/crypto/timelock/)
## Источники
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (проверено: 2026-08-22)
- [ERC-1822: Universal Upgradeable Proxy Standard (UUPS)](https://eips.ethereum.org/EIPS/eip-1822) - Ethereum Improvement Proposals (проверено: 2026-08-22)
- [ERC-7201: Namespaced Storage Layout](https://eips.ethereum.org/EIPS/eip-7201) - Ethereum Improvement Proposals (проверено: 2026-08-22)
- [Proxy Upgrade Pattern](https://docs.openzeppelin.com/upgrades-plugins/proxies) - OpenZeppelin Docs (проверено: 2026-08-22)
- [Writing Upgradeable Contracts](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin Docs (проверено: 2026-08-22)
- [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin Docs (проверено: 2026-08-22)
- [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html) - Solidity Documentation (проверено: 2026-08-22)
Source: https://wiki.fcontext.com/ru/crypto/upgradeable-contract/index.mdx