프라이버시 스테이블코인 체크리스트
도입
프라이버시 stablecoin을 검토할 때 첫 질문은 "얼마나 숨길 수 있는가"가 아니다. 첫 질문은 "누가 어떤 정보를 볼 권리가 있으며, 어떤 정보는 절대 필요 이상으로 공개하지 않을 것인가"다.
금액 privacy, 신원 privacy, 잔고 privacy, compliance proof, auditor disclosure는 서로 다른 문제다. 한쪽을 강화하면 다른 쪽이 어려워질 수 있다. 그래서 체크리스트는 privacy와 compliance를 같은 표에서 다룬다.
학습 목표
- privacy와 compliance 요구를 체크리스트로 균형 있게 평가한다.
- 사용자 보호, 감사, 운영 대응을 함께 설계한다.
개념 설명
Impact highLikelihood medium
핵심 가정 오류
숨길 데이터와 공개할 데이터가 분리되는가
Impact mediumLikelihood medium
운영 상태 누락
체인별 ownership 모델을 오해하지 않는가
Impact mediumLikelihood low
학습 산출물 미흡
프라이버시 스테이블코인 체크리스트 이해 점검
Actor matrix를 먼저 만든다.
| Actor | 봐야 하는 것 | 보지 않아야 하는 것 | 증거 |
|---|---|---|---|
| 사용자 | 자신의 balance, payment status, disclosure consent | 다른 사용자의 activity | wallet receipt |
| merchant | payment success, settled amount, refund status | payer 전체 balance와 KYC detail | merchant receipt |
| issuer | compliance status, freeze/disclosure trigger | 불필요한 거래 목적 정보 | issuer audit log |
| auditor/regulator | 필요한 범위의 proof 또는 disclosure | 모든 실시간 user activity | disclosure request record |
| public observer | supply, verifier result, public events | amount/counterparty detail | onchain proof result |
검토 항목은 네 그룹으로 나눈다.
| 그룹 | 체크 항목 |
|---|---|
| Data minimization | 숨길 field, 공개할 field, metadata leakage, retention policy |
| Selective disclosure | 누가 요청하고 누가 승인하며 어떤 record가 남는가 |
| Auditability | proof freshness, disclosure log, key rotation, reviewer access |
| Abuse response | unauthorized decrypt, stale proof, fraud/refund dispute, emergency access |
코드로 확인하기
privacy stablecoin 체크리스트는 기능 목록이 아니라 데이터 노출 경계표다. 코드에서는 어떤 값이 public, private, encrypted, revealable인지 명확히 태깅해야 한다.
백엔드데이터 분류표를 코드로 표현
type DataClass = "public" | "private" | "encrypted" | "revealable";const stablecoinPrivacyFields: Record<string, DataClass> = { txHash: "public", senderAddress: "public", transferAmount: "encrypted", kycCredential: "private", proofResult: "public", disputePacket: "revealable"};function assertNoPrivateFieldInEvent(fields: string[]) { const leaked = fields.filter((field) => stablecoinPrivacyFields[field] === "private"); if (leaked.length > 0) throw new Error(`Private field in event: ${leaked.join(",")}`);}이 검사는 event 설계와 analytics schema에서 특히 중요하다. private field가 한 번 로그로 나가면 나중에 지울 수 없다.
운영privacy release gate
privacy_release_gate: event_schema_reviewed: true analytics_redaction_tested: true reveal_policy_approved: true proof_failure_messages_reviewed: true unsupported_wallet_fallback_defined: true개인정보 보호는 cryptography만으로 완성되지 않는다. 지원하지 않는 wallet, 실패 메시지, 고객지원 로그까지 같은 기준으로 검토해야 한다.
인덱서이벤트 스키마에서 private field 차단
select event_name, field_namefrom analytics_event_fieldswhere data_class = 'private' and destination in ('public_dashboard', 'merchant_export', 'support_search');privacy 기능은 contract만 보는 순간 빠진다. analytics, support tool, merchant export로 private field가 흘러가면 암호화 transfer가 안전해도 제품은 privacy를 깨뜨린다.
클라이언트disclosure 요청 화면 모델
type DisclosureRequest = { requester: "issuer" | "auditor" | "regulator"; scope: "single_payment" | "account_window" | "full_account"; reason: string;};function disclosureRisk(request: DisclosureRequest) { if (request.scope === "full_account") return "requires_legal_approval"; if (request.reason.length < 20) return "needs_clear_reason"; return request.requester === "regulator" ? "formal_review" : "standard_review";}selective disclosure는 버튼 하나로 열어주는 기능이 아니다. 요청자, 범위, 이유를 사용자와 운영자가 볼 수 있는 형태로 남겨야 사후 감사가 가능하다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| 숨기는 데이터 | amount, sender, receiver, balance, purpose 중 무엇을 숨기는가 | privacy scope table |
| 공개 데이터 | supply, proof result, receipt, compliance status 중 무엇을 공개하는가 | public evidence table |
| disclosure | auditor/regulator/issuer access를 어떻게 통제하는가 | disclosure workflow |
| reconciliation | merchant ledger와 hidden transfer를 어떻게 맞추는가 | reconciliation design |
| incident | key leak, unauthorized decrypt, stale proof를 어떻게 처리하는가 | incident runbook |
실무 예시
privacy checkout에서 merchant는 payer 전체 잔고를 볼 필요가 없다. Merchant에게 필요한 것은 "결제가 성공했고 정산 가능한 금액이 있다"는 증거다. 반면 issuer는 제재 대응과 fraud investigation을 위해 제한된 disclosure 권한이 필요할 수 있다.
| 시나리오 | privacy 요구 | compliance/운영 요구 |
|---|---|---|
| 정상 결제 | payer identity와 balance 비공개 | receipt와 settlement amount 제공 |
| refund dispute | 결제 관련 record만 공개 | disclosure 승인과 audit log 필요 |
| sanctions alert | 관련 account disclosure 가능 | request owner, legal basis, retention |
| stale proof | 오래된 증명 거절 | proof timestamp와 list version 검증 |
| key rotation | 기존 record 접근성 유지 | old/new key audit trail |
흔한 오해와 실패 시나리오
| 오해 | 실제로 확인할 것 |
|---|---|
| privacy 기능은 암호기술 선택으로 끝난다고 본다. | 사용자 동의, disclosure policy, audit log, incident runbook이 함께 필요하다. |
| amount만 숨기면 충분하다고 본다. | sender, receiver, timing, metadata leakage도 검토해야 한다. |
| auditor access를 모든 데이터 접근 권한으로 둔다. | 필요한 범위와 절차가 제한되어야 한다. |
| hidden transfer는 ledger reconciliation과 무관하다고 본다. | merchant와 issuer는 정산 증거를 가져야 한다. |
| law enforcement 요청을 수동 운영으로만 둔다. | disclosure workflow, approval, log, user notification policy가 필요하다. |
실습 과제
- 프라이버시 스테이블코인 체크리스트 이해 점검: data minimization, selective disclosure, auditability, abuse response에서 총 12개 체크 항목을 작성한다.
- Actor matrix 작성: user, merchant, issuer, auditor/regulator, public observer가 봐야 할 것과 보지 않아야 할 것을 표로 만든다.
- disclosure workflow 설계: 요청, 승인, 복호화/증명, 기록, 사용자 통지, retention 절차를 만든다.
- incident runbook 작성: unauthorized decrypt, stale proof, key leak, hidden amount mismatch, regulator request를 처리하는 절차를 쓴다.
완료 기준
- 체크 항목 12개를 작성했다.
- privacy/compliance tradeoff를 명시했다.
- 운영 대응 절차를 만들었다.
근거 자료
- 프라이버시 스테이블코인 체크리스트: 06-프라이버시-ZK-FHE/03-프라이버시-스테이블코인-체크리스트.md