v0.0

에어갭 트랜잭션 서명 플로우 설계서¶

1. Executive Summary¶

본 문서는 D'CENT 엔터프라이즈 콜드월렛 커스터디 솔루션의 핵심 트랜잭션 서명 파이프라인을 설계한다. 에어갭(Air-Gap) 원칙을 준수하면서 엔터프라이즈급 다중 서명 승인 체계를 지원하는 Request-Approve-Sign-Broadcast 4단계 트랜잭션 라이프사이클을 정의한다.

핵심 설계 원칙: - 콜드월렛은 네트워크에 절대 연결되지 않음 (AC-NW-01) - 에어갭 통신은 QR(대시보드↔앱) + USB-C(앱↔콜드월렛)만 허용 (AC-NW-02) - 모든 서명은 하드웨어 SE 내부에서 수행, WYSIWYS 확인 후 물리 버튼 승인 (AC-TX-02) - M-of-N 다중 서명 승인 체계 적용 (AC-TX-01)

3개 컴포넌트 역할: | 컴포넌트 | 환경 | 핵심 역할 | |----------|------|----------| | 온라인 대시보드 | 네트워크 연결 | 트랜잭션 생성, 정책 검증, 서명 취합, 블록체인 전파 | | 오프라인 서명 앱 | 네트워크 차단 | 에어갭 브릿지, 서명 요청 전달, 부분 서명 수집 | | D'CENT X 콜드월렛 | 완전 격리 (SE) | WYSIWYS 표시, 물리 승인, SE 내부 서명 |

2. 트랜잭션 라이프사이클 개요¶

2.1. 4단계 파이프라인¶

┌─────────────────────────────────────────────────────────────────┐
│                    ONLINE ZONE                                   │
│                                                                   │
│  ① REQUEST          ④ BROADCAST                                  │
│  ┌──────────┐       ┌──────────┐                                 │
│  │ 대시보드  │       │ 대시보드  │                                │
│  │ TX 생성   │       │ TX 전파   │                                │
│  │ 정책 검증 │       │ 확인 대기 │                                │
│  └────┬─────┘       └────▲─────┘                                 │
│       │                  │                                        │
│ ══════╧══════════════════╧═══════  에어갭 경계  ═══════════════  │
│                                                                   │
│                 OFFLINE ZONE                                      │
│                                                                   │
│  ② APPROVE          ③ SIGN                                       │
│  ┌──────────┐       ┌──────────┐       ┌──────────┐             │
│  │ 오프라인앱│──────▶│ 오프라인앱│◀─────▶│ 콜드월렛  │            │
│  │ TX 확인   │       │ 서명 요청 │  QR   │ WYSIWYS  │            │
│  │ 승인 결정 │       │ 서명 수집 │ USB-C │ SE 서명   │            │
│  └──────────┘       └──────────┘       └──────────┘             │
│                                                                   │
└─────────────────────────────────────────────────────────────────┘

2.2. 단계별 요약¶

단계	컴포넌트	입력	출력	핵심 활동
① Request	온라인 대시보드	사용자 요청 (수신자, 금액, 자산)	미서명 트랜잭션 (PSBT/EIP-712)	TX 생성, 정책 사전 검증, 승인 요청 라우팅
② Approve	대시보드 + 오프라인 앱	미서명 TX, 승인 요청	승인/거부 결정	승인자 알림, TX 내용 확인, 승인/거부
③ Sign	오프라인 앱 + 콜드월렛	승인된 TX	부분 서명 / 완성 서명	에어갭 전송, WYSIWYS, SE 서명, 서명 반환
④ Broadcast	온라인 대시보드	M개 유효 서명	TX Hash (체인 확인)	서명 취합, TX 완성, 블록체인 전파

3. 각 단계별 상세 설계¶

3.1. Stage 1: Request (트랜잭션 요청)¶

컴포넌트: 온라인 대시보드 수행 역할: Initiator

3.1.1. 워크플로우¶

Initiator 로그인 (MFA)
    │
    ▼
