Пороговые подписи
Пороговые подписи позволяют необходимому числу участников совместно создавать цифровую подпись, используя доли общего ключа подписи. При хранении криптовалют это позволяет распределить полномочия на подписание между системами или организациями. Пороговая схема зависит от криптографического протокола и устройства управления ключами; обозначение MPC wallet не определяет эти подробности.[1]
Пороговые схемы и мультиподписи
В пороговой схеме подписывать может достаточное подмножество участников. FROST — двухраундовый протокол пороговой подписи Шнорра с предположениями безопасности о генерации долей ключа и числе скомпрометированных участников. RFC 9591 — информационная публикация Crypto Forum Research Group, а не спецификация категории Internet Standards Track.[1]
Подписание несколькими сторонами не всегда означает пороговую подпись. MuSig2, описанный в BIP 327, агрегирует открытые ключи участников и создаёт подпись Шнорра, совместимую с BIP 340, но требует участия всех подписантов, чьи ключи вошли в агрегацию. Это схема мультиподписи n-из-n, а не пороговая схема t-из-n.[2]
Предположения безопасности и эксплуатационные условия
Распределение долей меняет модель доверия, но не устраняет необходимость в защищённых системах. FROST предполагает безопасную генерацию и распределение долей и ограничивает число участников, которых может скомпрометировать противник. Раздел о безопасности рассматривает повторное использование одноразовых значений nonce, побочные каналы и сбои протокола. Доступность подписания и защита от подделки — разные свойства.[1]
Кастодиальные сервисы
Документация Multi-party Compute Google Cloud, проверенная в октябре 2026 года, описывает платформу хранения активов, сочетающую пороговые подписи с организационными мерами контроля. Сервис обозначен как Preview; описан API v1beta. Указана ECDSA на secp256k1 для Bitcoin и EVM-совместимых приложений; это не означает поддержки всех форматов подписей блокчейнов.[3]
Криптографическая авторизация также отличается от автоматической проверки политик транзакций. Согласно документации Google, достаточное число подписантов может авторизовать транзакцию, отклонённую автоматическими политиками. Поэтому решение политики следует понимать в рамках модели подписантов и управления сервисом.[4]
Источники
- ↑ 1,0 1,1 1,2 RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol, June 2024, introduction and security considerations.
- ↑ BIP 327: MuSig2 for BIP340-compatible Multi-Signatures, motivation and general signing flow, checked 29 October 2026.
- ↑ Google Cloud: Multi-party Compute overview, checked 29 October 2026.
- ↑ Google Cloud: Transaction policy evaluation, checked 29 October 2026.