---
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.
# Неинициализированный обновляемый прокси: риск захвата инициализатором
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Обновляемые контракты не используют конструктор для установки состояния агента, а полагаются на инициализатор. В этой статье описываются неинициализированные агенты, блокировка реализации и проверки развертывания.
Когда новый прокси-адрес развернут, но транзакция инициализации еще не подтверждена, любой может попытаться сначала вызвать общедоступный инициализатор и стать владельцем.
При развертывании агента конструктор не будет выполнять логику инициализации контракта в хранилище агента. Поэтому обновляемые системы часто используют инициализатор, который можно вызвать только один раз для установки владельца, параметров токена и модулей. Если функция не защищена должным образом или если развертывание и инициализация разделены на две транзакции, злоумышленник может вызвать ее первым.
## Как это работает
Процесс безопасности помещает данные вызова развертывания и инициализации в одну и ту же атомарную транзакцию и отключает инициализацию при реализации конструкции контракта, чтобы предотвратить перехват самой реализации. Повторный инициализатор используется для добавления нового статуса к новой версии, а также должен ограничивать версию и разрешения на вызов. Только проверка владельца агента без проверки статуса инициализации реализации все равно может привести к утечке рисков.
Операции внутри цепочки разделены на четыре уровня: кошелек отвечает за отображение и подпись, RPC отвечает за чтение и трансляцию, код контракта определяет изменение статуса, а консенсус блока определяет, будет ли транзакция окончательно подтверждена. Демонстрация «успеха» на любом уровне не может заменить проверку на других уровнях.
## Пример
Проект сначала развертывает агент, а затем планирует вызвать инициализацию(команда). Злоумышленник контролирует пул памяти и сначала вызывает инициализацию(злоумышленник) с более высокой комиссией, становится администратором, а затем переходит на вредоносную реализацию и переводит средства. Собственная транзакция инициализации команды откатывается, но в этот момент управление теряется.
Газ, проскальзывание и время блокировки в кейсе используются для демонстрации метода расчета. Перед фактической операцией необходимо прочитать цену, ликвидность, разрешения и статус контракта текущей цепочки и текущего блока. Сумма одновременно записывает количество токенов, долларовую стоимость и необработанное целое число в цепочке.
## Риски
Доходность должна рассчитываться на основе реальной стоимости выхода:
Чистая стоимость выхода = рыночная стоимость актива - ценовой шок - плата за протокол - налог на передачу - газ - скидка на риск ожидания
Установите три стрессовых сценария: перегрузка сети, исключение Oracle и обновление администратора. Предположим, что Gas расширяется в пять раз, глубина пула падает на 50 %, стейблкоин дисконтируется на 5 %, и вы не можете выйти в течение одного дня. Если месячный доход не может покрыть давление, высокий доход не обеспечивает достаточной компенсации.
Единый протокол, единая цепочка, единый мост и единая стабильная валюта устанавливают верхние пределы соответственно. Любые должности, которые требуют, чтобы администраторы, оракулы, мосты, внешние интерфейсы и один RPC одновременно работали нормально для выхода, должны быть еще больше сужены, а множественные связанные зависимости не должны ошибочно приниматься за дисперсию.
## Распространённые заблуждения
- Миф 1: Баланс на стороне клиента — это факт в цепочке. Внешний интерфейс может быть кэширован, проиндексирован с опозданием или подключен к неправильной сети, поэтому его необходимо перекрестно проверять с помощью чтения контракта.
- Миф 2: Увеличение газа или проскальзывания может решить любую поломку. Газ влияет только на сортировку, а проскальзывание только снижает цену; Ошибки разрешений, Nonce и условий контракта не будут автоматически исправлены.
- Миф 3: Успешное тестирование небольшого объема означает постоянную безопасность. Обновления администратора, динамические параметры и изменения ликвидности изменят результаты, и их следует проверять перед каждым расширением позиции.
## Похожие темы
- [ERC-4626 атака инфляции первого депозита: почему акции Vault могут быть округлены](/ru/crypto/erc4626-inflation-attack/)
- [агентский договор](/ru/crypto/proxy-contract/)
- [смарт-контракт](/ru/crypto/smart-contract/)
- [Обновляемый контракт](/ru/crypto/upgradeable-contract/)
- [Подтверждение действительности](/ru/crypto/validity-proof/)
## Источники
- [API Proxy и Initializable](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (дата обращения: 20 августа 2026 г.)
- [Написание обновляемых контрактов](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (дата обращения: 20 августа 2026 г.)
- [Обновление смарт-контрактов](https://ethereum.org/developers/docs/smart-contracts/upgrading/) - Ethereum.org (дата обращения: 20 августа 2026 г.)
Source: https://wiki.fcontext.com/ru/crypto/initializer-takeover/index.mdx