# BEYUL Whitepaper — Pre-Testnet Edition: 아키텍처 및 공개 모델

> **이것은 번역본입니다. 영어판이 유일한 정본(canonical)이며, 충돌 시 영어판이 우선합니다.** 기술 식별자(BEYUL, BYL, `privacychain`, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16 등)는 번역하지 않고 영어 그대로 둡니다.

**프로젝트:** BEYUL　**유형:** 프라이버시 퍼블릭 체인 연구 프로토타입(pre-testnet). BEYUL 프로토콜 작업은 현재 `privacychain` 리포지토리에서 개발되고 있습니다.
**문서 상태:** BEYUL 백서, **pre-testnet(연구) 에디션** — 프로토콜의 아키텍처, 공개 모델, 그리고 공개 테스트넷 이전의 현재 경계를 기술합니다. 이는 프로덕션 프로토콜 명세, 투자 문서, 컴플라이언스 의견, 보안 감사, 토큰 발행 자료, 메인넷 공지 중 **어느 것도 아닙니다**. 역량에 관한 주장은 §3.1의 증거 규율을 따르며, 여기의 어떤 것도 실제 성숙도를 넘어 기술되지 않습니다.
**토큰 상태:** 토크노믹스는 확정되지 않았습니다. **BYL**은 프로젝트의 약칭 / 티커일 뿐이며, 동결된 denomination이 **아닙니다** — denomination과 체인 파라미터는 Owner의 명시적 승인 대기 중입니다. 본 문서는 토큰 배분이나 유틸리티 설계를 정의하지 않습니다. 테스트넷 토큰은 사용되더라도 금전적 가치가 없으며 메인넷 전환도 약속되지 않습니다.
**정본 언어:** 영어판이 유일한 정본입니다. 중국어판(`beyul-whitepaper-pretestnet.zh.md`)은 함께 제공되는 작업 텍스트이며, 충돌 시 이 영어판이 우선합니다.

---

## 주장 경계 박스(먼저 읽어 주세요)

본 문서는 다음 중 어떤 주장도 **하지 않습니다**:

- 익명성, 추적 불가능성 또는 "절대적 보안"에 대한 주장 없음;
- 프로덕션 수준의 영지식 보안에 대한 주장 없음(현재 구현은 development-key 자료를 사용);
- 프로덕션 수준의 프라이버시에 대한 주장 없음(입금·출금 금액은 현재 온체인에 공개됨);
- 규제 승인이나 "compliance by design"에 대한 주장 없음;
- 현재 설계에는 프로젝트가 통제하는 전역 viewing key가 포함되지 않음; 이 속성은 오픈 구현·테스트·외부 감사를 통해 검증되어야 함;
- 공개 테스트넷도 메인넷도 존재하지 않음; **테스트넷 준비는 진행 중이며, 멀티노드 runbook과 관련 gate는 아직 완료되지 않음**;
- 토큰 가치, 에어드롭, 수익, 수익률, 거래소 상장에 대한 약속 없음; 본 문서는 지갑 제품이나 DeFi를 다루지 않음;
- 16-character disclosure code는 기반 암호 보안 자격증명이 아님(섹션 7).

**명명 및 기술 식별자.** BEYUL은 프로젝트/제품 이름입니다; BEYUL 프로토콜 작업은 현재 `privacychain` 리포지토리에서 개발됩니다. `privacychain`은 현재의 기술 식별자 — 리포지토리, 프로토콜/모듈/proto 패키지, 바이너리, chain-id — 로 유지되며 변경되지 않습니다. **BYL**은 약칭 / 티커입니다; denomination과 체인 파라미터는 Owner의 명시적 승인 대기 중이므로 BYL은 동결된 denomination이 아닙니다. 이 명명 규율은 앞으로만 적용되며, 과거 문서는 소급하여 개명되지 않습니다.

---

## 1. 요약

BEYUL은 **연구 프로토타입 단계(pre-testnet)**의 프라이버시 퍼블릭 체인 프로젝트로, **기본값으로 프라이버시(설계 목표)**와 사용자 통제 공개를 갖춘 결제 인프라를 탐구합니다. 목표 설계에서는 거래 세부 정보가 기본적으로 공개되지 않지만, 자산 소유자는 제한된 범위로 선택한 상대에게 자발적으로 공개할 수 있습니다 — Transaction Disclosure Code(TDC)는 단일 거래를 설명하고, Asset Disclosure Code(ADC)는 선택한 자산 스냅샷을 공개합니다. "기본값으로 프라이버시"는 설계 목표를 기술한 것이며 현재 프로토타입이 아닙니다(§5 참조).

**오늘 존재하는 것은 클라이언트 측 disclosure-code 파생 프로토타입**(로컬에서 테스트됨; 공개 증거 패키지는 통합 대기 중)과 Cosmos SDK 기반 chain-application 프로토타입뿐입니다. 엔드투엔드 서버 측 grant, 온체인 검증, ZK balance proof는 구현되지 않았습니다; trusted setup 없음, 외부 감사 없음, 공개 테스트넷도 메인넷도 없음; 입금·출금 금액은 현재 온체인에 공개됩니다. 본 백서(pre-testnet 에디션)의 목적은 공개 테스트넷 출시 전에 아키텍처 방향, 공개 모델, 현재 경계를 정확히 기록하는 것 — 그리고 해당 증거와 감사가 존재할 때에만 프로덕션 에디션으로 대체되는 것입니다.

