v0.0

M-of-N 다중 서명 승인 워크플로우 설계서¶

1. Executive Summary¶

본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 M-of-N 다중 서명 승인 워크플로우를 설계한다. 체인 유형별 최적 다중 서명 방식을 결정하고, 서명 수집 흐름(순차/병렬/하이브리드), 임계값 검증, 타임아웃 정책, 서명자 관리, 긴급 승인 체계, 에어갭 환경에서의 서명 수집 흐름을 상세히 정의한다.

핵심 설계 결정: - Bitcoin: MuSig2 (BIP-327) — N-of-N Schnorr 집계 서명. 온체인 효율 극대화, 프라이버시 보장 - EVM 체인: Smart Contract Multisig (Safe 기반) — M-of-N 유연성, ERC-4337 통합 가능 - Cross-chain 확장: MPC-TSS — Phase 4 EXT-02 범위에서 설계 (본 문서에서는 방향성만 언급)

제외 방식 (CLAUDE.md 준수): - Shamir's Secret Sharing (SSS): 키 복구 시 전체 시크릿 재구성 → 단일 장애점 → 서명 키 분할에 사용 금지 - 전통적 P2SH/P2WSH 멀티시그: 높은 수수료, 온체인 프라이버시 노출, 경쟁사 대비 기술 열위

2. 다중 서명 방식 결정 프레임워크¶

2.1. 체인별 다중 서명 방식 매핑¶

체인 유형	다중 서명 방식	구조	온체인 표현	프라이버시
Bitcoin	MuSig2 (BIP-327)	N-of-N	단일 Schnorr 서명 (64 bytes)	높음 (일반 TX와 구분 불가)
Ethereum (EVM)	Smart Contract Multisig (Safe)	M-of-N	컨트랙트 호출 (execTransaction)	중간 (컨트랙트 주소 공개)
Cross-chain	MPC-TSS (향후)	T-of-N	단일 서명 (체인 무관)	높음

2.2. 의사결정 매트릭스¶

평가 기준	MuSig2 (BTC)	Smart Contract (EVM)	MPC-TSS	P2SH Multisig (레거시)
온체인 효율	최고 (단일 서명)	높음 (컨트랙트 1회 호출)	최고 (단일 서명)	낮음 (M개 서명 + 스크립트)
프라이버시	최고 (구분 불가)	중간 (Safe 주소 공개)	높음	낮음 (멀티시그 가시)
유연성 (M-of-N)	제한 (N-of-N만)	높음 (자유로운 M/N)	높음 (T-of-N)	높음 (자유로운 M/N)
구현 복잡성	높음 (2라운드 프로토콜)	중간 (검증된 컨트랙트)	매우 높음	낮음
에어갭 호환성	높음 (PSBT + BIP-373)	높음 (EIP-712 서명)	중간 (인터랙티브)	높음
생태계 성숙도	성숙 (Ledger 구현 완료)	매우 성숙 (Safe: $100B+)	성숙 (Fireblocks 등)	레거시
D'CENT 선택	BTC 주 방식	EVM 주 방식	Phase 4 범위	미채택

2.3. Bitcoin MuSig2 심화: N-of-N 제약과 대응¶

MuSig2의 N-of-N 제약: MuSig2는 구조적으로 N-of-N만 지원한다. 모든 서명자가 참여해야 집계 서명이 완성된다.

엔터프라이즈에서의 M-of-N 니즈 대응: | 전략 | 설명 | 적합 시나리오 | |------|------|-------------| | 키 트리 (Taproot) | 복수의 N-of-N MuSig2 키를 Taproot 스크립트 트리에 조합 | 2-of-3: {AB, AC, BC} 3개 MuSig2 리프 | | 정책 기반 보완 | N-of-N MuSig2 + 대시보드 정책 엔진으로 승인 통제 | 모든 서명자가 참여하되, 정책으로 불필요 서명자 승인 면제 | | 레거시 폴백 | 복잡한 M-of-N이 필수인 경우 P2WSH 멀티시그 사용 | 호환성 우선 시나리오 |

권장: 키 트리(Taproot Script Path) 방식으로 M-of-N을 구현. 온체인에서는 사용된 리프의 MuSig2 서명만 노출되어 효율과 프라이버시를 모두 확보.

3. M-of-N 승인 워크플로우 상세¶

3.1. 서명 수집 모드¶

3.1.1. 순차(Sequential) 모드¶

