v0.5

FROST(BIP-445) 비교 분석 및 FROST-ready 추상화 계층 설계¶

1. FROST(BIP-445) 표준화 상태 분석¶

1.1. BIP-445 현재 상태¶

항목	상태	비고
BIP 번호	BIP-445	FROST Signing for BIP-340-compatible Threshold Signatures
현재 상태	Draft v0.4.1	2024년 기준, Final 아님
최초 제안	2023년	Tim Ruffing, Jonas Nick 등
기반 암호학	FROST (Flexible Round-Optimized Schnorr Threshold)	Komlo & Goldberg, 2020
Bitcoin Core 통합	미통합	secp256k1-zkp 실험 구현만 존재
실사용 사례	없음 (메인넷)	테스트넷 실험 수준

[risk] BIP-445 Draft v0.4.1 상태 (STATE.md 기록): 즉시 도입 불가. 표준화 완료 전까지 MuSig2(BIP-327 Final)를 기본 프로토콜로 유지한다.

1.2. IETF RFC 9591 관계¶

항목	IETF RFC 9591	BIP-445
범위	일반 FROST (다중 커브)	Bitcoin Schnorr (secp256k1) 특화
서명 형식	Ed25519, P-256, Ristretto255 등	BIP-340 x-only Schnorr 호환
DKG	별도 정의 (RFC 외)	ChillDKG 통합
Taproot 호환	없음	BIP-341 Taproot 직접 호환
관계	BIP-445는 RFC 9591의 secp256k1 특화 프로파일	RFC 9591 기반 + Bitcoin 특화 확장

1.3. Bitcoin 생태계 통합 로드맵¶

단계	프로젝트	현재 상태	예상 시점
1	secp256k1-zkp FROST 모듈	실험 구현	2024~ (진행 중)
2	rust-bitcoin/BDK FROST 지원	미착수	BIP-445 Final 이후
3	Bitcoin Core FROST 서명 지원	미착수	secp256k1-zkp 안정화 이후
4	하드웨어 월렛 FROST 구현	미착수	Bitcoin Core 통합 이후
5	프로덕션 사용	없음	2027~2028년 이후 (보수적 추정)

1.4. 표준화 완료 타임라인 (보수적 추정)¶

마일스톤	예상 시점	근거
BIP-445 Final	2025 H2 ~ 2026 H1	BIP-327 선례: Draft → Final에 약 2년 소요
secp256k1-zkp 안정 릴리스	2026 H1 ~ H2	Final 확정 후 6~12개월
첫 HW 월렛 FROST 구현	2027 H1 ~ H2	라이브러리 안정화 후 12개월
D'CENT FROST 구현 가능 시점	2027 H2 이후	HW 구현 사례 2건 이상 확보 후

결론: BIP-445 FROST의 프로덕션 수준 도입까지 최소 18~24개월이 소요될 것으로 추정된다. 이 기간 동안 MuSig2를 기본 프로토콜로 운용하되, FROST-ready 추상화 계층을 미리 설계하여 전환 비용을 최소화한다.

2. SE 구현 가능성 분석¶

2.1. FROST vs MuSig2 SE 내부 연산 비교¶

2.1.1. MuSig2 (BIP-327) SE 연산¶

Round 1 — Nonce 생성:
  1. SE TRNG → 128비트 랜덤 시드 2개 생성
  2. secp256k1 스칼라 곱셈 2회 (k_i1*G, k_i2*G)
  3. pubnonce = (R_i1, R_i2) 반환, secnonce 저장
  연산량: EC 스칼라 곱셈 2회, ~30ms (EAL5+ SE 기준)

Round 2 — Partial Signature:
  1. 수신된 N개 pubnonce로 aggregated nonce R 계산
  2. 챌린지 e = H(R || P_agg || msg) 계산
  3. s_i = k_i + e * a_i * sk_i (mod n)
  4. secnonce 원자적 삭제
  연산량: EC 연산 1회 + 해시 2회, ~20ms

2.1.2. FROST (BIP-445) SE 연산¶

사전 처리 (Preprocessing) — Nonce 생성:
  1. SE TRNG → 128비트 랜덤 시드 생성
  2. secp256k1 스칼라 곱셈 (d_i*G, e_i*G)
  3. (D_i, E_i) = nonce commitment 반환
  연산량: EC 스칼라 곱셈 2회, ~30ms (MuSig2와 동일)