## 2. 포지셔닝과 문제

공개 원장은 결제 관계, 잔액, 자금 흐름을 모든 관찰자에게 노출합니다; 한편 대부분의 강한 프라이버시 시스템은 *선택적* 공개를 운영상 어렵게 만듭니다 — 한 상대에게 거래 하나를 설명하는 것이 종종 모든 것을 볼 수 있는 능력을 넘겨주는 것을 의미합니다. BEYUL이 탐구하는 간극은: "공개"를 "은닉"과 동등한 일급 프리미티브로 만들고, 모든 공개를 사용자가 개시하도록 하는 것입니다.

BEYUL은 "완전히 익명이고 추적 불가능"이라는 서사를 두고 경쟁하지 않으며 이를 목표로 하지도 않습니다.

**비전.** 공개 원장의 금융 프라이버시는 뒤집혀 있습니다: 기본적으로 발가벗겨져 있고, 은닉 자체가 의심스러워 보입니다. BEYUL의 목표는 이 기본값을 뒤집는 것입니다 — 프라이버시를 기본 상태로, 공개를 사용자의 의도적이고 세분화된 선택으로: 어느 거래를, 어느 필드를, 누구에게, 얼마 동안.

**설계 원칙.** 프로토콜의 모든 부분은 다음을 따릅니다:

1. **공개는 일급 시민이다** — 공개 프리미티브는 은닉 프리미티브와 동등한 수준으로 설계되고 프로토타입화됩니다.
2. **최소 권한** — 각 키와 자격증명은 그 목적에 필요한 최소 권한만 지닙니다.
3. **spend authority는 신성하다** — 어떤 공개 흐름도 spend authority를 건드려서는 안 됩니다; 니모닉은 어떤 공개 단계에도 들어가지 않습니다.
4. **전역 특권 없음** — 프로토콜은 프로젝트나 제3자에게 전역 열람 채널을 제공하지 **않도록 설계**되어 있습니다; 그러한 분기가 존재하지 않는다는 것은 **오픈 구현·테스트·외부 감사로 검증되어야 할 설계 속성(§6)**이며, 아직 보증이 아닙니다.
5. **경계의 정직함** — 각 역량은 자신이 하지 않는 것을 선언합니다; 위협 모델과 한계는 공개로 유지됩니다.
6. **증거 우선** — 역량에 관한 주장은 증거(코드, 테스트, 감사)가 존재한 후에만 상향됩니다 — gate 기반이며 날짜 약속은 없습니다.

### 2.1 BEYUL 공개의 비교

> 이 표는 BEYUL의 **목표 설계**를 다른 시스템의 **현재 출시된 역량**과 비교합니다. 아래 BEYUL의 차별화 요소(만료, 폐기, 합의로 강제되는 가시성, 거래 단위/스냅샷 단위 범위 지정 및 서버·온체인 검증)는 대부분 **계획 중이거나 클라이언트 측 프로토타입**(§3, §7 참조)이며 아직 출시되지 않았습니다. 경쟁 제품 사실은 보수적으로 기술되며, 본 백서에서 독립적으로 재검증되지 않은 항목은 **【to verify】**로 표시됩니다.

| 시스템 | 공개 메커니즘 | 입도 | 만료/폐기 가능 | 가시성 강제 주체 |
|---|---|---|---|---|
| Zcash (Sapling/Orchard) | Full viewing key(FVK/IVK) | 계정 전체, 전부-아니면-전무 | 아니오 | 송신 가시성은 지갑 관행(ovk 암호화된 ciphertext)에 의존하며 합의가 아님 |
| Monero | View key | 계정 전체(수신) | 아니오 | 지갑 / 프로토콜; 범위 지정 거래 단위 프리미티브 없음 |
| Tornado 계열 믹서 | 네이티브로 없음(외부 도구, 예: association/exclusion proofs) | — | — | — |
| Penumbra | 계층형 viewing keys(FVK/IVK/OVK) + 주소별 detection key(FMD / S-FMD) | viewing keys는 계정 전체; detection key = **수신자 발견**(연결만, 내용 없음), 주소별 위임 가능 | 문서에 명시 없음【to verify】 | 암호 키 위임(클라이언트/지갑), 합의가 아님 |
| Aztec | 수신/송신 + **master** viewing keys; **tagging 기반** note discovery(FMD 아님); 암호화 로그 | master viewing key는 **모든 컨트랙트에 걸쳐 전부-아니면-전무**; 범위 지정/임시 공개는 앱 계층(Noir)에서만 구현 가능하며 프로토콜 네이티브가 아님 | 앱 계층의 "temporary view access"로만, 네이티브 아님【to verify】 | 앱/컨트랙트 로직 + 클라이언트(PXE), 기반 합의가 아님 |
| Namada (MASP) | Shielded viewing key(zvknam), Sapling 계열 멀티에셋 | **계정 전체**(하나의 shielded account의 수신+송신 잔액 및 이력); "선택적 공개" = viewing key 공유(계정 전체), 거래 단위 아님 | 공유된 viewing key는 네이티브로 폐기 불가(정확한 의미【to verify】) | Viewing key(지갑/클라이언트) |
| **BEYUL(목표 설계)** | **TDC**(거래 단위) + **ADC**(자산 스냅샷 단위), **계층화**(ADC L1/L2) | 거래 단위/스냅샷 단위; 범위 지정 필드; 송신자/수신자 역할 분리 | **만료 + 폐기(계획 중)** | **합의로 강제되는 가시성 경계(설계 요건, §6); 2요소 + 읽기 전용** |