트랜잭션 생성 폼
 - 출금 월렛 선택
 - 수신 주소 입력
 - 금액 / 자산 유형 선택
 - 메모 (선택)
    │
    ▼
정책 사전 검증 (Policy Engine)
 ├─ 화이트리스트 주소 확인 ──▶ 미등록 시 차단 + 등록 안내
 ├─ 금액 한도 확인 ──────────▶ 초과 시 상위 쿼럼 에스컬레이션
 ├─ 시간 기반 제한 확인 ─────▶ 영업시간 외 차단 또는 지연
 └─ 자산 유형 필터 ──────────▶ 차단 자산 시 거부
    │
    ▼
트랜잭션 구성
 - BTC: PSBT (BIP-174/370) 생성 — UTXO 선택, 수수료 산정
 - EVM: EIP-712 TypedData 구성 — Gas 추정, Nonce 설정
    │
    ▼
승인 요청 생성
 - 트랜잭션 ID 부여
 - 필요 승인자 목록 결정 (M-of-N 기반)
 - 승인 마감 시간 설정 (타임아웃)
 - 상태: PENDING_APPROVAL
    │
    ▼
승인자 알림 발송
 - 대시보드 내 알림
 - 이메일/SMS 알림 (선택)

3.1.2. 입력/출력 데이터 포맷¶

입력:

{
  wallet_id: string,          // 출금 월렛 식별자
  chain: "BTC" | "ETH" | ..., // 체인 유형
  to_address: string,          // 수신 주소
  amount: decimal,             // 전송 금액
  asset: string,               // 자산 유형 (BTC, ETH, USDT, ...)
  memo: string (optional),     // 메모
  priority: "normal" | "urgent" // 우선순위
}

출력 (BTC): - PSBT (BIP-174 v0 / BIP-370 v2 호환) - UTXO 입력 목록, 출력 목록, 수수료 정보 포함 - 서명 필드는 비어 있음 (미서명 상태)

출력 (EVM): - EIP-712 구조화 데이터 (RLP 인코딩 전 단계) - to, value, data, gasLimit, maxFeePerGas, nonce 포함

3.1.3. 에러 핸들링¶

에러 유형	처리 방식
화이트리스트 미등록 주소	즉시 차단, 화이트리스트 등록 안내 반환
금액 한도 초과	에스컬레이션: 상위 쿼럼 승인 요구로 전환
잔액 부족	즉시 거부, 현재 잔액 표시
네트워크 수수료 이상	수수료 상한 경고, 사용자 확인 요청
UTXO 선택 실패	대안 UTXO 세트 제시 또는 금액 조정 안내
중복 트랜잭션 감지	경고 표시, 사용자 확인 후 진행

3.1.4. 상태 전이¶

[초기] ──생성──▶ [DRAFT] ──정책통과──▶ [PENDING_APPROVAL]
                    │                         │
                    ▼                         ▼
              [POLICY_REJECTED]        [다음 단계: Approve]

3.2. Stage 2: Approve (승인)¶

컴포넌트: 온라인 대시보드 + 오프라인 서명 앱 수행 역할: Approver

3.2.1. 워크플로우¶

Approver 알림 수신
    │
    ▼
트랜잭션 상세 확인 (대시보드)
 - 수신 주소, 금액, 자산 유형
 - 화이트리스트 상태
 - 정책 검증 결과
 - 이전 승인자 서명 현황 (순차 모드 시)
    │
    ▼
승인 결정
 ├─ 승인 ──▶ 상태: APPROVED (해당 승인자)
 │           ──▶ M개 승인 도달 시: READY_TO_SIGN
 ├─ 거부 ──▶ 상태: REJECTED (사유 기록)
 └─ 보류 ──▶ 상태: ON_HOLD (추가 정보 요청)
    │
    ▼ (READY_TO_SIGN 시)
에어갭 전달 준비
 - 서명 요청 데이터 패키징 (PSBT / EIP-712)
 - QR 코드 생성 (UR 인코딩)

