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

Неинициализированный обновляемый прокси: риск захвата инициализатором

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

Обновлено

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

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

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

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

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

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

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

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

Пример

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

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

Риски

Доходность должна рассчитываться на основе реальной стоимости выхода:

Чистая стоимость выхода = рыночная стоимость актива - ценовой шок - плата за протокол - налог на передачу - газ - скидка на риск ожидания

Установите три стрессовых сценария: перегрузка сети, исключение Oracle и обновление администратора. Предположим, что Gas расширяется в пять раз, глубина пула падает на 50 %, стейблкоин дисконтируется на 5 %, и вы не можете выйти в течение одного дня. Если месячный доход не может покрыть давление, высокий доход не обеспечивает достаточной компенсации.

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

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

  • Миф 1: Баланс на стороне клиента — это факт в цепочке. Внешний интерфейс может быть кэширован, проиндексирован с опозданием или подключен к неправильной сети, поэтому его необходимо перекрестно проверять с помощью чтения контракта.

  • Миф 2: Увеличение газа или проскальзывания может решить любую поломку. Газ влияет только на сортировку, а проскальзывание только снижает цену; Ошибки разрешений, Nonce и условий контракта не будут автоматически исправлены.

  • Миф 3: Успешное тестирование небольшого объема означает постоянную безопасность. Обновления администратора, динамические параметры и изменения ликвидности изменят результаты, и их следует проверять перед каждым расширением позиции.

Похожие темы

Источники

Навигация

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