---
title: "Ротация подписантов мультиподписи"
description: "Процедура с приоритетом проверки для замены подписантов мультиподписи с сохранением кворума, проверкой точного набора владельцев и порога в сети и безопасным реагированием на компрометацию ключа."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Ротация подписантов мультиподписи
> Только в образовательных целях; не является инвестиционной, юридической или информационно-безопасностной рекомендацией. Ошибка ротации может передать контроль, аннулировать ожидающие подтверждения или навсегда заблокировать счёт с мультиподписью.
## Краткий ответ
Ротация подписантов мультиподписи меняет счета, уполномоченные подтверждать транзакции. Обычно для неё не нужен новый адрес кошелька или перевод активов: привилегированная транзакция меняет набор владельцев счёта, а иногда и порог подтверждения. Реализации различаются, поэтому проверяйте развёрнутый контракт и текущее состояние в сети, а не предполагайте, что подписи интерфейса точно описывают полномочия.
Безопасная ротация сначала доказывает контроль над каждым новым подписантом, сохраняет исполнимый, но не концентрированный кворум на протяжении изменения, удаляет старого подписанта и проверяет конечное состояние в сети. Потеря необходимого кворума до исполнения может сделать обычную ротацию владельцев невозможной; снижение порога ради удобства способно создать окно для захвата контроля.
Человек, устройство для подписи, закрытый ключ и адрес владельца в сети — отдельные записи. Зафиксируйте точный адрес, хранителя, независимый домен контроля, состояние резервной копии и причину ротации. Законная ротация никогда не требует раскрывать 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.
- **«Без кворума поддержка может сбросить кошелёк».** У самостоятельно хранимой мультиподписи есть только закодированные или заранее настроенные в сети пути полномочий. Без действующего кворума или пути восстановления доступ может быть потерян навсегда.
## Похожие темы
- [Аппаратный кошелёк](/ru/crypto/hardware-wallet/)
- [Кошелёк с мультиподписью](/ru/crypto/multisig-wallet/)
- [Управление закрытыми ключами](/ru/crypto/private-key-management/)
- [Риск восстановления владельца смарт-счёта](/ru/crypto/smart-account-owner-recovery-risk/)
- [Симуляция транзакций](/ru/crypto/transaction-simulation/)
## Источники
- [Как работают смарт-счета Safe?](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (дата обращения: 2026-08-21)
- [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation (дата обращения: 2026-08-21)
- [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation (дата обращения: 2026-08-21)
- [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation (дата обращения: 2026-08-21)
- [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation (дата обращения: 2026-08-21)
- [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation (дата обращения: 2026-08-21)
- [Рекомендации по управлению ключами: часть 1 - общие положения](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST (дата обращения: 2026-08-21)
Source: https://wiki.fcontext.com/ru/crypto/multisig-signer-rotation/index.mdx