의도된 차별화 요소는 "더 강한 은닉"이 아니라 **더 세분화되고, 시간 제한이 있으며, 사용자가 발행하는 공개**입니다: Zcash/Monero의 viewing key가 계정 전체·전부-아니면-전무·무기한 읽기 권한인 반면, BEYUL의 공개 자격증명은 하나의 거래(TDC) 또는 하나의 자산 스냅샷(ADC)으로 범위가 지정되고, 만료를 가지며, 폐기 가능하도록 설계됩니다 — 가시 필드 집합은 지갑 관행이 아니라 합의에 의해 강제됩니다. 이러한 속성은 설계 목표이며, 구현 상태는 §3과 §7에서 정직하게 추적됩니다.

> **출처.** Zcash/Monero: 본 프로젝트의 ZEC/XMR 심층 조사 보고서(1차 출처 — Zcash Protocol Specification; Monero 문서; 2026-06-12 기준). Penumbra / Aztec / Namada 행은 각 프로젝트의 **2026-06 기준 공식 문서**를 기술합니다(Penumbra: protocol.penumbra.zone — viewing keys, FMD; Aztec: docs.aztec.network — keys, note discovery; Namada: docs.namada.net — shielded accounts). 남은 【to verify】 항목 — Penumbra의 만료/폐기 및 transaction-perspective 의미, Aztec의 네이티브 만료/폐기, Namada의 정확한 폐기 의미 — 는 확인 대기 중입니다. 이 행들은 각 프로젝트 문서가 기술하는 내용을 진술한 것이며, 다른 시스템이 "할 수 없다"는 주장이 아닙니다.

## 3. 현재 상태

| 영역 | 상태 | 비고 |
|---|---|---|
| Chain-application | 프로토타입 | Cosmos SDK / Ignite |
| 합의 / 검증자 모델 | 테스트넷 설계 | CometBFT BFT + PoS형 초기 검증자 집합과 staking 모듈; PoW 아님; 메인넷급 PoS 경제 보안 아님 |
| Shielded module | 프로토타입 | 입금, 출금, spend, viewing-key 등록, note 공개 |
| Commitments / Merkle tree / nullifiers | 프로토타입 | 결정론적 동작과 double-spend 거부가 테스트로 커버됨 |
| disclosure-code 클라이언트 키 스택(TDC/ADC 파생) | 프로토타입, 로컬 테스트됨 | **공개 증거 패키지(commit/CI)는 통합 대기 중** |
| 서버 grant 스택 / 온체인 공개 검증 / ZK balance proof | 미구현 | 계획 중 |
| 수신/송신 view-key 분리 / audit key / **서버/합의로 강제되는** 공개 만료 및 폐기 | 미구현 | 계획 중 |
| Trusted setup / 외부 감사 | 미완료 / 미착수 | 모든 프로덕션 주장의 전제 조건 |
| 공개 테스트넷 / 메인넷 | 미배포 | **테스트넷 준비 진행 중: 멀티노드 runbook과 관련 gate 아직 미완료** |
| 공식 지갑 | 존재하지 않음 | 개발·테스트 도구만; 어떤 "공식 지갑"도 위조 |
| 토큰 경제 | 미확정 | 본 문서에는 토큰 설계가 없음 |

### 3.1 증거 체인

위 표의 "프로토타입 구현됨" 각 행은 산문으로 주장되는 것이 아니라 증거 기록에 연결됩니다. 증거 체인(commit hash, CI 기록, 정확한 테스트 명령과 출력, 재현 가능한 실행 지침)은 **Evidence Appendix**에 보관되며, 각 역량은 연구 성숙도 척도 **L0–L5**(설계 → 프로토타입 → 재현 가능 → 검토됨 → 네트워크 증거 → 프로덕션)로 평가됩니다. 본 백서는 원시 증거를 재진술하는 대신 그 등록부를 참조합니다.

| 역량 | 성숙도 | 증거 연결 |
|---|---|---|
| disclosure-code 클라이언트 코어(TDC/ADC 파생, 2요소, 도메인 분리, AEAD/AAD, erasure keys) | L1–L2 | 2026-06-19 읽기 전용 재현: **13/13** 로컬 테스트 통과; commit은 Evidence Appendix E1에 기록; CI **【to be supplied】** |
| Shielded module(commitment/nullifier/Merkle, double-spend 거부) | L1 | 2026-06-19 읽기 전용 재현: double-spend 및 nullifier 테스트 통과; Evidence Appendix E3; CI **【to be supplied】** |
| Groth16 spend 경로 | L1(dev-key) | dev/skeleton VK, trusted setup 없음; dev 경로 + production-VK-guard 테스트를 2026-06-19에 재현; Evidence Appendix E4 |
| 서버 grant 스택 / 온체인 검증 / ZK balance proof | L0(계획 중) | 미구현; Roadmap §10 참조 |