승인 요청 생성
    │
    ▼
승인자 1 (최고 직급) ──승인──▶ 기록
    │                              │
    ▼                              ▼
승인자 2 (차상위) ──────승인──▶ 기록
    │                              │
    ▼                              ▼
승인자 3 ──────────────승인──▶ 기록
    │
    ▼
M개 승인 도달 → 서명 수집 시작

특징: - 지정된 순서대로 승인자가 차례로 승인 - 이전 승인자가 완료해야 다음 승인자에게 알림 발송 - 적합: 계층적 통제 구조, 금액 기반 에스컬레이션 (CEO → CFO → 재무담당) - 단점: 총 소요 시간 = 각 승인자 응답 시간의 합

순서 결정 기준: | 기준 | 설명 | |------|------| | 역할 계층 | Super Admin → Admin → Approver 순 | | 금액 기반 | 고액: CFO 우선 → CTO → CISO | | 지정 순서 | 정책에서 명시적 순서 지정 |

3.1.2. 병렬(Parallel) 모드¶

승인 요청 생성
    │
    ├──▶ 승인자 1 ──승인──▶ ┐
    ├──▶ 승인자 2 ──승인──▶ ├──▶ M개 도달 → 완성
    ├──▶ 승인자 3 ──승인──▶ ┘
    └──▶ 승인자 4 ──대기──▶ (이미 M개 도달, 불필요)

특징: - 모든 승인자에게 동시에 알림 발송 - 가장 먼저 응답하는 M명의 승인으로 완성 - 적합: 속도 우선, 동일 권한 수준의 승인자 그룹 - 단점: 승인 순서 통제 불가, 특정 인원의 필수 참여 보장 어려움

3.1.3. 하이브리드 모드¶

1차 승인 계층 (순차)
    │
    ▼
관리자 승인 (1명 필수) ──승인──▶
    │
    ▼
2차 서명 계층 (병렬)
    │
    ├──▶ 서명자 A ──서명──▶ ┐
    ├──▶ 서명자 B ──서명──▶ ├──▶ M-1개 서명 도달 → 완성
    └──▶ 서명자 C ──서명──▶ ┘

특징: - 1차 계층: 관리자/고위 승인자의 순차 승인으로 거버넌스 통제 - 2차 계층: 일반 서명자의 병렬 서명 수집으로 속도 확보 - 적합: 거버넌스 + 효율 동시 요구, 대부분의 엔터프라이즈 시나리오 - 권장: 기본 서명 수집 모드로 하이브리드 모드 설정

3.2. 임계값(Threshold) 검증 로직¶

3.2.1. 검증 프로세스¶

서명 수신 시:
  1. 서명자 인증 확인 (유효한 Approver 역할 + 활성 상태)
  2. 서명 유효성 검증 (공개키 매칭, 데이터 무결성)
  3. 중복 서명 확인 (동일 서명자의 이중 서명 방지)
  4. 임계값 카운터 증가 (approved_count += 1)
  5. 임계값 도달 확인 (approved_count >= M)
     ├─ 미도달: 다음 승인자 대기
     └─ 도달: 상태 전이 → READY_TO_SIGN 또는 FULLY_SIGNED

3.2.2. 임계값 설정 정책¶

M-of-N 설정	적합 시나리오	최소 보안 수준
2-of-3	소규모 기업, 일상 운영	기본 (AC-TX-01 최소 충족)
3-of-5	중견 기업, 중요 자산 관리	높음
4-of-7	대기업, 고가 자산	매우 높음
5-of-9	기관 투자자, 수탁 서비스	최고

제약 조건: - M >= 2 (AC-TX-01: 최소 2-of-N 필수) - N >= M + 1 (1명 이상의 여유 서명자 보장 — 가용성) - N <= 15 (에어갭 서명 수집의 실용적 한계)

3.3. 타임아웃 정책¶

3.3.1. 단계별 타임아웃¶

단계	기본 타임아웃	설정 범위	초과 시 처리
승인 대기 (Approve)	24시간	1시간-7일	자동 만료 → EXPIRED
서명 대기 (Sign)	4시간	30분-24시간	자동 만료 → SIGN_EXPIRED
전체 트랜잭션	48시간	2시간-14일	자동 만료 → EXPIRED
긴급 트랜잭션	2시간	15분-4시간	자동 만료 + 에스컬레이션

3.3.2. 타임아웃 처리 흐름¶