온라인 서명 (Signing) — Single Round:
  1. binding factor rho_i = H(i || msg || commitments) 계산
  2. R = sum(D_i + rho_i * E_i) 계산 (외부에서 수행 가능)
  3. z_i = d_i + rho_i * e_i + lambda_i * s_i * c (mod n)
     여기서 c = H(R || group_pk || msg), lambda_i = Lagrange 계수
  4. nonce 원자적 삭제
  연산량: EC 연산 1회 + 해시 3회 + 라그랑주 보간 1회, ~25ms

2.1.3. 연산 요구사항 비교¶

항목	MuSig2 (BIP-327)	FROST (BIP-445)
Nonce 생성	EC 곱셈 2회, ~30ms	EC 곱셈 2회, ~30ms
서명 연산	EC 곱셈 1회 + 해시 2회, ~20ms	EC 곱셈 1회 + 해시 3회 + Lagrange 1회, ~25ms
총 SE 연산 시간	~50ms	~55ms
SE 메모리 (secnonce)	~96바이트 (2 스칼라 + 상태)	~96바이트 (2 스칼라 + 상태)
SE 메모리 (키 저장)	master_sk (32B)	key_share_i (32B) + 그룹 정보 (~100B)
추가 SE 메모리	없음	Lagrange 계수 캐시 (~32B x N)

결론: FROST의 SE 연산 요구사항은 MuSig2와 거의 동일하다. secp256k1 기반 Schnorr 서명이라는 공통 기반 덕분에 SE 하드웨어 수준의 변경은 불필요하다. 차이점은 Lagrange 보간 계산과 그룹 정보 저장 정도이다.

2.2. ChillDKG 에어갭 환경 제약¶

FROST는 MuSig2와 달리 분산 키 생성(DKG) 이 필요하다. BIP-445에서 권장하는 ChillDKG 프로토콜:

항목	ChillDKG	에어갭 환경 제약
통신 모델	Broadcast 채널 + 모든 참여자 간 직접 통신	QR/NFC로 N*(N-1) 양방향 교환 필요
라운드 수	3라운드	QR 교환 시 최소 3N(N-1) 회
생성 시간	~수 초 (네트워크)	~수십 분 (QR/NFC, 5-of-7 기준)
동기 요구	모든 참여자 동시 온라인	에어갭에서 동시성 보장 어려움
재시작 가능	라운드별 상태 저장	SE 비휘발성 메모리에 중간 상태 저장 필요

에어갭 DKG 실현 가능성 평가:

정족수	DKG QR 교환 예상	DKG 소요 시간 예상	실용성
2-of-3	~18회	~2분	실용적 (키 세레모니 1회성)
3-of-5	~60회	~7분	수용 가능 (키 세레모니 1회성)
5-of-7	~126회	~15분	도전적 (물리적 집결 필요)

DKG는 키 세레모니 시 1회만 수행하므로, 매 서명마다의 오버헤드는 아니다. 그러나 에어갭 환경에서 N*(N-1) 양방향 통신은 정족수가 커질수록 비실용적이 된다.

대안: Trusted Dealer DKG

Coordinator(오프라인 앱)가 신뢰 딜러로서 마스터 비밀 키를 생성하고 Shamir Secret Sharing으로 분배하는 방식. 에어갭에서는 N회 QR 전달로 단순화되나, Coordinator가 마스터 키를 일시적으로 보유하는 신뢰 모델 약화 문제가 발생한다. D'CENT 엔터프라이즈의 "제3자 없는 셀프 커스터디" 원칙과 충돌 가능성이 있어 신중한 검토가 필요하다.

2.3. 기존 D'CENT SE 펌웨어 변경 범위 추정¶

변경 항목	규모	설명
sign_partial 내부 로직	중	FROST 서명 로직(Lagrange 보간, binding factor) 추가
Nonce 생성	소	FROST nonce commitment 형식 변경 (구조 유사)
키 저장	중	key_share + 그룹 공개 키 + 참여자 목록 저장
DKG 모듈	대	ChillDKG 프로토콜 SE 내부 구현 (신규 모듈)
Nonce 관리	소	delete-on-read + 단조 카운터 동일 적용
총 펌웨어 변경	대	주로 DKG 모듈 신규 개발이 가장 큰 비용

