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

Ротация подписантов мультиподписи

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

Обновлено

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

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

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

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

Человек, устройство для подписи, закрытый ключ и адрес владельца в сети — отдельные записи. Зафиксируйте точный адрес, хранителя, независимый домен контроля, состояние резервной копии и причину ротации. Законная ротация никогда не требует раскрывать seed-фразу или закрытый ключ.

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

  1. Инвентаризируйте текущие полномочия. По независимо проверенным сети и адресу счёта прочитайте развёрнутую реализацию, список владельцев, порог, nonce, включённые модули, guards, fallback handler, путь восстановления и все timelocks. Модуль или механизм восстановления может исполнять действия вне обычного порога владельцев, а ограничивающий guard может заблокировать в остальном корректную ротацию.
  2. Определите целевое состояние до подписания. Запишите точный набор владельцев и порог после изменения. Убедитесь, что порог не превышает число владельцев и что как минимум столько же независимых подписантов останутся работоспособными. Географическое разделение не означает независимость, если один человек, хранилище паролей, облачная учётная запись или администратор контролирует все устройства.
  3. Зарегистрируйте и аутентифицируйте нового подписанта. Создайте или восстановите новый ключ в предназначенной для него среде хранения, проверьте адрес на доверенном устройстве и докажите контроль согласованным заданием или тестовой подписью. Подтвердите адрес по второму аутентифицированному каналу; не полагайтесь только на скопированный текст чата или интерфейс кошелька.
  4. Выберите порядок с безопасными промежуточными состояниями. Некоторые контракты могут атомарно заменить одного владельца. Например, Safe предоставляет swapOwner, а также addOwnerWithThreshold, removeOwner и changeThreshold. Если реализации нужны несколько транзакций, анализируйте набор владельцев и порог после каждого шага. Добавьте и проверьте возможности до их удаления, если только активная компрометация не делает такой порядок опасным.
  5. Декодируйте и смоделируйте точную транзакцию. Независимо проверьте chain ID, адрес счёта, target, селектор функции, старый и новый адреса владельца, итоговый порог, nonce, value и тип операции. Рассматривайте delegatecall, пакетное исполнение, изменения модулей и изменения guard как отдельные эффекты высокого риска. Каждый подписант должен одобрить один и тот же декодированный payload и хеш транзакции.
  6. Исполните с существующими полномочиями. Текущий действующий кворум разрешает ротацию, если документированный путь восстановления не предусматривает иное. В экстренной ситуации координируйтесь только через аутентифицированные контакты и используйте нескомпрометированных подписантов. Если недоступны и обычный кворум, и заранее настроенные полномочия восстановления, стандартный вызов управления владельцами не сможет восстановить доступ.
  7. Проверьте и завершите изменение. После подтверждения напрямую запросите набор владельцев и порог, проверьте созданные события или трассировки в зависимости от реализации и убедитесь, что старый адрес больше не уполномочен. Новый подписант должен участвовать в одобренной транзакции низкого риска или с нулевой стоимостью, требующей заданного порога. Проверьте ожидающие транзакции, отзовите внесетевой доступ и резервные копии прежнего подписанта и сохраните предложение, подписи, хеш транзакции, блок и конечное состояние.

Практический пример

Предположим, у счёта 3-of-5 есть владельцы A, B, C, D и E, а B нужно заменить на F. Сначала команда проверяет, что F контролирует точный предложенный адрес и остаётся независимым от других владельцев. Для совместимого развёртывания Safe она готовит swapOwner(prevOwner, B, F). Этот вызов сам является транзакцией Safe и поэтому требует 3 действительных подтверждения от текущего набора владельцев. Декодированный результат должен сохранить число владельцев 5 и порог 3.

После подтверждения транзакции команда читает getOwners и getThreshold, убеждается, что B отсутствует, а F присутствует, и проводит с участием F и двух других владельцев одобренный тест со стоимостью 0. Она также проверяет ожидающие транзакции: подпись или предварительное одобрение от B после удаления может больше не проходить проверку владельца, поэтому затронутые предложения нужно отменить или создать заново, а не считать исполнимыми.