> 현재 자체 평가: 대부분의 자료는 **L1–L2**이며 L5는 없습니다. Evidence Appendix 항목이 (commit/CI로) 채워질 때까지, 공개 자료는 "로컬에서 검증됨; 공개 증거 패키지 통합 대기 중"이라고 말하며 "공개 증거를 갖춘 구현됨"이라고 말하지 않습니다. 등록된 증거 기록이 없는 역량은 그 성숙도 수준을 넘어 기술될 수 없습니다. Evidence Appendix는 `docs/evidence-appendix.md`에 있습니다(내부용; 공개 증거 패키지와 함께 공개 예정); E1/E3/E4는 2026-06-19에 읽기 전용으로 재현되었으며 CI 연결은 아직 보류 중입니다.

## 4. 기술 모델

프로토타입은 shielded-pool 상태 기계를 중심으로 합니다. 비암호학자를 위해, 프라이빗 잔액의 수명 주기는 다음과 같이 진행됩니다:

1. **Note.** 사용 가능한 잔액은 *note* — (소유자, 금액, 무작위성)의 기록 — 입니다. note 자체는 온체인에 절대 나타나지 않습니다.
2. **Commitment.** 체인은 note에 대한 *commitment*(단방향 바인딩 해시)만 저장하며, 추가 전용 **Merkle commitment tree**에 추가합니다. commitment만으로는 관찰자가 소유자도 금액도 알 수 없습니다.
3. **Spend → nullifier.** note를 사용하려면 소유자가 그로부터 파생된 *nullifier*를 공개합니다. nullifier는 외부 관찰자에게 commitment와 연결되지 않도록 **설계되었으며**(nullifier-key PRF 가정 하에; 옐로페이퍼 §7.1), 해당 note에 대해서는 결정론적이므로 같은 note는 한 번만 무효화될 수 있습니다.
4. **Double-spend 거부.** 체인은 nullifier 집합을 유지하며, 중복된 nullifier는 거부됩니다. 이는 **어느 note가 사용되었는지 드러내지 않으면서** double-spend를 방지합니다.
5. **유효성 증명.** spend는 "그 commitment가 트리에 있는 note를 내가 소유하며, 그 nullifier를 올바르게 파생했다"는 영지식 증명을 수반하며, 그 값들 중 어느 것도 드러내지 않습니다. 검증은 Groth16 경로를 통해 이루어집니다.

**현재 검증기는 development/skeleton verifying-key 자료를 trusted setup 없이 사용하며, 프로덕션 soundness나 프라이버시를 확립하지 않습니다.** 표준 대외 표현: "프로토타입에는 development-key Groth16 검증 경로가 포함됩니다. 아직 프로덕션 수준의 영지식 보안을 제공하지 않습니다." note 형식, commitment 스킴, nullifier 파생, 트리 의미의 형식적 정의는 옐로페이퍼 §§5–7 및 §10을 참조하세요.

### 4.1 왜 독립 체인인가, 왜 Cosmos인가

공개 모델은 공유 L1 상의 스마트 컨트랙트 배포나 일반 rollup이 깔끔하게 제공하지 못하는 몇 가지에 대한 통제를 필요로 합니다:

- **합의로 강제되는 공개 가시성**(§6)과 shielded pool의 **공급 무결성 규칙**은 상태 전이/합의 계층에 있어야 하며, 호스트 체인의 검증자와 수수료 시장이 프로젝트의 통제 밖에 있는 컨트랙트 내부에 있어서는 안 됩니다.
- **네이티브 shielded 상태**(commitment tree, nullifier 집합, value-balance 회계)는 컨트랙트 스토리지보다 일급 체인 상태로서 더 저렴하고 감사 가능하며, 호스트 체인의 공개 mempool과 메타데이터 모델이 의도 이상으로 누출하는 것을 피합니다.
- **bonded-PoS 검증자 집합**은 공급 무결성을 모든 full node가 재계산할 수 있게 하고, 결제에 적합한 즉시 최종성을 제공합니다.

**Cosmos SDK + CometBFT**는 staking/slashing 모듈, 주권적 업그레이드 거버넌스, 즉시 최종성을 갖춘 성숙한 BFT-PoS 스택을 위해 선택되었습니다 — 어떤 토큰 모델에 대한 지지가 아닙니다(어느 것도 확정되지 않음). 이는 아키텍처 선정 근거이며, 독립 체인이 배포되었다는 주장이 아닙니다; 실제 상태는 §3과 §8을 참조하세요.

### 4.2 성능 특성

두 종류의 수치는 분리하여 다룹니다. **고유(스킴 수준, 인용 가능):** BN254 곡선 상의 Groth16은 **상수 크기 증명**(세 개의 군 요소: 2×G1 + 1×G2, BN254에서 약 128 B 압축 / 약 256 B 비압축)과 **상수 시간 검증**(회로 크기와 무관한, 고정되고 적은 수의 페어링 검사)을 가집니다. 이는 BEYUL의 구현이 아니라 증명 시스템 자체에서 따라옵니다. **시스템 수준(아직 측정되지 않음):** 증명 시간, 트랜잭션 처리량(TPS), 회로 크기(제약 수)는 프로덕션 회로에 의존하지만, 프로덕션 회로는 **구축되지 않았습니다** — 현재 경로는 dev/skeleton verifying key를 사용합니다(§4). 따라서 그러한 수치는 모두 **target / 【to be supplied】**이며, 프로덕션 회로와 trusted-setup 또는 투명 증명 경로가 존재한 후에 벤치마크됩니다(Roadmap §10, Phase 6). 이 선 위로는 어떤 시스템 수준 성능 수치도 주장되지 않습니다.

