이것은 번역본입니다. 영어판이 유일한 정본(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의 목표는 이 기본값을 뒤집는 것입니다 — 프라이버시를 기본 상태로, 공개를 사용자의 의도적이고 세분화된 선택으로: 어느 거래를, 어느 필드를, 누구에게, 얼마 동안.
설계 원칙. 프로토콜의 모든 부분은 다음을 따릅니다:
- 공개는 일급 시민이다 — 공개 프리미티브는 은닉 프리미티브와 동등한 수준으로 설계되고 프로토타입화됩니다.
- 최소 권한 — 각 키와 자격증명은 그 목적에 필요한 최소 권한만 지닙니다.
- spend authority는 신성하다 — 어떤 공개 흐름도 spend authority를 건드려서는 안 됩니다; 니모닉은 어떤 공개 단계에도 들어가지 않습니다.
- 전역 특권 없음 — 프로토콜은 프로젝트나 제3자에게 전역 열람 채널을 제공하지 않도록 설계되어 있습니다; 그러한 분기가 존재하지 않는다는 것은 **오픈 구현·테스트·외부 감사로 검증되어야 할 설계 속성(§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 상태 기계를 중심으로 합니다. 비암호학자를 위해, 프라이빗 잔액의 수명 주기는 다음과 같이 진행됩니다:
- Note. 사용 가능한 잔액은 note — (소유자, 금액, 무작위성)의 기록 — 입니다. note 자체는 온체인에 절대 나타나지 않습니다.
- Commitment. 체인은 note에 대한 commitment(단방향 바인딩 해시)만 저장하며, 추가 전용 Merkle commitment tree에 추가합니다. commitment만으로는 관찰자가 소유자도 금액도 알 수 없습니다.
- Spend → nullifier. note를 사용하려면 소유자가 그로부터 파생된 nullifier를 공개합니다. nullifier는 외부 관찰자에게 commitment와 연결되지 않도록 설계되었으며(nullifier-key PRF 가정 하에; 옐로페이퍼 §7.1), 해당 note에 대해서는 결정론적이므로 같은 note는 한 번만 무효화될 수 있습니다.
- Double-spend 거부. 체인은 nullifier 집합을 유지하며, 중복된 nullifier는 거부됩니다. 이는 어느 note가 사용되었는지 드러내지 않으면서 double-spend를 방지합니다.
- 유효성 증명. 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과 모니터링, 참가자 문서. 해당 증거가 존재할 때까지, 본 프로젝트는 메인넷, 토큰, 프로덕션 프라이버시, 컴플라이언스에 관한 주장을 하지 않습니다.