3.2.2. 승인 모드 (다중 서명 워크플로우 참조)¶

순차(Sequential) 모드: 지정 순서대로 승인자가 차례로 승인. 이전 승인자의 승인이 완료되어야 다음 승인자에게 알림 발송.
병렬(Parallel) 모드: 모든 승인자에게 동시에 알림. M개 승인 도달 시 자동 완성.
하이브리드 모드: 1차 계층(순차) 승인 후 2차 계층(병렬) 서명 수집.

3.2.3. 에러 핸들링¶

에러 유형	처리 방식
승인 타임아웃	자동 만료 (기본 24시간), 재요청 필요
승인자 비가용	대체 승인자 자동 지정 (설정 시) 또는 에스컬레이션
중복 승인 시도	거부 + 기존 승인 유지
승인 후 정책 변경	승인 무효화, 재승인 요구

3.2.4. 상태 전이¶

[PENDING_APPROVAL]
    │
    ├─ 승인(1/M) ──▶ [PARTIALLY_APPROVED]
    │                    │
    │                    ├─ 승인(M/M) ──▶ [READY_TO_SIGN]
    │                    │
    │                    └─ 타임아웃 ──▶ [EXPIRED]
    │
    ├─ 거부 ──▶ [REJECTED]
    │
    └─ 보류 ──▶ [ON_HOLD]

3.3. Stage 3: Sign (서명)¶

컴포넌트: 오프라인 서명 앱 + D'CENT X 콜드월렛 수행 역할: Approver (서명자)

3.3.1. 워크플로우¶

[온라인 → 오프라인 전환]

대시보드에서 서명 요청 데이터 표시
 - Animated QR 코드 (UR 인코딩, 대시보드→오프라인 앱)
    │
    ▼
오프라인 앱에서 서명 요청 수신
 - QR 스캔 (카메라)으로 대시보드 데이터 수신
 - 서명 요청 데이터 디코딩 및 검증
 - 트랜잭션 내용 표시 (수신자, 금액, 수수료)
    │
    ▼
[오프라인 앱 → 콜드월렛 전환]

오프라인 앱에서 콜드월렛으로 서명 요청 전달
 - USB-C: 오프라인 앱 → 콜드월렛 (USB-C 케이블 연결)
    │
    ▼
콜드월렛 WYSIWYS 표시 (AC-TX-02)
 - 수신 주소 전체 표시
 - 전송 금액 및 자산 유형
 - 네트워크 수수료
 - 체인 정보
    │
    ▼
물리 버튼 승인
 ├─ 승인 ──▶ SE 내부 서명 수행
 │           ├─ BTC: Schnorr 서명 (BIP-340) 또는 ECDSA
 │           ├─ EVM: ECDSA secp256k1 서명
 │           └─ 서명값 반환
 └─ 거부 ──▶ 서명 거부, 오프라인 앱에 거부 전달
    │
    ▼
[콜드월렛 → 오프라인 앱 반환]

서명값 전달 (USB-C)
 - 콜드월렛 → 오프라인 앱 (USB-C 케이블로 서명값 전송)
    │
    ▼
[오프라인 앱 → 대시보드 반환]

오프라인 앱에서 대시보드로 서명 전달
 - 서명된 PSBT / 서명값을 QR로 대시보드에 전달
 - 대시보드에서 서명 검증 및 저장

3.3.2. 에어갭 데이터 흐름 상세¶

왕복 4단계 에어갭 통신:

방향	경로	데이터	채널
→ (1)	대시보드 → 오프라인 앱	미서명 TX (PSBT/EIP-712)	QR
→ (2)	오프라인 앱 → 콜드월렛	서명 요청 페이로드	USB-C
← (3)	콜드월렛 → 오프라인 앱	부분 서명 (Partial Sig)	USB-C
← (4)	오프라인 앱 → 대시보드	서명 데이터	QR

M-of-N 서명 시: 위 과정을 M명의 서명자가 각각 수행. 다중 서명 수집 흐름은 별도 문서(multisig-workflow.md) 참조.