3. 에어갭 호환성 분석¶

3.1. FROST 사전 처리 단계의 에어갭 호환성¶

FROST의 사전 처리(preprocessing)는 서명 대상 메시지 없이 nonce commitment를 생성하는 단계이다:

특성	에어갭 호환성	분석
메시지 독립성	호환	nonce commitment는 msg 없이 생성 가능 (MuSig2 Pre-commitment와 동일 원리)
오프라인 생성	호환	SE 내부에서 독립적으로 생성, 네트워크 불필요
사전 배포	호환	생성된 commitment를 QR/NFC로 사전 배포 가능
유효 기간	제한적	SE 24시간 타임아웃 적용, 사전 생성 후 24시간 내 사용 필요

3.2. DKG 단계의 에어갭 호환성¶

DKG 라운드	통신 요구	에어갭 호환성	비고
Round 1: Commitment 공유	N → All (브로드캐스트)	호환	Coordinator가 수집·재배포
Round 2: Secret Share 전달	각 참여자 → 각 참여자 (P2P)	제한적	N*(N-1) 양방향 QR/NFC 교환 필요
Round 3: 검증 및 확인	All → All (브로드캐스트)	호환	Coordinator가 수집·재배포

DKG의 핵심 제약: Round 2에서 각 참여자가 다른 모든 참여자에게 고유한 secret share를 전달해야 한다. 이를 QR/NFC로 수행하면 N*(N-1)회 교환이 필요하며, 5-of-7 기준 30회 양방향 = 최소 60회 QR 교환이 된다.

완화 방안: Coordinator가 각 참여자의 암호화된 share를 중계하면 교환 횟수를 2N으로 줄일 수 있다. 단, Coordinator가 각 share의 목적지별 공개 키로 암호화된 봉투(encrypted envelope)만 중계하므로 Coordinator가 share 내용을 알 수 없다.

3.3. FROST 단일 온라인 라운드의 QR 교환 영향¶

FROST의 가장 큰 장점은 단일 온라인 라운드이다:

MuSig2: 2라운드 (nonce 교환 + partial sig 교환)
FROST:  1라운드 (사전 nonce 기반 partial sig만 교환)

FROST QR 교환 횟수 (Pre-commitment 포함):

단계	교환 횟수	설명
사전 준비: nonce commitment 수집	t회	t명의 서명자(정족수 참여자)가 commitment 전달
서명 세션: TX + commitments 브로드캐스트	1회	Coordinator → 전체 서명자 동시
서명 세션: partial sig 수집	t회	각 서명자 → Coordinator
총 교환	2t + 1	t = 정족수 threshold

MuSig2(Pre-commit) vs FROST QR 교환 비교:

정족수	MuSig2 Pre-commit (N+1)	FROST (2t+1)	FROST 추가 이점	비고
2-of-3	3회 (N=2)	5회 (t=2)	-2회 (불리)	N-of-N vs t-of-N 차이
3-of-5	4회 (N=3)	7회 (t=3)	-3회 (불리)	MuSig2는 N명만 참여
5-of-7	6회 (N=5)	11회 (t=5)	-5회 (불리)	FROST는 전체 t명 참여

중요 참고: 위 비교는 공정하지 않다. MuSig2는 N-of-N(전원 참여 필수)이고 FROST는 t-of-N(정족수만 참여)이다. MuSig2에서 M-of-N을 구현하려면 Taproot Script Path를 사용해야 하며, 이 경우 각 서명자가 개별 Schnorr 서명을 제출하므로 QR 교환 구조가 다르다. FROST의 진정한 이점은 QR 교환 횟수가 아닌 정족수 유연성(n-of-n 제약 해소)에 있다.

3.4. 에어갭 환경 FROST 유리점/불리점¶

