v0.6
Proof of Cold Storage 보고서 구조 및 SE 서명 자동 증명 설계¶
1. 개요¶
1.1. Proof of Cold Storage (PoCS)의 목적¶
D'CENT Enterprise는 에어갭 아키텍처를 통해 모든 키와 서명 연산을 네트워크에서 완전히 격리된 SE(Secure Element)에서 처리한다. 이는 구조적으로 100% 콜드 보관을 달성하지만, "100% 콜드임을 암호학적으로 증명"하는 메커니즘이 별도로 필요하다. 이것이 Proof of Cold Storage(PoCS) 보고서의 목적이다.
1.2. 규제 근거¶
| 규제 조항 | 요건 | PoCS 대응 |
|---|---|---|
| CORE-02 | 콜드 보관 비율 의무 | 관할별 비율(80%/95%/90%) 충족 증명 |
| DELTA-KR-01 | 한국 콜드 보관 비율 80% | 금감원 분기 보고 포맷 |
| DELTA-JP-01 | 일본 콜드 보관 비율 95% | JFSA 분기 보고, 10년 보존 |
| DELTA-SG-01 | 싱가포르 콜드 보관 비율 90% | MAS TRM 반기 보고 포맷 |
| REG-EU-02 | MiCA 자산 분리 보관 | PoCS를 자산 분리 증빙으로 활용 |
| REG-KR-04 | Proof of Reserve 리포트 | PoCS가 PoR을 포함 (콜드 = 100%) |
1.3. D'CENT 에어갭 아키텍처의 구조적 이점¶
일반 커스터디 솔루션:
총 자산 = 핫월렛 자산 + 콜드월렛 자산
cold_ratio = 콜드월렛 자산 / 총 자산
-> 비율 관리 필요, hot/cold 재배분 로직 필요
D'CENT Enterprise (에어갭):
총 자산 = SE 관리 자산 (100% 콜드)
핫월렛 = 0 (에어갭이므로 핫월렛 존재 불가)
cold_ratio = SE 관리 자산 / 총 자산 = 100%
-> 항상 모든 관할 요건 초과 충족
-> PoCS는 "100% 콜드"를 증명하는 증빙 역할
2. SE 서명 기반 증명 메커니즘¶
2.1. 증명 원리¶
PoCS의 핵심은 SE에 저장된 암호학적 증거를 통해 "모든 서명이 에어갭 환경에서만 수행되었음"을 증명하는 것이다.
증명 논리:
1. SE의 sign_counter는 단조 증가하며, SE 내부에서만 갱신된다
2. SE는 네트워크에 연결되지 않는 에어갭 환경에만 존재한다
3. 따라서 sign_counter > 0은 "서명이 콜드 환경에서 수행됨"의 증거이다
4. SE가 관리하는 키의 주소에 잔액이 있으면, 해당 자산은 콜드 보관 상태이다
5. 핫월렛이 존재하지 않으므로 cold_ratio = 100%이다
증거 체인:
SE 물리적 격리 (에어갭)
└─> SE만 서명 가능 (키가 SE에만 존재)
└─> sign_counter가 SE에서만 증가
└─> 모든 서명 = 콜드 서명
└─> 해당 키의 자산 = 100% 콜드 자산
└─> cold_ratio = 100% >= 80%/95%/90%
2.2. 증명 데이터 흐름¶
┌─────────────┐ ┌──────────────┐ ┌─────────────────────┐
│ SE (Zone 3) │ │ 오프라인 앱 │ │ 대시보드 (Zone 1) │
└──────┬──────┘ │ (Zone 2) │ └──────┬──────────────┘
│ └──────┬───────┘ │
│ │ 1. 보고서 생성 트리거
│ │ (분기/반기 스케줄)
│ │ │
│ │ 2. 온체인 총 자산 잔액 조회
│ │ (블록체인 노드/API)
│ │ │
│ │ ◄── 3. SE 데이터 수집 요청 ──
│ │ │
│ 4. READ_AUDIT_DIGEST │
│◄──────────────────│ │
│ │ │
│ SEAuditDigest 128B│ │
│──────────────────►│ │
│ │ │
│ 5. SE ATTESTATION │ │
│ (managed_addresses │
│ + attestation_sig) │
│◄──────────────────│ │
│ │ │
│ 서명된 증명 데이터 │ │
│──────────────────►│ │
│ │ │
│ │── 6. QR/NFC 전달 ──►│
│ │ (SEAttestation) │
│ │ │
│ │ 7. PoCS 보고서 조립:
│ │ - SE 증명 + 온체인 잔액
│ │ - cold_ratio 계산
│ │ - 관할별 비교
│ │ │
│ │ 8. 보고서 서명 + 저장
│ │ (3단계 아카이빙)
└──────────────────┘└─────────────────────┘
3. PoCS 보고서 구조 (CDDL)¶
3.1. 메인 보고서 스키마¶
; ====================================================================
; D'CENT Enterprise Proof of Cold Storage Report Schema
; Phase: 30-audit-architecture
; ====================================================================
ProofOfColdStorage = {
report_id: bstr .size 16, ; UUID
report_version: uint, ; 보고서 스키마 버전
generated_at: uint, ; 생성 시점 (epoch seconds)
reporting_period: ReportingPeriod, ; 보고 대상 기간
jurisdiction: tstr, ; 관할 코드 ("KR" / "JP" / "SG" / "EU" / "US")
required_ratio: float16, ; 의무 비율 (0.80 / 0.95 / 0.90 / 0.00)
asset_summary: AssetSummary, ; 자산 요약
se_attestations: [+ SEAttestation], ; SE별 증명 데이터 (1개 이상)
chain_snapshots: [+ ChainSnapshot], ; 온체인 잔액 스냅샷 (1개 이상)
compliance_result: ComplianceResult, ; 규제 준수 결과
report_sig: bstr .size 64, ; 대시보드 서명 (보고서 무결성)
}
ReportingPeriod = {
start: uint, ; 보고 시작 (epoch seconds)
end: uint, ; 보고 종료 (epoch seconds)
}
3.2. 자산 요약 스키마¶
AssetSummary = {
total_assets_usd: uint, ; 총 자산 (USD 환산, 센트 단위)
cold_assets_usd: uint, ; 콜드 보관 자산 (SE 관리)
hot_assets_usd: uint, ; 핫 보관 자산 (에어갭 구조에서 = 0)
actual_ratio: float16, ; cold_assets / total_assets
asset_breakdown: [+ AssetBreakdown], ; 체인별 자산 상세
}
AssetBreakdown = {
chain: tstr, ; 블록체인 ("BTC" / "ETH" 등)
total_balance: uint, ; 총 잔액 (최소 단위)
total_usd: uint, ; USD 환산 (센트 단위)
address_count: uint, ; 관리 주소 수
se_device_count: uint, ; 관리 SE 기기 수
}
3.3. SE 증명 스키마¶
SEAttestation = {
device_id: bstr .size 8, ; SE 기기 식별자
se_digest: SEAuditDigest, ; 128B 스냅샷 (현재 상태)
managed_addresses: [+ tstr], ; 이 SE가 관리하는 주소 목록
managed_value_usd: uint, ; 해당 주소들의 총 가치 (USD 센트)
sign_count_period: uint, ; 보고 기간 내 서명 횟수
last_sign_time: uint, ; 마지막 서명 시점 (epoch seconds)
attestation_sig: bstr .size 64, ; SE 서명 (아래 증명 대상)
}
; attestation_sig 서명 대상:
; SHA-256(device_id || managed_addresses_hash || managed_value_usd || sign_count_period)
; managed_addresses_hash = SHA-256(CBOR([managed_addresses]))
SEAttestation의 증명력:
- se_digest.sign_counter: SE에서 수행된 전체 서명 횟수 (단조 증가, 변조 불가)
- sign_count_period: 보고 기간 내 서명 횟수 (이전/현재 sign_counter 차이)
- managed_addresses: SE 키에서 파생된 주소 목록 (키 파생 경로로 검증 가능)
- attestation_sig: SE 개인키로 서명한 증명 -> SE 외부에서 생성 불가
3.4. 온체인 스냅샷 스키마¶
ChainSnapshot = {
chain: tstr, ; 블록체인 네트워크
block_height: uint, ; 스냅샷 시점의 블록 높이
timestamp: uint, ; 블록 타임스탬프
address: tstr, ; 조회 대상 주소
balance: uint, ; 잔액 (최소 단위: satoshi, wei 등)
balance_usd: uint, ; USD 환산 (센트)
price_source: tstr, ; 환율 출처 ("CoinGecko" / "CMC" 등)
? snapshot_proof: bstr, ; Merkle proof (선택, 검증 가능한 경우)
}
3.5. 규제 준수 결과 스키마¶
ComplianceResult = {
passed: bool, ; 규제 준수 여부
actual_ratio: float16, ; 실제 콜드 비율 (= 1.0 in airgap)
required_ratio: float16, ; 의무 비율
margin: float16, ; actual - required (양수 = 초과 충족)
notes: [* tstr], ; 주석 목록
? exceptions: [* ComplianceException], ; 예외 사항 (있는 경우)
}
ComplianceException = {
type: tstr, ; 예외 유형
description: tstr, ; 설명
mitigation: tstr, ; 완화 조치
}
4. 관할별 보고서 파라미터¶
4.1. 파라미터 매트릭스¶
| 파라미터 | 한국 (DELTA-KR-01) | 일본 (DELTA-JP-01) | 싱가포르 (DELTA-SG-01) | EU (MiCA) |
|---|---|---|---|---|
| 의무 비율 | 80% | 95% | 90% | 없음 (자산 분리 기반) |
| 보고 주기 | 분기 1회 | 분기 1회 | 반기 1회 | 연 1회 (자산 분리 증빙) |
| 보존 기간 | 5년 | 10년 | 5년 | 5년 |
| 보고 대상 | 금감원 (FSS) | JFSA | MAS | NCA (국가별) |
| 포맷 요건 | 금감원 현장검사 포맷 | JFSA 제출 포맷 | MAS TRM 포맷 | ESMA JSON (Draft) |
| 추가 요건 | 금감원 현장검사 시 즉시 제공 | 장기 아카이빙 필수 | MAS TRM 가이드라인 준수 | DORA 리스크 관리 증빙 포함 |
| D'CENT 마진 | +20% (100% - 80%) | +5% (100% - 95%) | +10% (100% - 90%) | N/A (100% 분리) |
4.2. 한국 금감원 보고 특수 요건¶
[금감원 현장검사 대응]
- 즉시 제공 가능: PoCS 보고서를 대시보드에서 실시간 생성 가능
- SE 현장 검증: 감사인이 직접 SE에서 READ_AUDIT_DIGEST 수행 가능
- 온체인 실시간 대조: 블록체인 잔액과 SE 관리 주소 실시간 매칭
[보고서 포맷]
- 한글 요약 페이지 (경영진/감독관 대상)
- 기술 상세 (CDDL 스키마 기반 데이터)
- SE 서명 검증 절차 안내
- 온체인 잔액 증빙 (블록 높이, 주소, 잔액)
4.3. 일본 JFSA 보고 특수 요건¶
[10년 장기 보존]
- PoCS 보고서 자체를 10년 아카이빙 (REG-JP-02 연동)
- 각 보고서에 아카이브 해시 태그 포함
- 10년 후 열람 시 스키마 버전 호환 보장 (report_version 필드)
[95% 비율 증명]
- D'CENT: 100% 콜드 -> 마진 +5%
- 경쟁사 대비 최고 수준 마진 (MPC 솔루션은 hot/cold 분리 복잡)
5. 자동 생성 파이프라인¶
5.1. 파이프라인 흐름¶
[Schedule Trigger]
│
├─ 한국: 매 분기 말 (3/31, 6/30, 9/30, 12/31)
├─ 일본: 매 분기 말
├─ 싱가포르: 매 반기 말 (6/30, 12/31)
└─ EU: 매 연도 말 (12/31)
│
▼
[Step 1: 온체인 데이터 수집] (Zone 1, 자동)
│ - 블록체인 노드 또는 외부 API(Etherscan, Blockchain.info 등) 호출
│ - 관리 주소별 잔액 조회
│ - 환율 정보 수집 (CoinGecko/CMC)
│ - ChainSnapshot 배열 생성
│
▼
[Step 2: SE 데이터 수집] (Zone 2 -> Zone 3, 수동/반자동)
│ - 대시보드에서 "SE 증명 수집" 요청 생성
│ - 오프라인 앱에서 각 SE 기기 순회:
│ a. READ_AUDIT_DIGEST -> SEAuditDigest
│ b. SE ATTESTATION 서명 요청 -> attestation_sig
│ c. managed_addresses 수집
│ - QR/NFC로 대시보드에 SEAttestation 전달
│
▼
[Step 3: 보고서 조립] (Zone 1, 자동)
│ - AssetSummary 계산 (온체인 + SE 데이터 병합)
│ - cold_ratio 계산: SE_managed_assets / total_assets
│ - ComplianceResult 판정 (actual vs required)
│ - ProofOfColdStorage 구조체 조립
│
▼
[Step 4: 서명 및 저장] (Zone 1, 자동)
│ - 대시보드 키로 report_sig 서명
│ - 3단계 아카이빙 적용 (활성 -> 아카이브 -> 영구)
│ - 보고서 고유 ID + 해시 인덱싱
│
▼
[Step 5: 배포] (Zone 1, 수동/자동)
- 규제 기관 제출 (관할별 포맷 변환)
- 내부 컴플라이언스 팀 배포
- 감사인 접근 권한 설정 (Auditor 역할)
5.2. SE 데이터 수집 최적화¶
SE 데이터 수집은 에어갭으로 인해 물리적 접근이 필요하다. 이를 최적화하기 위해:
일상 동기화 시 병합: - 정기 AuditSyncPayload 동기화 시 SEAttestation 데이터를 함께 수집 - 오프라인 앱이 PoCS 데이터 수집 상태를 추적하고, 보고 주기가 도래하면 자동으로 SEAttestation 생성 프로세스 트리거
배치 수집: - 여러 SE 기기의 SEAttestation을 하나의 AuditSyncPayload에 포함 가능 - NFC 대량 전송(~32KB)으로 다수 기기 증명을 1회 세션에 전달
6. Proof of Reserve vs Proof of Cold Storage¶
6.1. 개념 비교¶
| 항목 | Proof of Reserve (PoR) | Proof of Cold Storage (PoCS) |
|---|---|---|
| 증명 대상 | 총 자산 >= 총 부채(고객 예치금) | 콜드 자산 / 총 자산 >= 의무 비율 |
| 목적 | 지급 능력 증명 | 콜드 보관 비율 의무 충족 증명 |
| 데이터 원본 | 온체인 잔액 + 부채 장부 | 온체인 잔액 + SE 증명 |
| 검증 방법 | Merkle Tree 기반 잔액 증명 | SE sign_counter + attestation_sig |
| 기존 AC-ID | AC-RP-01 (Proof of Reserve) | AC-RP-01 확장 |
6.2. D'CENT에서의 관계¶
D'CENT Enterprise의 경우:
PoCS가 PoR을 포함한다 (superset 관계)
이유:
- 콜드 비율 = 100% (에어갭)
- 따라서 콜드 자산 = 총 자산
- PoCS가 "총 자산을 SE가 관리함"을 증명하면,
이것이 곧 "자산을 보유하고 있음"의 증명이 된다
- PoR 별도 구축 불필요 -> PoCS 보고서가 PoR 역할을 겸함
기존 설계 매핑:
AC-RP-01 (Proof of Reserve) -> PoCS로 확장/대체
AC-RP-02 (자산 분리 보관) -> PoCS AssetSummary에 포함
7. 에어갭 아키텍처의 PoCS 논증 강점¶
7.1. 경쟁사 대비 구조적 우위¶
| 솔루션 | 콜드 정의 | cold_ratio 관리 | PoCS 복잡도 |
|---|---|---|---|
| D'CENT Enterprise (에어갭) | SE가 네트워크 미연결 = 물리적 콜드 | 항상 100% (구조적) | 낮음 (SE 증명만) |
| Fireblocks (MPC) | MPC 키 조각이 다수 서버에 분산 | hot/cold 분류 논쟁 가능 | 높음 (서버별 증명 필요) |
| BitGo (HSM) | 네트워크 연결 HSM = "warm" 논쟁 | 실시간 재배분 필요 | 중간 (HSM 격리 증명) |
| Ledger Enterprise | Vault 서버 + HSM 조합 | 배포 설정에 따라 가변 | 중간~높음 |
| Cobo (MPC+HSM) | 하이브리드 구조 | hot/warm/cold 3단계 | 높음 (3단계 각각 증명) |
D'CENT의 결정적 이점: 1. "콜드" 정의에 논쟁의 여지가 없음: 물리적 에어갭 = 네트워크 연결 0% = 의심 불가 2. cold_ratio 관리 불필요: hot/cold 재배분 로직, 비율 모니터링 불필요 3. 증명 단순성: SE sign_counter + attestation_sig만으로 콜드 증명 완료 4. 감사인 검증 용이: SE에 직접 접근하여 READ_AUDIT_DIGEST로 즉시 검증
7.2. SE sign_counter의 증명력¶
sign_counter가 증명하는 것:
1. 서명이 수행되었다 (sign_counter > 0)
2. 서명은 SE 내부에서만 수행 가능하다 (HW 보호)
3. SE는 에어갭 환경에만 존재한다 (물리적 격리)
4. 따라서 모든 서명은 콜드 서명이다
5. 핫 서명 건수 = 0
6. cold_ratio = cold_signatures / total_signatures = 100%
반론 불가:
- "SE가 네트워크에 연결되었을 수 있다" -> 에어갭 설계상 불가능
- "다른 기기에서 서명했을 수 있다" -> 키가 SE에만 존재
- "sign_counter를 조작했을 수 있다" -> EAL5+ NVM 변조 불가
7.3. Phase 33 세일즈 메시징 입력¶
PoCS의 구조적 강점은 Phase 33(세일즈 메시징 프레임워크)의 핵심 입력이 된다: - 기술 사실: 에어갭 SE = 100% 콜드, 규제 비율 자동 초과 충족 - CCO 메시지: "규제 비율 관리를 위한 별도 시스템이 필요 없습니다" - CISO 메시지: "콜드 보관 증명이 SE 하드웨어에 내장되어 있습니다" - 경쟁사 포지셔닝: "MPC/HSM은 'warm'인지 'cold'인지 논쟁이 있지만, D'CENT은 물리적 에어갭으로 의심의 여지가 없습니다"
Phase: 30-audit-architecture Version: 1.0 관할 기준: CORE-02 (KR 80%, JP 95%, SG 90%)
관련 문서¶
- 감사 로그 레코드 CDDL 스키마 설계 -- 규제 준수
- AuditSyncPayload 동기화 프로토콜 및 3계층 무결성 체인 설계 -- 규제 준수
- SEAuditDigest CBOR 스키마 및 SE 역할 경계 정의 -- 규제 준수