Timelock и emergency pause часто упоминают вместе, хотя они действуют в противоположных направлениях. Timelock намеренно замедляет изменение протокола. Emergency pause даёт ограниченному кругу участников возможность остановить опасную функцию немедленно. Без первого пользователи не успевают отреагировать на обычное управление, без второго команда может наблюдать атаку и ждать окончания собственной задержки.
Безопасность определяется не наличием этих названий, а разделением полномочий. Кто создаёт операцию, кто может её отменить, кто нажимает аварийный тормоз, что именно прекращает работать и кто возвращает систему в нормальный режим – это пять разных вопросов.
Зачем нужен timelock
Timelock помещает административный вызов в очередь и разрешает исполнение лишь после минимальной задержки. За это время пользователи, разработчики и независимые наблюдатели могут прочитать calldata, оценить последствия и сократить позицию. Задержка превращает незаметную мгновенную власть в публично наблюдаемое намерение.
Типичная операция проходит состояния: создана, ожидает, готова к исполнению, исполнена или отменена. Proposer определяет, что поставить в очередь. Executor отправляет готовую операцию. Canceller прекращает её до исполнения. Admin управляет ролями, поэтому неправильно настроенный admin способен обесценить всю схему.
Timelock не обязан сам принимать политическое решение. Оно может появиться после голосования DAO или подписей multisig. Его задача – обеспечить временной барьер между утверждением и воздействием на контракты. Практическая проверка адресов, ролей и событий дана в руководстве по аудиту timelock и pause.
Что делает emergency pause
Pause – защитное состояние, при котором контракт отклоняет заранее выбранные операции. Оно может блокировать новые deposits, borrowing, swaps или bridge messages. Другие функции, например repay и withdrawal, иногда намеренно оставляют доступными, чтобы пользователи могли уменьшить риск.
Универсального смысла pause нет. В одном протоколе это общий флаг для всех рынков, в другом – отключение конкретного asset, а в третьем – закрытие только отдельных selectors через permission manager. Даже стандартный модуль Pausable действует лишь там, где разработчик добавил проверку состояния.
Аварийный guardian обычно получает более узкое право, чем governance. Он может остановить функцию, но не переводить treasury, менять комиссию или устанавливать произвольный код. Такая асимметрия полезна: быстрое действие сокращает ущерб, однако не позволяет одному оперативному ключу незаметно переписать правила.
Кто может остановить протокол
На практике emergency authority принадлежит одному из четырёх типов участников: EOA дежурного разработчика, multisig команды безопасности, специализированному Security Council или автоматизированному модулю. EOA реагирует быстро, но создаёт риск одного ключа. Multisig устойчивее к компрометации одного участника, хотя сбор подписей занимает время.
Security Council может включать независимых участников и повышенный threshold. Но публичный список имён не показывает реальную независимость ключей. Следует учитывать общих работодателей, хранение подписей, modules и возможность смены owners. Основы такой оценки раскрыты в статье о проверке multisig.
Автоматический pause может срабатывать при отклонении oracle, превышении лимита вывода или необычном изменении баланса. Он уменьшает задержку реакции, но сам становится частью критической логики. Ложное срабатывание способно остановить рынок, а неверный порог – пропустить атаку.
Кто может возобновить работу
Право unpause опаснее, чем кажется. Если guardian скомпрометирован во время активной атаки и может мгновенно снять собственную паузу, защита превращается в короткую помеху. Поэтому протоколы часто разделяют роли: guardian быстро останавливает, а governance или более сильный multisig возобновляет работу после анализа.
Восстановление может требовать не только unpause. Иногда сначала обновляют implementation, меняют oracle, закрывают повреждённый рынок или корректируют accounting. Эти изменения разумно проводить через timelock, но при активном инциденте долгая задержка увеличивает простой. Компромисс задаётся заранее: какие узкие исправления разрешены быстро и какие изменения всегда ждут.
Полезна ступенчатая модель. Сначала guardian блокирует рост риска. Затем участники публикуют разбор и remediation. После проверки governance открывает только безопасные операции, а полный режим возвращается отдельным решением. Один общий переключатель не даёт такой точности.
Как timelock и pause работают вместе
Нормальный путь управления начинается с proposal или решения multisig, проходит timelock и заканчивается исполнением. Аварийный путь идёт напрямую к узкому набору pause-функций. Он обходит задержку именно потому, что ожидание при эксплойте неприемлемо.
Хорошая архитектура разделяет эти траектории. Guardian не может установить новую implementation. Timelock не мешает guardian остановить deposits. Возврат из pause контролирует более широкая группа, а изменение самих guardian roles и минимальной задержки проходит обычный governance process.
Дополнительными слоями служат caps, rate limits и withdrawal queues. Они не заменяют emergency pause, но ограничивают скорость ущерба и дают время на реакцию. Чем мягче механизм, тем меньше вероятность, что защитное действие заблокирует добросовестных пользователей.
Когда задержка не защищает
Timelock бесполезен, если существует параллельный путь изменения тех же правил. Например, DAO ждёт два дня для настройки риска, но владелец proxy способен мгновенно заменить implementation. Тогда реальная задержка равна нулю. Различия механизмов обновления объяснены в материале о типах proxy.
Другой обход – admin, который может выдать себе proposer role или уменьшить delay без ожидания. В корректно замкнутой конфигурации timelock управляет собственными критическими ролями, а смена минимальной задержки проходит через него же. Bootstrap-admin, оставшийся после запуска, нарушает это свойство.
Открытая EXECUTOR_ROLE сама по себе не является обходом. Нулевой адрес может позволять любому исполнить уже готовую операцию, но не создавать новую. Это повышает liveness: одобренное действие не зависит от одного bot. Полномочие proposer остаётся отдельным.
Когда pause создаёт новый риск
Слишком широкая пауза способна заморозить withdrawals и repayments вместе с опасными deposits. Заёмщик может потерять возможность погасить долг, тогда как liquidation возобновится позже. Пользователь получает операционный риск от самого защитного механизма.
Слишком узкая пауза оставляет обходной маршрут. Если остановлен router, прямой вызов pool может продолжать работать. Если закрыты transfers токена, mint через bridge или vault остаётся доступным. Поэтому область действия должна соответствовать активам и связям протокола, а не только основному интерфейсу.
Централизованный guardian также может применять pause как инструмент цензуры или давления. Ограниченный scope, прозрачные события, multisig и процесс последующего подтверждения governance уменьшают этот риск, но не устраняют его полностью.
Как читать модель власти пользователю
Пользователю важны три временных горизонта. Первый – сколько занимает мгновенная аварийная реакция. Второй – сколько длится обычный governance delay. Третий – сколько времени требуется самому пользователю для безопасного выхода с учётом cooldown, epoch, bridge и ликвидности.
Если вывод занимает семь дней, а upgrade delay равен одному дню, формально видимый timelock не даёт полного окна выхода. Если pause блокирует withdrawal без предельного срока, guardian фактически контролирует доступ к средствам. Если unpause доступен тому же одиночному ключу, остановка не защищает от его компрометации.
Проверять нужно deployed contracts и события, а не только документацию. Proxy, owner и роли меняются. Даже успешная simulation не гарантирует неизменность authority до включения операции в блок, о чём подробнее рассказано в материале о пределах симуляции.
Признаки сбалансированной схемы
- Наблюдаемость. Обычные изменения заранее появляются в onchain queue с декодируемой calldata.
- Достаточный delay. Пользователь успевает выполнить реальный, а не теоретический выход.
- Узкий guardian. Аварийная роль останавливает риск, но не переводит активы и не меняет произвольный код.
- Раздельный unpause. Возобновление требует более сильного подтверждения или governance.
- Сохранение выхода. По возможности остаются repay, withdrawal и отмена неисполненных заявок.
- Нет скрытого upgrade bypass. Proxy admin, beacon owner и role admin подчинены заявленной задержке.
- Прозрачная история. События показывают pauses, role changes, upgrades, scheduling и execution.
Итог
Timelock даёт время увидеть плановое изменение, а emergency pause даёт время остановить внеплановый ущерб. Они дополняют друг друга только при чётком разделении ролей. Быстрый guardian должен иметь узкие полномочия, обычные обновления – проходить наблюдаемую задержку, а возврат к работе – требовать достаточной проверки.
Фраза «есть timelock» не является гарантией. Реальная модель безопасности складывается из proxy admin, role admin, multisig, guardian, области pause и времени пользовательского выхода. Самый короткий из обходных путей определяет фактическую скорость власти над протоколом.