구분	내용
유리점
정족수 유연성	t-of-n 네이티브 지원, 7-of-11 이상 대규모 정족수에서 Taproot Script Tree 조합 폭발 회피
라운드 감소	온라인 1라운드로 MuSig2의 2라운드보다 서명 세션 교환 간소화
단일 주소	t-of-n이 단일 공개 키/주소로 표현, 프라이버시 향상
불리점
DKG 오버헤드	초기 키 세레모니에서 N*(N-1) 양방향 교환 필요 (에어갭 비실용적 가능성)
SE 구현 부재	프로덕션 수준 SE FROST 구현 사례 0건
표준 미확정	BIP-445 Draft 상태, 스펙 변경 가능성
키 마이그레이션	기존 MuSig2 키에서 FROST 키로 전환 프로토콜 미정의
Coordinator 역할	FROST Coordinator가 nonce commitment 배포를 관리, 중앙 집중 위험

4. MuSig2 vs FROST 비교표¶

항목	MuSig2 (BIP-327)	FROST (BIP-445)
표준화 상태	Final (확정)	Draft v0.4.1 (미확정)
서명 라운드 수	2라운드 (nonce + partial sig)	1라운드 (사전 처리 제외)
정족수 모델	N-of-N 전용	t-of-N (유연)
M-of-N 구현	Taproot Script Path (조합 수 C(N,M))	네이티브 (단일 공개 키)
DKG 필요 여부	불필요 (KeyAgg만)	필요 (ChillDKG)
SE 구현 사례	있음 (다수 HW 월렛)	없음 (프로덕션 0건)
SE 연산 시간	~50ms	~55ms
SE 메모리	~130B (키+nonce)	~260B (키+그룹정보+nonce)
QR 교환 (2-of-3, Pre-commit)	3회 (N=2, N-of-N)	5회 (t=2, t-of-N)
QR 교환 (3-of-5, Pre-commit)	4회 (N=3, N-of-N)	7회 (t=3, t-of-N)
QR 교환 (5-of-7, Pre-commit)	6회 (N=5, N-of-N)	11회 (t=5, t-of-N)
에어갭 호환성	검증됨	미검증 (DKG 제약)
DKG 에어갭 교환 (5-of-7)	N/A	~60회+ (비실용적 가능성)
키 교체	키 집계 재계산	DKG 재실행 또는 키 재분배
프라이버시	N-of-N: 단일 키 / M-of-N: 스크립트 노출	항상 단일 키 (최대 프라이버시)
대규모 정족수 (7-of-11+)	비실용적 (C(11,7)=330 리프)	실용적 (네이티브 t-of-n)

5. FROST-ready 추상화 계층 설계¶

5.1. ThresholdSigningProtocol 추상화 인터페이스¶

Phase 24 btc-implementation.md 섹션 7.1에서 정의한 SE sign_partial protocol 추상화를 확장하여, MuSig2와 FROST를 동일 인터페이스로 추상화한다.

┌──────────────────────────────────────────────────────────────┐
│ ThresholdSigningProtocol (추상화 인터페이스)                      │
│                                                                │
│  // 세션 관리                                                   │
│  init_session(                                                 │
│    protocol: MUSIG2 | FROST,                                   │
│    participants: PublicKey[],                                   │
│    threshold: uint                                             │
│  ) -> SessionState                                             │
│                                                                │
│  // Nonce/Commitment 생성                                      │
│  generate_nonce(                                               │
│    session: SessionState                                       │
│  ) -> NonceCommitment                                          │
│    MuSig2: (R_i1, R_i2)                                       │
│    FROST:  (D_i, E_i)                                          │
│                                                                │
│  // 상대방 Commitment 수신                                     │
│  receive_commitments(                                          │
│    session: SessionState,                                      │
│    commitments: NonceCommitment[]                              │
│  ) -> PartialSignRequest                                       │
│    MuSig2: aggregated nonce R 계산                             │
│    FROST:  binding factor 계산                                  │
│                                                                │
│  // 부분 서명 생성                                               │
│  sign_partial(                                                 │
│    session: SessionState,                                      │
│    message: bytes(32)                                          │
│  ) -> PartialSignature                                         │
│    MuSig2: s_i = k_i + e * a_i * sk_i                         │
│    FROST:  z_i = d_i + rho_i * e_i + lambda_i * s_i * c       │
│                                                                │
│  // 서명 집계 (Coordinator에서 실행)                              │
│  aggregate(                                                    │
│    session: SessionState,                                      │
│    partials: PartialSignature[]                                │
│  ) -> FinalSignature                                           │
│    MuSig2: s = sum(s_i), sig = (R, s)                          │
│    FROST:  z = sum(z_i), sig = (R, z)                          │
│                                                                │
│  // 세션 취소                                                    │
│  abort(session: SessionState) -> void                          │
│    공통: nonce 즉시 폐기, 카운터 유지                             │
│                                                                │
│  ┌──────────────────┐    ┌──────────────────┐                  │
│  │  MuSig2Adapter   │    │  FROSTAdapter    │                  │
│  │  (BIP-327)       │    │  (BIP-445)       │ [미래 구현]       │
│  │                  │    │                  │                   │
│  │  KeyAgg          │    │  frost_keygen    │                  │
│  │  NonceGen        │    │  nonce_generate  │                  │
│  │  Sign            │    │  frost_sign      │                  │
│  │  SigAgg          │    │  frost_aggregate │                  │
│  └──────────────────┘    └──────────────────┘                  │
│                                                                │
│  공통: secp256k1 곡선, BIP-340 Schnorr 호환 서명                  │
│  공통: delete-on-read nonce, 단조 카운터, 24시간 타임아웃          │
│  차이: 키 집계 vs DKG, 2라운드 vs 1라운드                         │
└──────────────────────────────────────────────────────────────┘

