FROST oznacza Flexible Round-Optimized Schnorr Threshold. To protokół podpisu progowego, w którym wystarczająca liczba uczestników podpisuje pod wspólnym kluczem publicznym, bez odtwarzania całego tajnego klucza w jednym miejscu podczas podpisywania.
W schemacie 2 z 3 wystarczą dwa dostępne uprawnione udziały, a jeden nie utworzy podpisu. Atakujący, który zdobędzie dwa, również osiągnie próg. Długoterminowy udział klucza nie jest częściowym podpisem konkretnej wiadomości: potrzebny jest wspólny protokół ze świeżymi wartościami jednorazowymi. [RFC 9591 — FROST]
Zaufany dystrybutor może utworzyć sekret i rozdzielić udziały, zna więc cały klucz i musi bezpiecznie się z nim obchodzić. DKG umożliwia wspólne generowanie bez takiego pojedynczego dystrybutora, ale wymaga własnej komunikacji i weryfikacji. RFC 9591 opisuje głównie podpis; dodatek o dystrybutorze nie oznacza, że każde wdrożenie automatycznie używa DKG. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
W pierwszej rundzie uczestnik tworzy dwa tajne nonce i udostępnia ich publiczne zobowiązania. W drugiej sprawdza wiadomość, listę uczestników i własne zobowiązania, po czym oblicza udział podpisu. Koordynator agreguje udziały. Czynniki wiążące łączą nonce z konkretną wiadomością i zbiorem zobowiązań; dwie rundy nie obejmują wcześniejszego generowania kluczy. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Ponowne użycie nonce może ujawnić tajny materiał klucza. Po użyciu trzeba bezpiecznie wycofać tajne nonce, także przy przerwanej próbie; odtworzenie starej kopii nie może przywrócić możliwości ich użycia. Losowość, równoległe sesje i trwałe śledzenie zużycia należą do bezpieczeństwa, nie tylko do optymalizacji szybkości. [RFC 9591 — FROST]
Koordynator zbiera zobowiązania i udziały podpisu; bez wystarczającej liczby udziałów klucza nie ma prawa podpisać samodzielnie. Może jednak zatrzymać wiadomości lub przerwać próbę. Sprawdzenie wadliwego udziału może wskazać autora, nie zapewnić zakończenia sesji. Nadal potrzebne są uwierzytelniony transport i dostateczna liczba dostępnych uczestników. [RFC 9591 — FROST]
Dla Bitcoin wynik musi spełniać dokładne kodowanie, haszowanie i reguły BIP 340 oraz ewentualne modyfikacje klucza Taproot. Sam wybór secp256k1 w ogólnym zestawie FROST nie wystarcza. ZF udostępnia osobne frost-secp256k1-tr dla Taproot; sprawdź konkretny zestaw i jego testy. Pojedynczy podpis w łańcuchu sam nie ujawnia wewnętrznego progu. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Udział wymaga prawidłowego identyfikatora, publicznych danych grupy i zgodnego oprogramowania. Odzyskanie utraconego udziału z pomocą innych lub odświeżenie udziałów to dodatkowe protokoły, które wdrożenie musi naprawdę obsługiwać. Kopia tego samego udziału nie dodaje niezależnego uczestnika. Kopie zapasowe muszą zachować próg i zapobiegać powrotowi zużytych nonce. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Każdy podpisujący powinien sprawdzić odbiorców, kwoty, opłatę i reguły zatwierdzania, zamiast ślepo podpisywać hash od koordynatora. FROST zapewnia wspólne podpisywanie, nie poprawność zamiaru gospodarczego. Przed użyciem sprawdź wersję implementacji, odzyskiwanie i zachowanie przy awarii; informacyjne RFC nie certyfikuje całego portfela. [RFC 9591 — FROST]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Schnorr signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.