## 5. 프라이버시 모델과 현재 한계

| 차원 | 목표 모델 | 현재 프로토타입 |
|---|---|---|
| 풀 내 금액과 송신자/수신자 연결 | 은닉 | 프로토타입 경로, 프로덕션 아님 |
| 입금 / 출금 금액 | 설계 대기 | **공개** |
| 타이밍 / 수수료 사이드채널 / mempool | 완화 대기 또는 범위 밖 | 미완화 |
| 검증자 순서 지정 / 검열 / MEV | 일부 프로토콜 범위 밖 | 미완화 |
| 네트워크 계층 및 거래소/브리지 메타데이터 | 프로토콜 범위 밖 | 범위 밖 |

**현재 프로토타입은 프로덕션 수준의 프라이버시가 아닙니다.**

pre-testnet / 저사용 시 익명 집합은 작거나 비어 있으며, 실제 사용자가 없으면 풀 내 프라이버시는 유의미하게 확립되지 않습니다 — **강한 프라이버시는 크고 활발한 익명 집합에 의존하며, 실제 사용이 존재하기 전까지는 주장되지 않습니다**. 검증자 계층 순서 지정/MEV와 네트워크 메타데이터는 미완화 상태로 남아 있습니다.

익명 집합의 형식적 프레임워크(shielded pool의 익명 집합이 어떻게 정의되고 한정되는지)는 옐로페이퍼(§15)에 보관됩니다; 본 절은 프라이버시 목표와 현재 한계를 진술하는 것이지 그 형식 모델이 아닙니다.

## 6. 키와 공개 모델

권한이 높은 순서로: **Spend Key**(유일한 지출 권한; 사용자 기기를 절대 떠나지 않으며, 공개 흐름에 절대 관여하지 않음) → **Full View Key**(읽기 전용; 수신/송신 분리 계획) → **Audit Key**(계획 중: 사용자가 자발적으로 발행; 기간 제한, 범위 제한, 폐기 가능; 프로토콜이 강제하는 채널이 아님) → **Disclosure Credential**(하나의 거래 또는 하나의 자산 스냅샷에 바인딩된 최소 공개 단위) → **16-character disclosure code**(입구 단축 코드; 키가 아님).

**프로젝트 열람 권한 경계**: 현재 설계에는 프로젝트가 통제하는 master viewing key가 포함되지 않습니다. 이 속성은 팀에 대한 신뢰가 아니라 오픈 구현·테스트·외부 감사를 통해 검증되어야 합니다 — 키 파생 경로는 오픈 소스로 출시되며, 어떤 제3자도 프로젝트로 이어지는 분기가 없음을 파생 그래프에서 감사할 수 있습니다. 외부 감사가 완료될 때까지 이는 "검증되어야 할 설계 속성"이며 "보증"이 아닙니다.

**니모닉 정책(아키텍처 계획이며 출시된 제품이 아님)**: 지갑 루트 키는 기본적으로 24단어 니모닉(BIP39)을 사용하며, 하위 키는 도메인 분리(HKDF + domain tags)로 파생됩니다. **니모닉은 어떤 공개 흐름에도 절대 나타나서는 안 됩니다**; disclosure code도 `link_secret`도 니모닉 단독으로 파생될 수 없으며, TDC/ADC grant는 자발적 공개의 순간에 CSPRNG와 로컬 인가를 사용해 생성됩니다.

**공개 가시성 경계(설계 요건)**: 공개 자격증명의 가시 범위 — 송신 방향 가시성 포함 — 는 지갑 구현 관행이 아니라 합의 계층 규칙으로 보장되도록 계획됩니다(송신 가시성이 지갑 관행에 의존하는 Zcash에서 얻은 업계 교훈); 이 요건은 온체인 검증 스택(roadmap Phase 5)과 함께 실현되며 오늘은 구현되지 않았습니다.

**Disclosure Grant 계층(독립 검토 대기)**: Disclosure Grant 계층 — 범위, 만료, 폐기, 감사 로그, viewer 권한 — 는 독립적인 제품 및 보안 검토 대기 중입니다. 그 검토가 완료될 때까지 이러한 경계 속성 중 어느 것에도 의존해서는 안 되며, 어떤 문서도 그것들이 확립되었다고 암시해서는 안 됩니다.

## 7. TDC / ADC 공개 프로토타입

### 7.1 용어와 인코딩

공식 용어는 "**16-character Crockford Base32 disclosure code**"(알파벳은 혼동되는 문자 I/L/O/U를 제외; 단축 코드 엔트로피 약 80비트)이며, "16-character disclosure code"로 약칭됩니다. "16-digit code"나 "16-digit security code" 같은 표현은 사용하지 않습니다 — 숫자만 사용하는 스킴(약 53비트)은 엔트로피 예산이 불충분하여 기각되었습니다.

> **"16-character disclosure code는 기반 암호 보안 자격증명이 아닙니다. 이는 사용자 친화적인 접근 입구이며, 실제 인가는 고엔트로피 disclosure credential, 서명, 범위 제한, 만료, 검증 로직에 의해 공동으로 보호되어야 합니다."**

### 7.2 실제 현재 상태(필독)