5.2. 추상화 계층이 커버하는 범위¶

계층	추상화 대상	MuSig2 구현	FROST 구현
SE 내부	sign_partial protocol 파라미터	`protocol: MUSIG2`	`protocol: FROST`
SE 내부	Nonce 생성	MuSig2 NonceGen	FROST nonce_generate
SE 내부	서명 연산	MuSig2 Sign (e * a_i * sk_i)	FROST frost_sign (lambda_i * s_i * c)
오프라인 앱	라운드 관리	2-Pass 배치 또는 Pre-commit	Single-Pass (사전 commitment)
오프라인 앱	서명 집계	MuSig2 SigAgg	FROST frost_aggregate
QR/NFC 전송	데이터 포맷	UR type 45060~45063	동일 UR 타입 재사용
대시보드	TX 생성/전파	변경 없음	변경 없음
ApprovalBundle	승인 서명 구조	변경 없음	변경 없음

핵심: QR/NFC 전송 계층과 ApprovalBundle은 MuSig2와 FROST 모두에서 동일하게 사용된다. 이는 옵션 A의 2단계 분리 설계 덕분으로, 개인 기기 승인(Stage 1)과 콜드월렛 서명(Stage 2)이 독립적이기 때문이다. FROST 전환은 Stage 2의 콜드월렛 간 서명 프로토콜만 영향을 받는다.

5.3. 데이터 호환성¶

MuSig2 배치 전송용 UR 타입(qr-optimization.md에서 정의한 45060~45063)을 FROST에서도 재사용:

UR 타입	MuSig2 용도	FROST 적용	변경 사항
45060 (session-init)	PSBT + 참여자 + 세션	PSBT + 참여자 + 세션	`protocol` 필드 추가
45061 (nonce-response)	pubnonce (66B)	commitment (66B)	필드명 의미만 변경
45062 (round2-init)	pubnonce 세트 + msg	commitment 세트 + msg	구조 동일
45063 (partial-response)	partial_sig (32B)	partial_sig (32B)	구조 동일

UR 타입 확장: 45060에 protocol 필드(1바이트: 0x01=MuSig2, 0x02=FROST)를 추가하면 수신 측이 프로토콜을 자동 식별할 수 있다.

5.4. 전환 시 변경 범위 매트릭스¶

컴포넌트	MuSig2 -> FROST 변경 내용	변경 규모	예상 공수
SE 펌웨어	sign_partial 내부 로직 교체 (Lagrange 보간 추가)	중	3~6개월
SE 펌웨어	DKG 모듈 신규 추가 (ChillDKG)	대	6~12개월
SE 펌웨어	키 저장 구조 확장 (그룹 정보)	소	1개월
오프라인 앱	라운드 관리 로직 변경 (2라운드→1라운드)	소	2~4주
오프라인 앱	DKG Coordinator 로직 추가	중	2~3개월
QR/NFC 전송	UR 타입 protocol 필드 추가 (1바이트)	무	1주
대시보드	변경 없음	무	0
ApprovalBundle	변경 없음	무	0
Approval Verifier	변경 없음	무	0

