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

Кошелёк с мультиподписью

Узнайте, как кошелёк M-of-N распределяет полномочия на транзакции, чем отличаются скриптовые и контрактные мультиподписи и какие риски подписантов, исполнения, модулей и восстановления сохраняются.

Обновлено

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

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

Кошелёк с несколькими подписями, или мультисиг, контролирует счёт либо расходуемый выход правилом, которое требует не менее M одобрений от N авторизованных открытых ключей или аккаунтов владельцев. Например, правило 2-of-3 принимает любые два действительных полномочия из трёх. Один закрытый ключ перестаёт быть единственной точкой контроля, однако не каждая одобренная транзакция становится безопасной.

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

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

Порог M-of-N отражает ограничения компрометации и доступности. Схема 3-of-5 продолжит работать, если два полномочия недоступны, но любые три действительных полномочия могут одобрить расход. Разные адреса не независимы, если один человек, администратор устройств, облачный аккаунт, место хранения резервных копий или кастодиан контролирует достаточное их число.

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

  1. Проверьте полномочия до предложения. Подтвердите сеть и аккаунт либо выход, затем изучите скрипт или развёрнутый контракт, набор владельцев, порог, правила nonce или последовательности и каждый модуль, guard, fallback handler, путь восстановления и право обновления, способные исполнять или блокировать транзакции.
  2. Сформируйте и декодируйте точный запрос. Проверьте получателя, актив, стоимость, calldata или скрипт, тип операции, nonce, комиссии и содержимое пакета. При наличии надёжных инструментов моделируйте сложные вызовы и убедитесь, что каждый подписант проверяет реальные полномочия подписи, а не надпись интерфейса.
  3. Соберите одобрения в независимых доменах контроля. Подписанты проверяют один и тот же дайджест транзакции на доверенных устройствах и общаются по аутентифицированным каналам. Законная процедура не требует раскрытия seed-фразы или закрытого ключа.
  4. Исполните одобренный запрос. Достижение порога может лишь сделать предложение исполнимым. Исполнитель всё ещё должен передать или отправить его и, возможно, заплатить сетевую комиссию. Устаревший nonce, конкурирующее предложение, изменившееся состояние, недостаточная комиссия или неудачный вызов могут помешать исполнению.
  5. Проверьте завершение по состоянию блокчейна. Дождитесь требуемых подтверждений, изучите исполненный payload и результат, при необходимости подтвердите балансы, настройки владельцев и события. Повторно оцените ожидающие предложения после изменения владельцев, порога, модулей или политики.

Пример

Казначейство использует мультисиг смарт-аккаунта 3-of-5 с владельцами A, B, C, D и E в отдельных доменах контроля. Для платежа 10,000 USDC предложение фиксирует правильные сеть, аккаунт, получателя, контракт токена, сумму, calldata, nonce и политику комиссий. A, C и E независимо декодируют один запрос до одобрения.

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

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

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

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

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

  • «Чем больше подписантов, тем всегда безопаснее». Больший набор может снизить концентрацию, но повышает риски координации, фишинга и доступности. Выбирайте владельцев и порог по модели угроз и операционным возможностям.
  • «Кошелёк 3-of-5 контролируют пять независимых людей». Блокчейн считает действительные ключи или аккаунты, а не людей. Общие устройства, копии, администраторы или кастодианы могут свести номинально разных владельцев к одному домену.
  • «Мультисиг равен двухфакторной аутентификации или MPC». Все эти схемы распределяют контроль, но отличаются учётными данными, путями проверки, on-chain доказательствами и предпосылками восстановления.
  • «После одобрения порога перевод завершён». Одобрение, исполнимость, отправка, включение и подтверждение — разные состояния. Запрос может остаться в ожидании или завершиться ошибкой.
  • «Мультисиг предотвращает кражу и эксплуатацию контрактов». Он ограничивает только пути полномочий, заложенные в реализации. Действительный кворум, привилегированный модуль, уязвимый контракт или небезопасное восстановление всё равно могут привести к необратимой потере.

Похожие темы

Источники

Навигация

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