BEYUL이 가진 것은 **로컬에서 테스트된 TDC/ADC 클라이언트 측 파생 프로토타입**입니다. 엔드투엔드 서버 grant, 체인 상태 검증, ZK balance proof는 **계획 중이며 미구현**입니다. 따라서 다음과 같이 진술해서는 **안 됩니다**: 검증 가능한 공개가 구현되었다; 자금을 이미 증명할 수 있다; ADC가 정확한 잔액을 증명할 수 있다; 또는 disclosure code를 온체인에서 검증할 수 있다.

클라이언트 프로토타입이 커버하는 것(로컬에서 테스트됨): 2요소 KEK(`link_secret` + 16자 코드, 둘 다 필수); 정준 인코딩; TDC 송신자/수신자 역할 바인딩; TDC/ADC 도메인 분리(서로 열 수 없음); AAD 변조 보호를 갖춘 AEAD envelope(클라이언트 측 TDC/ADC envelope; 온체인 MsgDiscloseNote envelope의 AAD는 여전히 target — 옐로페이퍼 §2.3); slow-hash 코드 검증기(목표 스위트 Argon2id; 프로덕션 어댑터 미연결); erasure-key crypto-shredding.

### 7.3 TDC와 ADC 의미

| 역량 | 드러내는 것 | 드러내지 않는 것 | 상태 |
|---|---|---|---|
| TDC — Transaction Disclosure Code | 한 거래/출력의 범위 지정 필드, 송신자/수신자 역할 분리 | spend authority, 전체 이력, 미래 거래 | 클라이언트 파생 프로토타입; 서버 및 체인 검증 미구현 |
| ADC_L1 — Asset Disclosure Code, 하한 계층 | 사용자가 선택한 proof-of-funds / 하한 진술 | 전체 잔액, notes, nullifiers, 거래 상대, 이력 | 클라이언트 파생 프로토타입; **증명 시스템 미구현** |
| ADC_L2 — Asset Disclosure Code, 정확 계층 | 확정된 높이에서 선택 자산의 정확한 잔액 스냅샷 | notes, nullifiers, 거래 상대, 이력 | **설계만**; 완전성 소스 + ZK balance proof 필요 |

**공개 트릴레마**: 소유권을 숨기는 시스템은 잔액 완전성, 이력 비누출, viewing key를 넘기지 않음을 동시에 약속할 수 없습니다 — 사용자는 선택한 notes의 소유를 증명할 수 있지만, 추가 완전성 소스 없이는 아무것도 누락하지 않았음을 증명할 수 없습니다. 따라서 ADC는 계층화되며, ADC는 선택한 자산 집합의 선택한 높이에서의 잔액을 정확히 공개합니다 — "잔액을 드러내지 않는다"고 기술해서는 안 됩니다.

ADC 리스크(공개 유지): 같은 상대에게 반복된 스냅샷은 시간에 따른 잔액 변화를 드러냅니다; 순자산 노출은 신체적 안전과 강요 리스크입니다(ADC는 기본적으로 꺼져 있으며 명시적 확인이 필요); 회전(rotation)은 관찰자가 이미 본 것을 되돌릴 수 없습니다.

### 7.4 disclosure code FAQ

| 질문 | 답변 |
|---|---|
| TDC란 무엇인가 | transaction disclosure code; 한 거래/출력에 관한 범위 지정 정보만 공개합니다 |
| ADC란 무엇인가 | asset disclosure code; 사용자가 선택한 자산 잔액 스냅샷을 공개합니다 |
| ADC는 잔액을 드러내는가 | 예 — ADC는 선택한 잔액 스냅샷(selected balance snapshot)을 공개합니다 |
| disclosure code로 자금을 쓸 수 있는가 | 아니오. 모든 disclosure credential은 `canSpend=false`(프로토콜 수준 불변식)를 가져야 합니다 |
| disclosure code는 영구적인가 | 아니오. **24시간 수명은 설계 기본값이며 현재 강제되는 속성이 아닙니다** — 서버/합의로 강제되는 만료와 폐기는 구현되지 않았으며, 미래의 Layer 2 grant 및 검증 서비스(roadmap Phase 5)에 의해 강제되며 오늘이 아닙니다. 클라이언트 측 envelope 만료는 E1 프로토타입에서만 시연되며 평문을 보유한 누구든 무시할 수 있으므로 강제되는 속성이 아닙니다. 설계상 자격증명은 시간 제한이 있고 사용자가 구성할 수 있습니다: 더 긴 공개에는 명시적 확인이 필요하고, 영구 공개는 기본값이 아니며, 폐기(강제된 후)는 미래 접근을 막지만 이미 열람되거나 복사된 정보는 지울 수 없습니다 |
| disclosure code는 복구 구문에서 파생되는가 | 아니오. disclosure credential은 읽기 전용이며, **지갑 생성 시 자동 생성되지 않고, 복구 구문에서 파생되지 않으며**, spend authority를 부여할 수 없습니다(`canSpend=false`). TDC는 거래 단위 공개; ADC는 옵트인 자산 수준 grant입니다 |
| disclosure code는 어떻게 보호되는가 | 2요소(`link_secret` + 16자 코드), AEAD envelope, AAD 바인딩, slow-hash 검증기; **서버 측 레이트 리미팅과 통일된 오류 응답은 아직 구현되지 않았습니다** |
| disclosure code는 개인 키인가 | 아니오. 자산을 옮길 수 없고 Spend/View/Audit 키를 대체할 수 없습니다; 그러나 함부로 공유하지 마세요 — 한 번 공개된 정보는 되돌릴 수 없습니다 |