3.3.3. 에러 핸들링¶

에러 유형	처리 방식
QR 스캔 실패 (대시보드↔앱)	재시도, Animated QR 속도 조절
USB-C 통신 오류 (앱↔콜드월렛)	USB-C 케이블 재연결, 재시도
WYSIWYS 불일치	서명 거부 + 보안 경고 (중간자 공격 의심)
SE 서명 실패	PIN 재입력, 디바이스 상태 점검
부분 서명 검증 실패	해당 서명 폐기, 재서명 요청
서명 세션 타임아웃	세션 만료, 새 서명 요청 필요 (리플레이 방지)

3.3.4. 상태 전이¶

[READY_TO_SIGN]
    │
    ├─ 서명(1/M) ──▶ [PARTIALLY_SIGNED]
    │                    │
    │                    ├─ 서명(M/M) ──▶ [FULLY_SIGNED]
    │                    │
    │                    └─ 타임아웃 ──▶ [SIGN_EXPIRED]
    │
    └─ 서명 거부 ──▶ [SIGN_REJECTED]

3.4. Stage 4: Broadcast (전파)¶

컴포넌트: 온라인 대시보드 수행 역할: 시스템 (자동) 또는 Initiator (수동 확인)

3.4.1. 워크플로우¶

M개 유효 서명 수집 완료
    │
    ▼
서명 취합 및 트랜잭션 완성
 - BTC: PSBT에 모든 부분 서명 병합, 최종 TX 구성
   - MuSig2: 부분 서명 집계 → 단일 Schnorr 서명 생성
   - P2WSH: 각 서명 + redeem script 조합
 - EVM: 서명된 트랜잭션 직렬화 (RLP 인코딩)
    │
    ▼
최종 검증
 - 서명 유효성 검증 (공개키 매칭)
 - 트랜잭션 무결성 검증 (해시 비교)
 - 이중 지출 방지 확인
    │
    ▼
블록체인 전파
 - 노드 연결 (다중 노드 제출 — 안정성)
 - TX 브로드캐스트
    │
    ▼
확인 대기
 - Mempool 진입 확인
 - 블록 포함 확인 (BTC: 1-6 확인, EVM: 12-64 블록)
 - 상태: CONFIRMED
    │
    ▼
완료 처리
 - 감사 로그 기록 (전체 라이프사이클)
 - 잔액 업데이트
 - 관련자 알림

3.4.2. 에러 핸들링¶

에러 유형	처리 방식
노드 연결 실패	대체 노드 자동 전환 (최소 3개 노드 풀)
TX 거부 (인셉선 에러)	에러 코드 분석, UTXO/Nonce 충돌 시 재구성
장시간 미확인	BTC: RBF(Replace-By-Fee) 제안, EVM: Gas 인상 제안
이중 지출 감지	즉시 차단, 보안 알림, 감사 로그
네트워크 혼잡	수수료 재추정, 사용자 확인 후 재전파

3.4.3. 상태 전이¶

[FULLY_SIGNED]
    │
    ├─ 검증 성공 ──▶ [BROADCASTING]
    │                    │
    │                    ├─ 전파 성공 ──▶ [PENDING_CONFIRMATION]
    │                    │                    │
    │                    │                    ├─ 확인 ──▶ [CONFIRMED]
    │                    │                    │
    │                    │                    └─ 실패 ──▶ [FAILED]
    │                    │
    │                    └─ 전파 실패 ──▶ [BROADCAST_FAILED]
    │
    └─ 검증 실패 ──▶ [VALIDATION_FAILED]

4. 에어갭 통신 채널 비교¶

4.1. QR 코드 (UR 표준, Animated QR) — 주 채널¶

표준: Blockchain Commons UR (Uniform Resources) v2 인코딩: CBOR → UR → Animated QR (Fountain 코드 기반 멀티파트)