타임아웃 발생
    │
    ├─ 일반 트랜잭션:
    │   ├─ 자동 만료
    │   ├─ Initiator에게 알림
    │   ├─ 감사 로그 기록 (만료 사유, 미승인 승인자 목록)
    │   └─ 재요청 가능
    │
    └─ 긴급 트랜잭션:
        ├─ 에스컬레이션: 상위 관리자에게 긴급 알림
        ├─ 대체 승인자 자동 지정 (설정 시)
        └─ 감사 로그 기록 (에스컬레이션 이력)

3.4. 서명 순서 정책¶

옵션	설명	적합 시나리오
고정 순서	정책에 정의된 순서로만 서명 가능	규제 요구, 순차 에스컬레이션
자유 순서	서명자 순서 무관, M개 도달 시 완성	글로벌 팀, 시간대 다양
조건부 순서	특정 역할(예: CISO)은 반드시 포함, 나머지 자유	거버넌스 필수 인원 + 유연성

권장: 조건부 순서를 기본 정책으로 채택. 특정 필수 서명자(mandatory signer)를 지정하되, 나머지 M-1명은 자유 순서로 수집.

4. 서명자 관리¶

4.1. 서명자 추가¶

Admin이 서명자 추가 요청
    │
    ▼
관리자 쿼럼 승인 (AC-AC-03)
 - 최소 2명의 Admin 승인
    │
    ▼
키 세레모니 실행 (key-ceremony.md 참조)
 - 새 서명자의 콜드월렛에서 키 생성
 - 공개키 수집 및 검증
    │
    ▼
다중 서명 월렛 재구성
 - BTC: Taproot 스크립트 트리 업데이트 (새 MuSig2 리프 추가)
 - EVM: Safe 소유자 목록에 추가 (addOwnerWithThreshold)
    │
    ▼
테스트 트랜잭션 실행
 - 소액 전송으로 새 서명자 참여 검증
    │
    ▼
감사 로그 기록
 - 서명자 추가 이벤트, 승인자 목록, 타임스탬프

4.2. 서명자 제거¶

Admin이 서명자 제거 요청 (예: 퇴사, 역할 변경)
    │
    ▼
관리자 쿼럼 승인
    │
    ▼
즉시 조치:
 - 해당 서명자의 대시보드/오프라인앱 접근 해제
 - 대기 중인 해당 서명자의 승인/서명 무효화
    │
    ▼
키 로테이션 실행 (AC-KM-07)
 - BTC: 새 키 세트로 자산 이전 (제거된 서명자의 키 포함 주소에서 새 주소로)
 - EVM: Safe에서 소유자 제거 (removeOwner) + 임계값 조정
    │
    ▼
디바이스 회수 및 보안 삭제
 - 콜드월렛 회수 (가능 시)
 - SE 보안 삭제 수행 (AC-KM-06)
    │
    ▼
감사 로그 기록

4.3. 임계값(M) 변경¶

Admin이 임계값 변경 요청
    │
    ▼
변경 영향 분석 (대시보드 정책 시뮬레이션)
 - 현재 M: 2, 요청 M: 3
 - 현재 대기 트랜잭션 영향 평가
    │
    ▼
관리자 쿼럼 승인 (현재 임계값 기준으로 승인)
    │
    ▼
다중 서명 구성 업데이트
 - BTC: Taproot 스크립트 트리 재구성
 - EVM: Safe changeThreshold() 호출
    │
    ▼
기존 대기 트랜잭션 처리
 - 새 임계값 미달 트랜잭션: 추가 승인 요청
 - 새 임계값 초과 트랜잭션: 이미 충족, 변경 없음

4.4. 대체 서명자 (Backup Signer)¶

항목	설명
지정 방식	각 주 서명자에 대해 1명의 대체 서명자 사전 지정
활성화 조건	주 서명자 비가용 선언 (Admin 승인)
권한 범위	주 서명자와 동일한 서명 권한 (임시)
기간 제한	최대 30일 (연장 시 Admin 재승인)
감사	대체 서명자 활성화/비활성화 전 과정 기록
키 관리	대체 서명자는 별도 콜드월렛 + 키 세트 보유 (주 서명자 키 공유 아님)

5. 긴급 승인 체계¶

5.1. 긴급 트랜잭션 정의 기준¶

