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

Как работает временная блокировка управления?

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

Обновлено

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

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

Временная блокировка управления (governance timelock) — это контроллер исполнения, а не ещё одно голосование. После того как управление санкционирует набор вызовов, уполномоченный предлагающий ставит точную операцию в очередь. Контракт фиксирует момент, когда она может стать доступной для исполнения, и отклоняет попытки исполнить её раньше. Благодаря задержке предстоящее обновление, изменение параметров, перевод из казначейства или изменение роли становится заметным до того, как вступит в силу.

Заявленная задержка — лишь одна часть механизма контроля. Проверяйте идентификатор операции, самое раннее время исполнения, правило истечения срока, если оно есть, предшествующую операцию, предлагающего, исполнителя, отменяющего, администратора и все прочие способы управления целевым контрактом. Временная блокировка на 48-hour не создаёт окно выхода продолжительностью 48-hour, если операция поздно поставлена в очередь, мониторинг сработал с задержкой, вывод средств занимает больше времени или другой привилегированный ключ может немедленно выполнить то же изменение.

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

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

  1. Полномочия закрепляются за временной блокировкой. Timelock должен владеть целевым контрактом или иметь в нём соответствующую роль. Если у управляющего контракта нет полномочий над целью, принятие предложения ничего не меняет; если отдельный администратор сохраняет параллельные полномочия, этот путь может обойти задержку.
  2. Предлагающий ставит в очередь точную операцию. В TimelockController от OpenZeppelin идентификатор одиночной операции представляет собой хеш target, value, data, predecessor и salt; для пакетной операции хешируются соответствующие массивы, а также та же зависимость и соль. Изменение любого поля создаёт другой идентификатор операции. Соль позволяет различать в остальном одинаковые действия.
  3. Минимальная задержка начинается при постановке в очередь. Успешное голосование не обязательно запускает timelock. При постановке в очередь фиксируется время готовности с задержкой не меньше текущего минимума контракта. Операции OpenZeppelin переходят из состояния Unset в Waiting, затем в Ready и, после успешного исполнения, в Done.
  4. При исполнении проверяются зависимости и разрешения. Предшествующая операция уже должна находиться в состоянии Done. Вызывающая сторона должна соответствовать правилу исполнителя, а вызов целевого контракта — завершиться успешно. Исполнитель не может изменить поставленный в очередь набор вызовов. Предоставление роли исполнителя адресу address(0) разрешает исполнение любому участнику после наступления срока, что повышает доступность, но позволяет любому аккаунту выбрать точный допустимый момент исполнения.
  5. Отмена возвращает ожидающую операцию в исходное состояние. В актуальных контрактах OpenZeppelin аккаунт с ролью CANCELLER_ROLE может отменить ожидающую операцию, в том числе уже готовую, но ещё не исполненную. Повторная постановка в очередь запускает новый таймер. Распределение ролей имеет значение: в старых версиях и других реализациях timelock право отмены может принадлежать предлагающему или администратору.
  6. Истечение срока зависит от реализации. В TimelockController от OpenZeppelin нет встроенного истечения льготного периода: готовая операция остаётся готовой, пока её не исполнят или не отменят. Timelock в Compound v2, напротив, требует исполнения не позднее eta + GRACE_PERIOD, а в его исходном коде значение GRACE_PERIOD равно 14 days. Governor Bravo помечает поставленное в очередь предложение как просроченное после этой границы.
  7. Администрирование тоже должно выполняться с задержкой. OpenZeppelin разрешает вызывать updateDelay только через обращение timelock к самому себе. В развёртывании с самостоятельным администрированием изменения ролей также проводятся через поставленные в очередь операции. Временный внешний администратор, используемый при настройке, должен отказаться от этой роли после завершения конфигурации; иначе он останется отдельным источником доверительного риска.

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

Разбор примера

Предположим, предложение снижает порог ликвидации на рынке кредитования с 75% до 60%. Голосование заканчивается в Monday 12:00 UTC, но предлагающий ставит операцию в очередь только во Tuesday 18:00 UTC. Заданная задержка составляет 48 hours, поэтому самое раннее время исполнения — Thursday 18:00 UTC, а не Wednesday 12:00 UTC.

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

