Timelock и multisig управления: как проверить контроль обновлений

Начните с получателя административных вызовов

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

Запишите цепочку вида рабочий контракт → контроллер обновления → timelock → proposer или система управления. Это учебная схема, а не универсальная архитектура. Если на каком-то шаге связь не подтверждена кодом и состоянием, обозначьте разрыв проверки, вместо того чтобы достраивать его по похожим названиям.

Проверьте не только число секунд, но и управление ролями

Для OpenZeppelin TimelockController прочитайте минимальную задержку и действующие роли proposer, executor, canceller и администратора. Открытый executor может позволять любому исполнить уже подготовленную операцию после ожидания; сам по себе он не даёт право предложить произвольное обновление.

Установите, остался ли внешний администратор или timelock управляет собой. В стандартной модели updateDelay проходит через сам timelock; другие реализации могут отличаться. Административный доступ к ролям важен даже тогда, когда изменение реализации всё ещё требует задержки: он способен менять участников процесса и возможности отмены.

• задержка прочитана у нужного timelock;
• роли подтверждены состоянием;
• сведения о выдаче и отзыве ролей сопоставлены с текущим блоком;
• порядок изменения задержки проверен по реализации.

Порог подтверждения нужно читать вместе с модулями

Например, у Safe список владельцев можно проверить через getOwners(), а порог – через getThreshold(). Это показывает адреса и необходимое число подтверждений стандартного пути, но не доказывает независимость владельцев ключей, принадлежность их разным организациям или качество хранения.

Также исследуйте включённые модули и ограничения исполнения. Модуль может разрешать действия по собственной логике без обычного набора подписей каждой операции. Guard способен добавлять проверки и в неудачной конфигурации блокировать исполнение; его охват нужно оценивать для конкретной версии и пути вызова. Один числовой порог не описывает всю политику аккаунта.

Сопоставьте основной маршрут и прямые альтернативные роли

Проверьте, нет ли у рабочего контракта, beacon или ProxyAdmin отдельного управляющего адреса, способного выполнить то же изменение другим путём. Аварийные права тоже нужно классифицировать: мгновенная пауза не равна мгновенному обновлению кода. Не объявляйте любую роль обходом timelock без проверки её возможностей.

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

• найдены все пути нужного изменения;
• аварийные функции отделены от upgrade;
• модули и guard включены в анализ;
• неизвестные звенья перечислены;
• сохранён блок и предусмотрена повторная проверка.

Чек-лист: timelock и multisig управления: как проверить контроль обновлений

• рабочий контракт связан с контроллером;
• timelock действительно входит в путь обновления;
• роли и их администраторы проверены;
• multisig владельцы и порог прочитаны;
• модули и guard исследованы;
• альтернативные полномочия классифицированы;
• снимок привязан к сети и блоку.

Материал подготовлен редакцией сайта и проверен 26 октября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.