기준	임계값	비고
보안 위협 감지	즉시	키 노출 의심, 해킹 시도 감지
시장 급변	관리자 판단	대규모 가격 변동 시 긴급 포지션 조정
규제 명령	즉시	자산 동결/이전 명령
운영 장애	4시간 이내	디바이스 장애로 인한 긴급 복구

5.2. 긴급 승인 절차¶

긴급 트랜잭션 요청 (priority: "urgent")
    │
    ▼
정책 엔진 — 긴급 모드 활성화
 - 시간 기반 제한 해제
 - 쿨다운 기간 스킵
 - 타임아웃 단축 (2시간)
    │
    ▼
축소 쿼럼 적용
 - 일반: 3-of-5 → 긴급: 2-of-5 (최소 M=2 유지)
 - 또는: 긴급 키 세트 사용 (별도 2-of-3 긴급 월렛)
    │
    ▼
긴급 서명 수집 (병렬 모드 강제)
    │
    ▼
전파 후 사후 의무:
 - 24시간 내 전체 Admin에게 긴급 트랜잭션 보고
 - 감사 로그에 긴급 사유, 축소 쿼럼 근거 기록
 - 72시간 내 사후 감사 완료

5.3. 보안 트레이드오프 명시¶

긴급 조치	보안 영향	완화 방안
축소 쿼럼	공모 위험 증가	최소 M=2 유지, 사후 감사 의무화
시간 제한 해제	소셜 엔지니어링 공격 창 확대	긴급 TX 별도 감사 추적
쿨다운 스킵	연속 공격 위험	긴급 TX 횟수 제한 (24시간 내 최대 3건)
긴급 키 세트	키 관리 복잡성 증가	긴급 키 세트 별도 보관, 정기 점검

6. 에어갭 환경에서의 서명 수집 흐름¶

6.1. 단일 서명자 흐름 (기본)¶

대시보드 ──QR──▶ 오프라인앱 ──QR──▶ 콜드월렛
                                        │
                                    [SE 서명]
                                        │
대시보드 ◀──QR── 오프라인앱 ◀──QR── 콜드월렛

4회 에어갭 통신 (왕복 2회)

6.2. M-of-N 서명 수집 흐름¶

방식 A: 중앙 수집 (권장)¶

대시보드: 미서명 TX 표시 (QR)
    │
    ├─▶ 서명자 1: 오프라인앱A → 콜드월렛1 → 서명1 → 오프라인앱A → 대시보드
    │
    ├─▶ 서명자 2: 오프라인앱B → 콜드월렛2 → 서명2 → 오프라인앱B → 대시보드
    │
    └─▶ 서명자 3: 오프라인앱C → 콜드월렛3 → 서명3 → 오프라인앱C → 대시보드

대시보드: M개 서명 수집 완료 → 취합 → Broadcast

장점: 대시보드가 중앙 허브 역할, 서명 상태 추적 용이 적합: 서명자들이 같은 장소 또는 네트워크 접근 가능

방식 B: 릴레이 수집¶

오프라인앱: 미서명 TX 수신 (대시보드에서 QR)
    │
    ▼
서명자 1: 오프라인앱 → 콜드월렛1 → 부분서명1 → 오프라인앱
    │
    ▼ (오프라인앱이 부분서명1을 포함한 QR 생성)
서명자 2: 오프라인앱 → 콜드월렛2 → 부분서명2 → 오프라인앱
    │
    ▼ (오프라인앱이 부분서명1+2를 포함한 QR 생성)
서명자 3: 오프라인앱 → 콜드월렛3 → 부분서명3 → 오프라인앱
    │
    ▼
M개 서명 수집 완료 → 오프라인앱 → 대시보드로 반환 → Broadcast

장점: 오프라인 환경에서 순차적으로 서명 수집 가능 적합: 서명자들이 동일 물리적 위치에서 차례로 서명하는 세레모니 환경

방식 C: 분산 비동기 수집¶

대시보드: 미서명 TX + 고유 세션 ID 표시
    │
    ├─▶ 서명자 1 (서울): 자신의 오프라인앱으로 QR 스캔 → 콜드월렛 서명 → 대시보드 반환
    ├─▶ 서명자 2 (싱가포르): 자신의 오프라인앱으로 QR 스캔 → 콜드월렛 서명 → 대시보드 반환
    └─▶ 서명자 3 (런던): 자신의 오프라인앱으로 QR 스캔 → 콜드월렛 서명 → 대시보드 반환

대시보드: 비동기적으로 서명 수신 → M개 도달 시 완성