Таким образом, у пользователей есть 48 hours с момента постановки в очередь, но полезное время для выхода короче. Если уведомление приходит через 6 hours после постановки в очередь, а очередь анстейкинга или вывода занимает 24 hours, остаётся лишь 18 hours резерва:

usable response time = ready time - detection time - exit settlement time

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

Риски и меры контроля

  • Полномочия для обхода. Перечислите владельцев, администраторов прокси, роли контроля доступа, маяки обновлений, аварийные советы, модули и межсетевые исполнители. Эффективную задержку определяет самый короткий привилегированный путь.
  • Подмена или неверная расшифровка набора вызовов. Пересчитайте идентификатор операции по исходным полям, определите реализации прокси, расшифруйте каждый селектор и аргумент и смоделируйте весь пакет. Понятный человеку текст предложения не является исполняемым набором вызовов.
  • Недостаточное уведомление. Настройте оповещения по ончейн-событиям постановки в очередь и отмены, а не только по публикациям на форуме. Измеряйте срок уведомления от подтверждённой постановки в очередь до самого раннего допустимого блока или времени исполнения, затем вычитайте время обнаружения и завершения выхода.
  • Сбой отмены. Подтвердите, какие аккаунты могут отменить операцию, доступны ли они, какой порог подписей им нужен и остаётся ли отмена возможной после готовности операции. Отрепетируйте транзакцию до инцидента.
  • Сбой исполнителя или манипуляции со временем. Ограниченные исполнители могут оказаться недоступны или намеренно задержать исполнение. Открытое исполнение повышает доступность, но позволяет третьим лицам исполнить операцию сразу при наступлении срока, поэтому зависимые цены, обновления оракулов и позиции пользователей должны быть безопасны на этой границе.
  • Устаревшие операции в очереди. Там, где нет срока истечения, старые готовые операции могут оставаться исполнимыми бессрочно. Отслеживайте и явно отменяйте оставленные операции. При наличии льготного периода контролируйте точное время его окончания и после истечения требуйте нового цикла управления.
  • Риски зависимостей и пакетных операций. Проверяйте идентификатор предшествующей операции и порядок атомарного пакета. Один вызов с откатом может заблокировать атомарный пакет; неверная зависимость способна навсегда заблокировать в остальном корректную операцию.
  • Небезопасное администрирование. Подчините уменьшение задержки, выдачу ролей и замену timelock самому timelock. Удалите администраторов развёртывания, сохраните как минимум одного работоспособного предлагающего и исполнителя и не допускайте конфигурации, которая навсегда заблокирует управление.
  • Отсутствие реального выхода. Сопоставляйте задержку с очередями вывода, финальностью мостов, ликвидностью рынка, полномочиями приостановки и перегрузкой сети. Объявленная задержка не защищает пользователей, если активы нельзя вывести до исполнения.

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

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

  • «Задержка начинается после завершения голосования». Обычно она начинается, когда успешное действие ставят в очередь, если только развёрнутая реализация явно не связывает эти моменты.
  • «Исполнить может любой, значит любой может изменить предложение». Открытый исполнитель может запустить лишь уже поставленный в очередь набор вызовов с совпадающими идентификатором операции и условиями.
  • «Готовность означает, что действие должно исполниться немедленно». Готовность означает допустимость исполнения. Всё ещё нужны транзакция, разрешения, выполненные зависимости и успешный вызов целевого контракта.
  • «У любого timelock есть окно исполнения». Истечение срока зависит от реализации. Compound v2 использует льготный период; в TimelockController от OpenZeppelin готовые операции по умолчанию не истекают.
  • «Длительный timelock устраняет риск управления». Задержка помогает, только если до исполнения реально возможны мониторинг, понимание, отмена или приостановка, информирование и выход. Параллельные администраторы и заблокированный вывод могут свести пользу к нулю.

Похожие темы

Источники

Навигация

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