Если B мог быть скомпрометирован, команда не просит его одобрить удаление. Три других нескомпрометированных владельца исполняют замену, а затем проверяют модули, разрешения восстановления, allowances, session keys и уже исполненные транзакции, поскольку удаление B не отменяет прежние действия и не отзывает полномочия, выданные другим путём. Если доступны менее 3 нескомпрометированных владельцев, помочь может только заранее настроенный путь восстановления или администрирования; передача seed-фраз или доверие незапрошенному сервису «восстановления» не заменяет кворум.

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

  • Неверный счёт или адрес. Проверьте chain ID, адрес мультиподписи, реализацию и адрес нового владельца на независимых устройствах и по независимым источникам. Отравление адреса и ошибки копирования могут передать контроль злоумышленнику.
  • Потеря кворума. Смоделируйте каждое промежуточное состояние. Слишком раннее удаление владельца, повышение порога выше числа доступных подписантов или одновременная ротация нескольких связанных устройств может сделать счёт непригодным.
  • Временная концентрация. Более низкий порог или недавно добавленный подписант может создать период, когда счёт контролирует меньше сторон. Предпочитайте атомарную замену, если она поддерживается, и не снижайте порог лишь для упрощения процедуры.
  • Связанное хранение. Разные адреса не независимы, если их seed-фразы, устройства, резервные копии, коммуникации или администраторы имеют общий домен отказа. Тестируйте восстановление без централизации секретов.
  • Скрытые полномочия. Модули, guards, fallback handlers, session keys, timelocks и контракты восстановления могут обойти или заблокировать путь владельцев. Инвентаризируйте и проверяйте их до и после ротации.
  • Гонка со скомпрометированным подписантом. До подтверждения удаления подозрительный подписант может опередить транзакцию, вывести активы, изменить конфигурацию или одобрить другую транзакцию. Используйте процедуры реагирования, приватную доставку транзакций, когда это уместно, и непрерывный мониторинг состояния; не считайте, что отправленная транзакция уже выиграла гонку.
  • Устаревшие ожидающие одобрения. Изменения владельцев и порога могут сделать собранные подписи недействительными или поменять набор достаточных подтверждений. Повторно оцените каждую транзакцию в очереди по конечному состоянию и отмените устаревшие предложения.
  • Ложное завершение. Уведомление интерфейса об успехе не доказывает заданное состояние. Дождитесь требуемой политики подтверждения, затем прочитайте состояние контракта и проверьте payload транзакции, события и результат исполнения.
  • Неполное отключение доступа. Удаление владельца в сети не стирает скопированные ключи, организационный доступ, учётные данные relayer, записи в хранилище паролей или полномочия в других контрактах и сетях. Отзовите каждый элемент отдельно и сохраните аудиторский след.

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

  • «Ротация означает перевод всех активов в новый кошелёк». Многие мультиподписи на основе смарт-счетов обновляют владельцев по тому же адресу счёта. Миграция — другая операция, которая может требоваться только конкретной реализацией или планом реагирования.
  • «Сначала добавить нового подписанта всегда безопасно». Это защищает доступность, но может временно расширить набор уполномоченных. При активной компрометации атомарная замена или другой экстренный порядок могут быть безопаснее.
  • «Порог 3-of-5 означает, что доступны любые три названных человека». Контракт считает действительные счета владельцев, а не людей, отделы или устройства. Совместное хранение и недоступные ключи уменьшают фактическую независимость и доступность.
  • «Удаление скомпрометированного владельца отменяет ущерб». После подтверждения удаление предотвращает дальнейшее использование этого пути владельца; оно не отменяет исполненные транзакции и не отзывает разрешения, созданные в другом месте.
  • «Интерфейса кошелька достаточно как доказательства». Интерфейсы и службы индексирования могут быть устаревшими, неверно настроенными или вредоносными. Декодируйте транзакцию и прочитайте конечное состояние контракта через независимо проверенный endpoint.
  • «Без кворума поддержка может сбросить кошелёк». У самостоятельно хранимой мультиподписи есть только закодированные или заранее настроенные в сети пути полномочий. Без действующего кворума или пути восстановления доступ может быть потерян навсегда.

Похожие темы

Источники

Навигация

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