장점: 글로벌 팀, 서로 다른 시간대의 서명자 지원 적합: 일상적 운영, 긴급하지 않은 트랜잭션

6.3. MuSig2 에어갭 서명 흐름 (Bitcoin 전용)¶

MuSig2는 2라운드 인터랙티브 프로토콜이므로, 에어갭 환경에서 추가 통신이 필요하다.

Round 1: Nonce 교환 (에어갭 1회 추가)

대시보드: MuSig2 세션 시작
    │
    ├─▶ 서명자 1: 콜드월렛1에서 nonce_1 생성 → QR → 대시보드
    ├─▶ 서명자 2: 콜드월렛2에서 nonce_2 생성 → QR → 대시보드
    └─▶ 서명자 N: 콜드월렛N에서 nonce_N 생성 → QR → 대시보드

대시보드: 모든 nonce 수집 → aggregated_nonce 계산
    │
    ▼
Round 2: 부분 서명 (에어갭 1회)

대시보드: TX + aggregated_nonce QR 표시
    │
    ├─▶ 서명자 1: 콜드월렛1에서 partial_sig_1 생성 → QR → 대시보드
    ├─▶ 서명자 2: 콜드월렛2에서 partial_sig_2 생성 → QR → 대시보드
    └─▶ 서명자 N: 콜드월렛N에서 partial_sig_N 생성 → QR → 대시보드

대시보드: 모든 partial_sig 수집 → 최종 Schnorr 서명 집계 → Broadcast

에어갭 통신 횟수: 서명자당 4회 (nonce 반환 + nonce 수신 + 부분 서명 반환 + TX 수신) = 총 4N회 BIP-373: PSBT 내 MuSig2 데이터(participant keys, public nonces, partial signatures) 포함하여 상태 추적

6.4. 부분 서명(Partial Signature) 관리¶

항목	설명
저장 위치	대시보드 서버 (암호화 저장)
유효 기간	서명 세션 타임아웃까지 (기본 4시간)
검증	수신 즉시 공개키 매칭 + 데이터 무결성 검증
상태 추적	서명자별 서명 상태 실시간 표시 (대기/완료/만료)
폐기	세션 만료 시 모든 부분 서명 즉시 폐기 (리플레이 방지)
MuSig2 Nonce	일회용 — 동일 nonce 재사용 시 프라이빗 키 노출 위험. 콜드월렛 SE에서 nonce 재사용 방지 필수

7. 컴플라이언스 매핑¶

제약조건 ID	설명	충족 방식
AC-TX-01	최소 2-of-N 다중 서명 지원	M >= 2 강제. BTC(MuSig2), EVM(Safe) 모두 2-of-N 이상 지원
AC-AC-03	관리자 쿼럼 승인 기반 권한 변경	서명자 추가/제거, 임계값 변경 시 Admin 쿼럼 승인 필수
AC-KM-07	키 로테이션/교체 절차	서명자 교체 시 키 로테이션 연계. BTC: 자산 이전, EVM: Safe 소유자 변경
AC-AU-01	변조 불가 감사 로그	모든 승인/서명/서명자 관리 액션에 감사 이벤트 생성
AC-GV-02	정책 변경 쿼럼 승인	서명 정책(모드, 임계값, 타임아웃) 변경 시 Admin 쿼럼 승인

8. 설계 갭 및 Phase 4-5 연계 사항¶

갭	해당 Phase	설명
MPC-TSS 웜 월렛	Phase 4 (EXT-02)	Cross-chain T-of-N 서명. 본 문서에서는 방향성만 언급
하드웨어 정책 엔진	Phase 4 (DIF-02)	SE에서 정책 위반 TX 거부 — MuSig2 nonce 생성 전 정책 검증
UR PSBT 스키마 상세	Phase 5 (SYS-02)	MuSig2 + BIP-373 PSBT의 UR 인코딩 바이트 수준 명세
Safe 컨트랙트 배포 전략	Phase 5 (SYS-06)	Safe 프록시 배포, 모듈 설정, Gas 최적화

본 문서는 Phase 3 Core Product Design의 일부로, 에어갭 서명 플로우(airgap-signing-flow.md)의 Sign 단계에서 다중 서명 수집 워크플로우를 트리거한다. 멀티체인 지원(multichain-support.md)의 체인별 서명 방식(MuSig2/Safe/MPC-TSS) 결정이 본 문서의 기반이다.