FROST는 Flexible Round-Optimized Schnorr Threshold의 약자입니다. 충분한 참여자가 공통 공개키 아래에서 서명하는 임계값 서명 프로토콜로, 서명 중 전체 비밀키를 한곳에 복원하지 않습니다.
2-of-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 키 조정을 따라야 합니다. 일반 FROST 암호 모음에서 secp256k1을 고르는 것만으로는 부족합니다. ZF는 Taproot용 frost-secp256k1-tr을 별도로 제공합니다. 구체적인 모음과 테스트를 검증해야 합니다. 온체인 서명 하나만으로 내부 임계값이 드러나지는 않습니다. [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.