특징: - 카메라 기반 단방향 통신 — 물리적 연결 없음 - Animated QR: 대용량 데이터를 여러 프레임으로 분할 전송 - PSBT 전체 페이로드 전송 가능 (다중 입력 트랜잭션 포함) - 인간이 통신 과정을 시각적으로 관찰 가능 (inspectable) - Keystone, Sparrow, AirGap Vault 등 주요 에어갭 월렛이 채택

4.2. USB-C — 앱↔콜드월렛 통신 채널¶

표준: USB 2.0/3.0, USB-C 커넥터 D'CENT X 역량: USB-C 포트 내장 (엔터프라이즈 모드에서 Bluetooth 비활성화)

특징: - 유선 연결 기반 — 빠르고 안정적인 데이터 전송 - 오프라인 앱과 콜드월렛이 하나의 오프라인 서명 유닛을 구성 - 대용량 페이로드(PSBT 등) 전송에 제약 없음 - 에어갭 경계는 대시보드↔오프라인 앱 사이에 존재 (QR로 유지)

참고: NFC는 R3covery 카드 전용으로 사용된다 (시드 백업/복구). 서명 통신에는 사용하지 않는다.

4.3. 채널 비교 테이블¶

항목	QR (UR/Animated) — 대시보드↔앱	USB-C — 앱↔콜드월렛
페이로드 크기	수 KB~수십 KB (Animated QR로 무제한 확장)	무제한 (USB 대역폭)
전송 속도	중간 (프레임 수에 비례, 10-30초)	매우 빠름 (즉시)
물리적 연결	없음 (카메라 — 완전 비접촉)	유선 연결 (USB-C 케이블)
검사 가능성	높음 (화면에 QR 표시, 과정 관찰 가능)	중간 (연결 상태 확인 가능)
보안 수준	높음 (시각적 채널, 중간자 공격 어려움)	높음 (물리 연결, 에어갭 앱 전용 디바이스)
다중 입력 TX	적합 (Animated QR로 대용량 PSBT 전송)	적합 (대역폭 무제한)
UX	카메라 정렬 필요, 조명 영향	USB-C 케이블 연결 — 직관적
하드웨어 요구	카메라 + 화면 (양쪽 모두)	USB-C 포트 (양쪽 모두)
표준 생태계	Blockchain Commons UR — 업계 표준화 진행 중	USB 표준 — 성숙한 표준
권장 사용	에어갭 채널 — 대시보드↔앱	디바이스 채널 — 앱↔콜드월렛

4.4. 채널 선택 가이드라인¶

통신 구간	채널	사유
대시보드 → 오프라인 앱	QR (Animated)	에어갭 경계 통과, UR 표준 인코딩
오프라인 앱 → 콜드월렛	USB-C	오프라인 서명 유닛 내부 통신, 대용량 페이로드 제약 없음
콜드월렛 → 오프라인 앱	USB-C	서명 결과 반환, 안정적 전송
오프라인 앱 → 대시보드	QR (Animated)	에어갭 경계 통과, 서명 데이터 반환
정책/설정 동기화	QR + USB-C	대시보드→앱은 QR, 앱→콜드월렛은 USB-C

4.5. 통신 채널 분리 원칙¶

에어갭 경계와 디바이스 통신을 명확히 분리: - 에어갭 경계 (대시보드↔오프라인 앱): QR 코드만 사용 — 물리적 네트워크 격리 보장 - 오프라인 서명 유닛 내부 (오프라인 앱↔콜드월렛): USB-C 케이블 연결 — 하나의 오프라인 서명 유닛으로 동작 - 에어갭 경계에서의 무결성 검증은 QR 채널의 시각적 관찰 가능성에 의존

5. 전체 트랜잭션 상태 머신¶