총 예상 공수: SE 펌웨어 9~18개월 + 오프라인 앱 3~4개월 = 12~22개월. SE DKG 모듈이 가장 큰 개발 항목이며, FROST 서명 로직 자체는 MuSig2와 구조적으로 유사하여 비교적 소규모이다.

6. 전환 로드맵 및 권장사항¶

6.1. 3단계 전환 로드맵¶

Phase 1: 현재 — MuSig2 구현 + FROST-ready 인터페이스 적용¶

항목	내용
기간	즉시 ~ BIP-445 Final
서명 프로토콜	MuSig2 (BIP-327)
추상화	ThresholdSigningProtocol 인터페이스 적용
SE 구현	MuSig2Adapter (protocol: MUSIG2)
QR/NFC	Pre-commitment Pipelining + NFC 고속 교환 (qr-optimization.md)
목표	FROST 전환 시 외부 인터페이스(UR 타입, APDU) 변경 없음 보장

Phase 2: BIP-445 Final 확정 후 — SE FROST 모듈 개발 + 테스트넷 검증¶

항목	내용
기간	BIP-445 Final + 6~12개월
트리거	BIP-445가 BIP Final 상태로 승격
SE 개발	FROSTAdapter (protocol: FROST) + ChillDKG 모듈
검증	Bitcoin 테스트넷에서 t-of-n FROST 서명 검증
병행 운용	MuSig2 프로덕션 유지, FROST 테스트넷 병행
DKG 검증	에어갭 환경 ChillDKG 세레모니 실증

Phase 3: 생태계 성숙 후 — 프로덕션 전환 + MuSig2 폴백 유지¶

항목	내용
기간	Phase 2 완료 + 6~12개월
트리거	SE FROST 구현 사례 2건 이상 + Bitcoin Core 통합
전환	신규 배포는 FROST 기본, 기존 배포는 MuSig2 유지
폴백	protocol 파라미터 전환으로 MuSig2 즉시 복귀 가능
마이그레이션	기존 MuSig2 지갑에서 FROST 지갑으로 자산 이전 절차

6.2. 전환 판단 기준 (Go/No-Go Criteria)¶

FROST 프로덕션 전환을 위해 4가지 조건이 모두 충족되어야 한다:

#	조건	현재 상태	비고
1	BIP-445 Final 확정	미충족 (Draft v0.4.1)	스펙 안정성 보장
2	SE FROST 구현 사례 2건 이상	미충족 (0건)	구현 검증
3	Bitcoin Core 또는 BDK FROST 통합	미충족	생태계 성숙도
4	에어갭 DKG 실증 완료	미충족	D'CENT 환경 검증

6.3. 권장사항 요약¶

현재 시점에서 FROST 도입은 불가하다. BIP-445 Draft 상태, SE 구현 사례 부재, 에어갭 DKG 미검증 3가지 이유로 즉시 도입은 위험하다.
MuSig2를 기본 프로토콜로 확정하고, FROST-ready 추상화 계층을 적용한다. ThresholdSigningProtocol 인터페이스와 UR 타입 protocol 필드를 통해 FROST 전환 시 최소 변경을 보장한다.
FROST의 핵심 이점은 대규모 정족수(7-of-11 이상)에서 발현된다. 5-of-7 이하에서는 MuSig2 + Taproot Script Path가 실용적이며, FROST의 추가 이점이 제한적이다.
DKG 에어갭 호환성이 최대 기술적 과제이다. ChillDKG의 N*(N-1) 양방향 통신은 에어갭 환경에서 정족수 크기에 따라 비실용적일 수 있으며, Trusted Dealer DKG 대안은 보안 모델 약화 문제가 있다.
BIP-445 표준화 진행을 지속 모니터링한다. Draft → Final 승격, secp256k1-zkp FROST 모듈 안정화, 최초 HW 월렛 구현 사례를 추적하여 Phase 2 착수 시점을 결정한다.

설계 기준: Phase 24 btc-implementation.md 섹션 7 FROST 전환 대비 추상화 참조: BIP-327 (MuSig2), BIP-445 (FROST), IETF RFC 9591, BIP-340 (Schnorr), BIP-341 (Taproot) 위험 기록: STATE.md [risk] BIP-445 FROST Draft v0.4.1 상태 — 즉시 도입 불가