FROST означает Flexible Round-Optimized Schnorr Threshold. Это протокол пороговой подписи, в котором достаточное число участников подписывает под общим публичным ключом, не собирая весь секретный ключ в одном месте при подписании.
В схеме 2 из 3 достаточно двух доступных уполномоченных долей, а одной для подписи мало. Злоумышленник, получивший две, тоже достигает порога. Долгосрочная доля ключа не является частичной подписью конкретного сообщения: нужен совместный протокол со свежими одноразовыми значениями. [RFC 9591 — FROST]
Доверенный распределитель может создать секрет и раздать доли, поэтому знает весь ключ и должен безопасно с ним обращаться. DKG позволяет совместную генерацию без такого единственного распределителя, но добавляет собственную коммуникацию и проверки. RFC 9591 описывает прежде всего подпись; приложение о распределителе не означает, что каждое внедрение автоматически использует DKG. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
В первом раунде участник создаёт два секретных nonce и передаёт их публичные обязательства. Во втором проверяет сообщение, список участников и собственные обязательства, затем вычисляет свою долю подписи. Координатор объединяет доли. Связывающие множители привязывают nonce к конкретному сообщению и набору обязательств; два раунда не включают предварительную генерацию ключей. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Повторное использование nonce может раскрыть секретный ключевой материал. После использования секретные nonce следует безопасно вывести из употребления даже при прерванной попытке; восстановление старой копии не должно снова делать их пригодными. Случайность, одновременные сеансы и устойчивый учёт расходования относятся к безопасности, а не только к ускорению. [RFC 9591 — FROST]
Координатор собирает обязательства и доли подписи; без достаточного числа долей ключа он не может подписать самостоятельно. Однако он может задержать сообщения или вызвать прерывание. Проверка ошибочной доли может выявить автора, но не гарантирует завершения сеанса. Нужны аутентифицированный транспорт и достаточно доступных участников. [RFC 9591 — FROST]
Для Bitcoin результат должен соответствовать точному кодированию, хешированию и правилам BIP 340 и возможным корректировкам ключа Taproot. Одного выбора secp256k1 в общем наборе FROST недостаточно. ZF отдельно предоставляет frost-secp256k1-tr для Taproot; проверь конкретный набор и его тесты. Одна подпись в цепочке сама не раскрывает внутреннего порога. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Доле нужны правильный идентификатор, публичные данные группы и совместимое ПО. Восстановление потерянной доли с помощью остальных или обновление долей — дополнительные протоколы, которые внедрение должно реально поддерживать. Копия той же доли не добавляет независимого участника. Резервирование должно сохранять порог и не допускать возвращения использованных nonce. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Каждый подписант должен проверить получателей, суммы, комиссию и правила одобрения, а не слепо подписывать хеш координатора. FROST обеспечивает совместное подписывание, а не правильность делового намерения. Перед использованием проверь версию реализации, восстановление и поведение при сбоях; информационный RFC не сертифицирует весь кошелёк. [RFC 9591 — FROST]
Для полной картины прочитайте эту статью вместе с Schnorr signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.