## 8. 테스트넷 계획(현재 초점)

### 8.1 검증자 모델

테스트넷은 **PoS형 BFT 검증자 모델**을 사용합니다: Cosmos SDK + CometBFT, 초기 검증자 집합, staking 모듈 테스트 흐름. 이는 PoW가 아니며, 또한 **메인넷급 PoS 경제 보안이 아닙니다** — 메인넷 경제 모델은 본 백서 범위 밖의 장기 연구입니다.

### 8.2 테스트넷 준비 상태(솔직히)

테스트넷 준비는 **진행 중**입니다: 멀티노드 runbook과 관련 gate는 아직 완료되지 않았습니다(해당 풀 리퀘스트가 모두 병합되지 않았고 체크도 통과하지 않음). 이 gate들이 닫히고 증거가 등록될 때까지, 본 프로젝트는 "testnet-ready" 표현을 사용하지 않습니다.

출시 전 체크리스트: 증거 패키지 종료; 테스트넷 chain-id와 genesis; 검증자 온보딩 가이드; 3+ 노드 멀티노드 runbook; faucet 정책과 레이트 리미팅; 공개 RPC/API 정책; 모니터링 대시보드; 인시던트 대응 프로세스; 알려진 한계 목록; 참가자 명령 흐름; 테스트넷 토큰 무가치 고지.

### 8.3 테스트넷이 검증할 수 있는 것 / 증명할 수 없는 것

**검증할 수 있는 것**: 노드 동작과 블록 생성, staking 모듈 흐름, faucet, RPC, 모니터링과 인시던트 대응, disclosure-code 데모 흐름, shielded module 프로토타입 흐름.
**증명할 수 없는 것**: 프로덕션 프라이버시, 메인넷 PoS 경제 보안, 토큰 가치, 규제 수용, 프로덕션 ZK soundness. 테스트넷 출시를 "프로덕션 검증"으로 마케팅해서는 안 됩니다.

### 8.4 참가자 안내

테스트넷 토큰은 금전적 가치도 메인넷 전환 약속도 없습니다; 공식 지갑은 없습니다 — 공식적으로 공개된 커맨드라인 도구와 문서로만 참여하세요; **어떤 흐름도 당신의 니모닉을 공개 단계에 넣도록 절대 요구하지 않습니다** — 당신의 니모닉을 요구하는 "공식"은 사기꾼입니다; 현재 어떤 토큰 판매, 프라이빗 라운드, 화이트리스트, 에어드롭 등록도 없습니다.

### 8.5 거버넌스, 업그레이드, 경제적 경계

이 pre-testnet 단계에서 BEYUL은 **탈중앙 거버넌스가 없습니다**. 프로토콜 업그레이드와 보안상 중요한 pin — genesis 파라미터와 **pinned verifying key** — 는 **초기 검증자 집합과 Owner가 공동으로** 통제합니다. 이는 솔직히 진술하는 중앙집중적 신뢰 모델이며, 네트워크와 그 거버넌스가 성숙함에 따라 점진적으로만 탈중앙화됩니다(DAO 없음, 탈중앙화 일정 약속 없음). 검증자를 운영하는 것 자체는 업그레이드 권한을 부여하지 않습니다; pinned VK와 genesis는 "검증자 집합 + Owner" 업그레이드 경로를 통해서만 변경됩니다.

**경제적 경계.** denomination, 공급량, 경제 파라미터는 **Owner의 결정 — gate되어 있으며 본 백서에서 정의되지 않습니다**(위 토큰 상태 참조). 여기서는 어떤 denomination, 공급량, 토큰 경제 모델도 고정하지 않습니다.

## 9. 위협 모델(완화될 때까지 공개)

적대자 클래스별로 정리되었으며, 옐로페이퍼의 적대자 모델(A1–A4)에 맞춰져 있습니다. 이는 요약입니다; 옐로페이퍼가 위협 모델의 권위 있는 참조이며, 두 문서는 드리프트해서는 안 됩니다 — 차이가 있는 경우 옐로페이퍼가 우선합니다.

- **A1 — 수동적 체인 관찰자**(공개 체인 데이터만 읽음): 공개 입금/출금의 금액 상관, 타이밍 상관, 수수료/gas 사이드채널 — **미완화**. commitments, nullifiers, anchors, 풀 순흐름 계정은 설계상 공개됩니다.
- **A2 — 네트워크/인프라 적대자**(mempool, RPC, 검증자 순서 지정, IP): mempool 관찰, 검증자 순서 지정과 검열, 네트워크 계층 메타데이터 — **미완화**(순서 지정/검열은 일부 프로토콜 범위 밖); 프로토콜 외 거래소/브리지 메타데이터 — **범위 밖**.
- **A3 — 공개 측 적대자**(공개 수신자 또는 코드 보유자): 수신자에 의한 공개 전달은 **암호학적으로 통제 불가능**; 폐기는 **미구현**; 반복된 ADC 스냅샷의 시계열과 순자산 노출; 강요된 발행 — **솔직히 진술, 미완화**.
- **A4 — 엔드포인트/소셜 적대자**(사용자 기기, 피싱): 니모닉이나 코드를 노린 피싱과 소셜 엔지니어링, 위조 지갑과 위조 공식 채널 — **미완화**; 사용자 교육과 공식 채널 목록으로 대응.

