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.