[DRAFT]
  │
  ├─ 정책 통과 ──▶ [PENDING_APPROVAL]
  │                    │
  │                    ├─ 승인 완료 (M/M) ──▶ [READY_TO_SIGN]
  │                    │                          │
  │                    │                          ├─ 서명 완료 (M/M) ──▶ [FULLY_SIGNED]
  │                    │                          │                          │
  │                    │                          │                          ├─ 전파 성공 ──▶ [PENDING_CONFIRMATION]
  │                    │                          │                          │                    │
  │                    │                          │                          │                    ├─▶ [CONFIRMED]
  │                    │                          │                          │                    └─▶ [FAILED]
  │                    │                          │                          │
  │                    │                          │                          └─ 전파 실패 ──▶ [BROADCAST_FAILED]
  │                    │                          │
  │                    │                          ├─ 부분 서명 (k/M) ──▶ [PARTIALLY_SIGNED]
  │                    │                          │
  │                    │                          └─ 서명 거부/타임아웃 ──▶ [SIGN_EXPIRED]
  │                    │
  │                    ├─ 부분 승인 (k/M) ──▶ [PARTIALLY_APPROVED]
  │                    │
  │                    ├─ 거부 ──▶ [REJECTED]
  │                    │
  │                    └─ 타임아웃 ──▶ [EXPIRED]
  │
  └─ 정책 거부 ──▶ [POLICY_REJECTED]

상태별 허용 액션:

상태	허용 액션	가능 역할
DRAFT	수정, 제출, 삭제	Initiator
PENDING_APPROVAL	승인, 거부, 보류	Approver
PARTIALLY_APPROVED	승인, 거부	미승인 Approver
READY_TO_SIGN	서명 시작	Approver (서명자)
PARTIALLY_SIGNED	서명 추가	미서명 Approver
FULLY_SIGNED	전파 (자동/수동)	System / Initiator
CONFIRMED	조회	모든 역할
REJECTED/EXPIRED	조회, 재요청	Initiator

6. 컴플라이언스 매핑¶

제약조건 ID	설명	충족 방식
AC-TX-01	최소 2-of-N 다중 서명 지원	Stage 2-3에서 M-of-N 승인 및 서명 수집 흐름 구현. 최소 M=2 강제
AC-TX-02	WYSIWYS: 하드웨어 표시 + 물리 승인	Stage 3에서 콜드월렛 디스플레이 표시 후 물리 버튼 승인 필수
AC-NW-01	콜드월렛 네트워크 연결 금지	콜드월렛은 USB-C(앱 경유)로만 데이터 교환, 네트워크 스택 비활성화
AC-NW-02	QR + USB-C만 허용	에어갭 통신은 QR(대시보드↔앱), 디바이스 통신은 USB-C(앱↔콜드월렛)로 제한
AC-AU-01	변조 불가 감사 로그	4단계 각 상태 전이마다 감사 이벤트 생성 및 기록
AC-GV-01	정책 버전 관리	Stage 1 정책 사전 검증 시 적용 정책 버전 기록

7. Phase 5 설계 시 참조사항¶

본 문서는 트랜잭션 서명 플로우의 기능 설계 수준이다. Phase 5 System Architecture Design에서는 다음을 상세 명세해야 한다:

항목	본 문서 수준	Phase 5 상세화 범위
UR 인코딩	표준 참조	CBOR 스키마, UR Type 정의, 메시지 포맷 바이트 수준 명세
USB-C 프로토콜	개념 수준	USB-C 통신 프로토콜, 커맨드셋 정의, 응답 코드 정의
에어갭 데이터 암호화	필요성 언급 (AC-NW-03)	암호화 알고리즘, 키 교환 프로토콜, 무결성 검증 방식
노드 연결	다중 노드 언급	노드 풀 관리, Failover 전략, RPC 인터페이스
상태 저장소	상태 머신 정의	Event Sourcing 구현, 상태 일관성 보장

본 문서는 Phase 3 Core Product Design의 일부로, 다중 서명 워크플로우(multisig-workflow.md) 및 멀티체인 지원(multichain-support.md)과 긴밀히 연계된다. Phase 2 컴플라이언스 매트릭스(compliance-architecture-matrix.md)의 AC-TX, AC-NW 제약조건을 기반으로 설계되었다.