횡단적·미해결: 회로 버그, trusted setup, 외부 감사 — **미검증 / 미해결 / 미완료**. 풀 공급 무결성(G-S 게이트)은 열려 있으며, 보존과 double-spend는 **프로덕션 속성으로 주장되지 않고**, in-circuit 및 keeper value-balance와 128↔64비트 폭 일관성(옐로페이퍼 §12.3 반영)을 대기 중입니다. 테스트넷 토큰 가치와 보상에 관한 혼동은 **허용되지 않습니다** — 테스트 토큰은 무가치하며 모든 보상 회계는 시뮬레이션입니다.

## 10. Roadmap(gate 기반, 날짜 약속 없음)

> 각 역량은 정확히 다음 중 한 상태에 있어야 합니다: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. commit, CI 기록, 테스트 명령, 출력 없이 "구현됨"으로 쓸 수 있는 주장은 없습니다.

| 단계 | 목표 | 종료 기준(요약) |
|---|---|---|
| Phase 0 — 증거 종료 및 문서 범위 설정 **← 현재** | Evidence Appendix 종료; 공개 서사를 테스트넷으로 한정 | 구현됨 주장은 모두 증거 있음; 토큰/지갑/DeFi/메인넷 함의 없음 |
| Phase 1 — 테스트넷 준비 | 8.2절 체크리스트 완료 | 3+ 노드 devnet 안정; runbook 재현 가능; PR 체크 그린 |
| Phase 2 — 공개 테스트넷 | 통제된 공개 실험 | 외부 노드 참여 가능; faucet 남용 통제; 메인넷이나 수익 오도 없음 |
| Phase 3 — TDC MVP | 엔드투엔드 단일 거래 grant | 오류 코드/만료/소진 시 동작 안전; grant 존재 누출 없음; 범위 지정 필드만 |
| Phase 4 — ADC_L1 | 하한 proof of funds | 정확한 잔액으로 기술하지 않음; 시계열 리스크 공개; TDC/ADC 상호 열기 불가 |
| Phase 5 — 온체인 공개 검증 | root-bound 검증 | 오류 체인/오류 root/오류 scope/오류 asset 모두 거부; 리플레이 보호 |
| Phase 6 — 프로덕션 ZK 경로 | 감사 가능한 증명 시스템 | dev verifying keys 폐기; 외부 암호 감사; 완료 전 "production ZK" 주장 없음 |
| Phase 7 — ADC_L2 | 정확한 잔액 스냅샷 | 완전성 증명 가능; 이력 누출 없음; 장기 viewing key가 되지 않음 |
| Phase 8 — 외부 감사 및 pre-mainnet | pre-mainnet 검토 | 프로토콜/암호/구현 감사; 법률 검토; 공개 증거 패키지 |

순서는 되돌릴 수 없습니다: **testnet → TDC MVP → ADC_L1 → root-bound verification → production ZK → ADC_L2 → audit → pre-mainnet.**

## 11. 컴플라이언스 경계

BEYUL은 컴플라이언스 솔루션이 아닙니다: AML, KYC, travel-rule, 동결, 제재 스크리닝, 보고 워크플로를 구현하지 않으며, "compliant by design"을 주장하지 않습니다. 모든 공개는 사용자가 개시합니다; 프로토콜에는 강제 공개 채널이 없습니다; 현재 설계에는 프로젝트가 통제하는 전역 viewing key가 포함되지 않습니다(오픈 구현과 감사로 검증 예정). 기관과 개인은 자기 관할 구역의 프라이버시 자산에 대한 규제 입장을 독립적으로 평가해야 합니다.

## 12. 리스크 고지 및 면책

본 문서는 정보 제공만을 목적으로 하며, 다음 중 어느 것도 구성하지 않고 그렇게 해석되어서도 안 됩니다: 증권, 상품, 금융 상품의 제공 또는 판매; 투자, 법률, 세무, 재무 자문; 또는 어떤 관할 구역에서의 컴플라이언스 표명. 본 문서에는 미래 예측 진술(설계 목표, 테스트넷 계획, roadmap)이 포함되며 중대한 불확실성에 영향을 받습니다; 실제 결과는 크게 다를 수 있습니다.

본 프로젝트는 현재 **발행된 토큰이 없습니다**; 테스트넷 토큰은 사용되더라도 금전적 가치가 없습니다. 암호 자산 네트워크 참여에는 중대한 리스크가 따릅니다. 스스로 조사하고 전문 자문가와 상의하세요. 어떤 번역이 이 영어 정본판과 충돌하는 경우, 이 영어판이 우선합니다. 이 면책은 일반 템플릿이며, 정식 공개 전에 해당 관할 구역의 법률 고문이 검토해야 합니다.

## 13. 결론

BEYUL의 방향은 기본값으로 프라이버시와 사용자 통제 공개입니다. 오늘의 신뢰할 수 있는 자산: chain-application 프로토타입, 로컬에서 테스트된 TDC/ADC 클라이언트 측 파생 프로토타입, 그리고 구현에 엄격히 정렬된 상태 표와 위협 모델. 현재 유일한 초점은 **공개 테스트넷 출시 전제 조건**입니다: 증거 종료, 멀티노드 runbook, faucet과 모니터링, 참가자 문서. 해당 증거가 존재할 때까지, 본 프로젝트는 메인넷, 토큰, 프로덕션 프라이버시, 컴플라이언스에 관한 주장을 하지 않습니다.