이 페이지는 Rand의 주요 설계 결정마다 그 근거를 기록합니다. 구성 요소가 제공해야 하는 속성, 그 속성이 성립하는 가정, 그리고 그 대가로 감수한 비용입니다. 2026년 9월 29일에 이 사이트, 백서 요약, 레퍼런스 풀 노드(github.com/randprotocol/fullnode: README, docs/, docs/superpowers/specs/)를 바탕으로 작성했습니다. 각 답변은 근거를 밝힌 문서를 명시하며, randprotocol.org로 시작하지 않는 경로는 fullnode 저장소를 기준으로 합니다.
상태. Rand는 창립 팀이 운영하는 testnet에서 실행되고 있으며, 프로토콜은 독립적인 감사를 받지 않았습니다. 아래의 몇몇 결정은 체인 컷에 걸쳐 단계적으로 구현됩니다. 모든 수치는 작성 시점에 구동 중인 노드를 측정한 값이며, 변경될 수 있으므로 인용하기 전에 다시 측정해야 합니다.
암호 프리미티브
1. 노트 암호화에 ML-KEM-768(Kyber)을 사용하는 이유는 무엇입니까?
노트의 평문은 수신자에게 암호화되어 엔벨로프에 담기며, 이 엔벨로프는 공개 원장에 무기한 남습니다. 따라서 그 기밀성은 되돌릴 수 없는 속성입니다(질문 8). 이후 어느 시점에든 암호학적으로 의미 있는 양자 컴퓨터를 손에 넣은 공격자는 타원곡선 KEM으로 봉인된 과거의 모든 엔벨로프를 복호화할 수 있습니다. Shor 알고리즘이 이산로그 문제를 다항 시간에 풀기 때문입니다. ML-KEM은 NIST FIPS 203으로 표준화되어 있고 그 안전성은 Module-LWE로 환원되며, 이 문제를 푸는 효율적인 양자 알고리즘은 알려져 있지 않습니다. 768 파라미터 세트(NIST 범주 3)는 안전 마진과, 모든 주소가 담아야 하는 1,184바이트 캡슐화 키 사이의 절충점으로 선택했습니다. 엔벨로프는 ML-KEM-768과 ChaCha20-Poly1305를 결합한 것으로 1,348바이트이며, 고정 길이 메모 필드를 포함하면 1,860바이트입니다.
출처: randprotocol.org (양자 내성 섹션); fullnode README; docs/shielded.md §2
2. Pedersen이 아니라 Poseidon2 커밋먼트를 사용하는 이유는 무엇입니까?
Pedersen 커밋먼트는 완전 은닉(perfectly hiding)이지만 계산적으로만 바인딩(computationally binding)되며, 그 바인딩은 양자 공격자가 깨뜨리는 이산로그 가정으로 환원됩니다. 이산로그를 계산할 수 있는 공격자는 커밋먼트를 다른 값으로 열 수 있습니다. 오늘 공개된 커밋먼트는 원장이 존속하는 동안 건전성과 은닉성을 유지해야 하므로, 이 방식은 양자 공격자에 대해서도 성립한다고 믿어지는 가정 위에 있어야 하며, 실무적으로는 해시 함수를 뜻합니다. Poseidon2는 Goldilocks 필드 위에 정의된 산술화 지향 해시이므로 STARK 내부에서 계산할 때 제약 수가 적게 듭니다. 동일한 해시가 노트 커밋먼트, 깊이 32의 머클 트리, 널리파이어를 구현합니다.
출처: randprotocol.org (양자 내성 섹션); docs/shielded.md §1–2
3. BLAKE3와 Poseidon2, 두 가지 해시 함수를 쓰는 이유는 무엇입니까?
두 함수는 서로 다른 비용 모델에 맞게 최적화되어 있습니다. Poseidon2는 증명 내부에서 해시를 계산해야 하는 모든 곳, 즉 노트, 커밋먼트 트리, 널리파이어, zkVM의 내부 테이블에 사용합니다. 비용이 제약 수로 측정되기 때문입니다. BLAKE3는 증명이 관여하지 않고 네이티브 처리량이 지배적인 모든 곳, 즉 블록 해시, 트리·널리파이어 집합·밸리데이터 레지스터·프로그램 테이블에 대한 상태 루트, 밸리데이터 주소(공개 키의 BLAKE3 다이제스트)에 사용합니다. Poseidon2는 CPU에서 상대적으로 느리고, BLAKE3는 산술화 비용이 상대적으로 큽니다. 각 함수는 자신의 비용 모델이 적용되는 곳에만 사용합니다.
출처: fullnode README (서명 / 해시 행); docs/architecture.md
4. 밸리데이터 서명에 Dilithium2(ML-DSA)를 사용하는 이유는 무엇입니까?
합의 서명이 제공하는 것은 갱신 가능한 속성입니다(질문 8). 스킴이 나중에 깨지면 앞으로의 메시지는 위조할 수 있지만 이미 최종 확정된 블록이 소급하여 무효가 되지는 않으므로, 이론적으로는 양자 공격자가 나타나기 전에 스킴을 교체할 수 있습니다. 그럼에도 제네시스부터 격자 기반 스킴을 채택한 것은 합의 투표, 브리지 가디언의 공동 서명, 밸리데이터 레지스터가 하나의 양자 내성 키 유형을 공유하게 하기 위해서입니다. 노드는 라운드 3 Dilithium2 파라미터 세트(crystals-dilithium 크레이트)를 구현하며, 이는 최종 FIPS 204 ML-DSA-44와 다릅니다. 공개 키는 1,312바이트, 서명은 2,420바이트입니다.
출처: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. SNARK가 아니라 투명한 STARK(Goldilocks 위의 FRI)를 사용하는 이유는 무엇입니까?
이 선택은 세 가지 요구 사항에서 나옵니다. 첫째, 신뢰 설정이 없어야 합니다. 건전성은 구조화된 참조 문자열이나 페어링 친화 곡선이 아니라 해시 함수의 충돌 저항성에만 의존합니다. 둘째, 양자 내성 건전성이 그럴듯하게 성립해야 합니다. 이 논증은 이산로그나 페어링 가정을 두지 않습니다. 셋째, 질문 2의 해시 기반 커밋먼트 스킴과 호환되어야 합니다. 비용은 증명 크기입니다. 번들 증명은 약 1.3 MB로, Zcash나 Monero의 차폐 트랜잭션보다 300–600배 큽니다. 이 비용은 감수하기로 했으며, 블록 수준 집계로 별도로 다룹니다(질문 31 및 34).
출처: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. 27 쿼리가 아니라 80 쿼리 FRI 프로파일을 사용하는 이유는 무엇입니까?
프로덕션 프로파일(80 쿼리, 블로업 계수 8, 20비트 작업증명 그라인딩)은 약 86비트의 증명 가능한 건전성을 제공하며, 27 쿼리 프로파일은 약 42비트입니다. 증명 크기는 2.75배가 됩니다. 검증 시간은 거의 달라지지 않아, 콜드 상태에서 809 ms가 838 ms로 늘고 웜 상태에서는 약 16 ms입니다. 증명 크기보다 증명 가능한 건전성을 우선했고, 크기 비용은 블록 공간 및 집계 설계로 넘겼습니다.
출처: docs/block-space.md §1, §3
7. 양자 내성 주장을 ‘프로토콜 전체 128비트’가 아니라 프리미티브별로 밝히는 이유는 무엇입니까?
초기 초안은 프로토콜 전체에 128비트 양자 내성 보안이 있다고 주장했습니다. 이 주장은 Brassard–Høyer–Tapp 한계와 맞지 않습니다. 이 한계에 따르면 양자 공격자는 약 2^85번의 쿼리로 256비트 해시의 충돌을 찾습니다. 그래서 이 주장은 보완하지 않고 철회했습니다. 현재 논문은 보안을 프리미티브별, 역할별로 기술합니다. 384비트 트랜스크립트 해시, 원상(preimage) 저항성만 필요한 곳에 쓰는 256비트 해시, Dilithium2, ML-KEM-768, 확장체 위의 FRI가 이에 해당하며, Module-LWE와 Module-SIS 가정 아래에서 해시 함수를 양자 랜덤 오라클로 모델링합니다. 노드의 트랜스크립트 해시는 현재 Poseidon2이며, 문서는 이를 미해결 구성 격차로 기재하고 있습니다.
출처: randprotocol.org (양자 내성 섹션)
8. ‘되돌릴 수 없는 속성 대 갱신 가능한 속성’의 구분은 무엇이며 왜 선택을 좌우합니까?
보안 속성은 미래의 어느 시점에 새로운 능력을 얻은 공격자가 이미 공개된 데이터에 대해 소급하여 위반할 수 있으면 되돌릴 수 없는 속성입니다. 노트 기밀성과 커밋먼트 은닉성이 이에 해당하므로, 공개되는 시점에 양자 내성을 갖추어야 합니다. 속성이 사용할 때마다 새로 확립되어 위협이 현실화하기 전에 스킴을 교체할 수 있으면 갱신 가능한 속성이며, 서명과 증명 건전성이 이에 해당합니다. 이 섹션의 모든 프리미티브 선택은 그것이 보호하는 속성을 분류하는 데서 나옵니다.
출처: randprotocol.org (양자 내성 섹션)
차폐 풀
9. 계정이나 잔액 없이 노트/UTXO 모델을 사용하는 이유는 무엇입니까?
계정 기반 원장은 구조상 잔액을 공개합니다. 잔액을 숨기려면 상태를 암호화하고 암호문에 대한 명제를 증명해야 하며, 이는 비용이 상당히 더 듭니다. 노트 풀은 커밋먼트와 널리파이어만 저장하며, 둘 다 소유자나 금액을 드러내지 않으므로 공개 상태에는 잔액 정보가 없습니다. 유일한 예외는 밸리데이터 레지스터로, 복제본들이 정족수 구성원에 합의할 수 있도록 지분 가중치가 공개되어야 합니다(질문 29).
출처: docs/shielded.md §1–2; docs/staking.md §1
10. 주소가 약 1.6 KB인 이유는 무엇입니까?
차폐 주소는 32바이트 소유자 필드 pk와, 송신자가 엔벨로프를 봉인하는 데 필요한 1,184바이트 ML-KEM-768 캡슐화 키로 구성됩니다. base58로 인코딩하면 약 1,667자입니다. 이 길이는 양자 내성 KEM의 직접적인 결과입니다. 승인된 설계(짧은 차폐 주소, 2026-09-17)는 주소를 약 256비트의 수신자 식별자로 대체합니다. 이 식별자는 지출 키로 서명되고 익스플로러가 제공하는, 갱신 가능한 레코드로 해석되므로, 캡슐화 키는 옮겨 적는 것이 아니라 가져오게 됩니다.
출처: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. 모든 키를 하나의 256비트 지출 키에서 파생하는 이유는 무엇입니까?
나머지 모든 키 자료는 단일 비밀 sk의 결정적 함수이며, 각각 고유한 도메인 구분자를 사용합니다. 열람 키 nk = H(NK, sk), 소유자 필드 pk = H(PK, nk), 널리파이어 H(NF, nk, cm), 발신 열람 키, ML-KEM 디캡슐화 키가 그것입니다. 따라서 키 파일에는 sk만 저장되고, 백업은 값 하나이며, 트리를 리프 0부터 다시 스캔하면 모든 노트를 복구합니다. 복구할 수 있는 두 번째 사본이 없으므로 지갑은 기존 키 파일을 덮어쓰기를 거부합니다.
출처: docs/shielded.md §1
12. 4-in-4-out으로 번들 형태를 고정하는 이유는 무엇입니까?
형태를 고정하면 무엇을 옮기든 모든 번들의 크기와 구조가 같아집니다. 각 번들은 정확히 네 개의 널리파이어와 네 개의 커밋먼트를 공개하며, 사용하지 않는 슬롯은 값이 0인 더미 노트입니다. 거스름돈 출력은 값이 0이더라도 공개하는데, 거스름돈 출력이 없으면 그 트랜잭션이 구별되기 때문입니다. 원래 사양은 Sapling을 따른 2-in-2-out이었습니다. 숨김 자산 번들과 함께 4-in-4-out으로 넓혀서 슬롯 0–1은 비공개 자산을, 슬롯 2–3은 수수료용 RAND를 담습니다. 슬롯을 셋이 아닌 넷으로 한 것은 토큰 전송이 최대 두 개의 RAND 노트로 수수료를 충당할 수 있게 하기 위해서입니다.
출처: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. 하나의 증명으로 어떤 자산(RAND, zUSD, RPL 토큰)이든 옮길 수 있는 이유는 무엇입니까?
14번 체인 이전에는 토큰 전송에 번들이 두 개 포함되었습니다. 하나는 RAND 수수료용이고 다른 하나는 자산용이었습니다. 따라서 증명이 두 번 필요했고, 어떤 토큰이 이동했는지 모든 관찰자에게 드러났습니다. 자산 숨김 게스트는 자산 식별자를 비공개 입력으로 받으므로, zUSD 전송은 RAND 결제와 구별되지 않습니다. 이 게스트가 티어 14(약 100초, 메모리 5.7 GB)에 들어가는 것은 입력을 루프로 읽고 머클 소속 검사를 융합하기 때문입니다. 완전히 펼친 구현은 티어 16(약 400초, 21 GB)이 필요하며, 이는 16 GB 머신의 메모리를 초과합니다.
출처: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. 수수료는 왜 공개이며 제안자에게 지급됩니까?
공개 수수료는 공개 스테이크 레지스터와 일관되며, 트랜잭션 수락 비용을 낮춥니다. 노드는 어떤 검증도 수행하기 전에 수수료 하한을 확인할 수 있습니다. 번들 증명은 균형 방정식 Σ 입력 = Σ 출력 + 수수료 + 소각을 강제하므로, 수수료는 어떤 노트인지 드러내지 않고 숨겨진 노트에서 지급됩니다. 감수하는 비용은 수수료 금액이 트랜잭션의 종류(전송 또는 프로그램 호출)를 드러낼 수 있다는 점입니다.
출처: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (결정 표); docs/fees.md §1
15. 예치(mint, bridge attest)의 금액은 왜 공개입니까?
풀에 들어오는 가치는 공개적으로 회계 처리되어야 하며, 브리지 증명(attestation)은 원천 체인에서 그에 상응하는 잠금이 발생했음을 보여 주는 공개 증거입니다. 이로 인한 가시성은 진입 단계에 한정되며, Zcash의 투명 주소에서 차폐 주소로의(t-to-z) 트랜잭션에 해당합니다. 예치된 노트의 이후 지출은 숨겨집니다.
출처: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (공개 항목 표)
16. 메모는 왜 512바이트 고정 필드입니까?
고정 길이 필드는 메모의 존재 여부와 길이를 원장이 드러내지 않도록 보장합니다. 메모가 활성화된 체인에서는 더미와 거스름돈을 포함해 노트를 생성하는 모든 엔벨로프가 정확히 1,860바이트입니다. 메모는 암호화된 엔벨로프 안에서만 전달되며 노트, 커밋먼트, 증명에는 포함되지 않습니다. 또한 이미 해당 노트를 복호화할 수 있는 당사자만 읽을 수 있습니다. 형식이 잘못된 메모는 빈 메모로 디코딩되므로, 노트 자체를 복구할 수 없게 만들지 않습니다.
출처: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. 증명은 왜 로컬에서 수행하며, 위임 prover는 이를 어떻게 훼손하지 않습니까?
증명 자체가 지출 승인입니다. 번들에는 서명도 발신자 필드도 없으므로 지출 키가 지갑을 떠날 필요가 없습니다. 티어 14 번들 증명에는 약 5.7 GB의 메모리가 필요하여 휴대폰과 브라우저가 제공할 수 있는 범위를 넘으므로, 위임 prover가 존재합니다. 분할 승인(번들 게스트 v3, 제네시스 매개변수 hc_auth)은 두 역할을 분리합니다. prover는 조회 키 nk만 받아 번들 증명을 생성하고, 지갑은 sk로 작은 티어 10 승인 증명을 생성합니다. 따라서 prover는 번들 증명을 구성할 수 있지만 지출을 승인할 수는 없습니다(질문 36).
출처: docs/prover.md §1; docs/shielded.md (분할 승인); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. 앵커 윈도우는 왜 256개 블록입니까?
증명은 특정 커밋먼트 트리 루트(앵커)에 대해 구성되며, 티어 14 번들 증명을 구성하는 데는 약 100초가 걸립니다. 따라서 원장은 제출 시점에 수 분 전의 앵커를 수락해야 합니다. 윈도우는 최초 사양에서 64개 블록이었으나, 블록 간격이 줄어듦에 따라 256개 블록으로 넓혀졌고, 이로써 실제 시간 기준의 길이가 증명 시간보다 길게 유지됩니다.
출처: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM과 기밀 연산
19. 게스트 ISA로 왜 RV32I입니까(RV64가 아니라)?
32비트 워드는 정확히 네 개의 바이트 림브로 분해되며, Goldilocks 소수 p = 2^64 − 2^32 + 1은 두 32비트 값의 곱이 체(field)를 넘치지 않을 만큼 충분히 큽니다. RV64는 ALU 및 메모리 테이블의 림브 열 수를 두 배로 늘립니다. 또한 RISC-V는 주류 컴파일러가 이미 지원하는 타깃이므로, 게스트 프로그램은 전용 언어로 작성된 프로그램이 아니라 일반적인 컴파일된 바이너리입니다.
출처: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. 256비트 체가 아니라 왜 Goldilocks입니까?
Goldilocks는 64비트 소수로, 그 연산은 CPU의 네이티브 64비트 명령어에 효율적으로 대응되며, 그 곱셈 군은 FRI가 요구하는 2의 거듭제곱 크기의 큰 부분군을 가집니다. 32비트 워드와 함께 사용하면 모든 트레이스 행이 좁게 유지되어, 프로덕션 프로파일의 증명을 노트북에서 수행할 수 있습니다. 작은 체에서 연산하여 잃는 건전성은 확장체에서 FRI 챌린지를 추출함으로써 회복됩니다.
출처: docs/zkvm.md §2; randprotocol.org (성능 섹션)
21. 옵코드별 가스 계량 대신 왜 가스 티어입니까?
옵코드별 가스는 Ethereum에서 모든 노드가 모든 트랜잭션을 재실행하고 실행 길이를 사전에 제한할 수 없기 때문에 존재합니다. Rand에서는 어떤 노드도 프로그램을 실행하지 않습니다. 발신자가 체인 밖에서 한 번 실행하고, 노드는 단일 STARK를 검증합니다. 이 검증 비용은 수행된 연산이 아니라 티어에만 의존합니다. 종료는 티어가 강제합니다. 2^t 사이클 안에 정지하지 않는 실행은 티어 t에서 증명을 만들 수 없기 때문입니다. 가격은 고정 하한에 헤더가 상한을 두는 가스 추정치를 더한 것이며, 블록 용량은 바이트 예산입니다. 가스는 EVM 및 sBPF 인터프리터 게스트 내부에서만, 비공개 상태로 나타납니다. 원천 체인의 의미론을 재현하는 데 필요하기 때문입니다.
출처: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. 트레이스는 왜 LogUp 버스로 연결된 아홉 개 테이블로 나뉩니까?
단일 모놀리식 테이블은 모든 행을 가장 넓은 연산의 너비에 맞춰 패딩해야 합니다. 트레이스를 CPU, 메모리, ALU, 범위, 니블, Poseidon2, 프로그램, 입력, 공개의 아홉 개 테이블로 분리하고 각각을 자신의 높이까지만 패딩하면 전체 트레이스가 작게 유지됩니다. LogUp 논증은 테이블 간의 멀티셋 관계를 성립시킵니다. Keccak 및 SHA-256 테이블은 선택 사항이며, 게스트가 해당 시스템 호출을 실행할 때만 포함됩니다.
출처: docs/zkvm.md §5
23. 프로그램 호출은 왜 출력 워드를 여덟 개만 게시합니까?
프로그램 호출은 공개 코드가 비공개 입력에 대해 올바르게 실행되었음을 보이는 증명이며, 원장은 영수증만 기록합니다. 32비트 워드 여덟 개면 결과, 커밋먼트 또는 결정을 바인딩하기에 충분하고, 출력 크기가 고정이므로 영수증의 형태가 프로그램에 대해 아무것도 드러내지 않습니다. 현재 출력은 데이터일 뿐이며, 프로그램이 스스로 가치를 전송할 수는 없습니다.
출처: randprotocol.org/usecases (플랫폼 참고); docs/confidential.md
24. 호출 입력 엔벨로프는 왜 있습니까?
비공개 입력을 보관하는 호출자는 나중에 호출이 무엇을 대상으로 계산되었는지 입증할 수 있습니다. 호출 입력 엔벨로프는 입력을 암호화하여 호출과 함께 저장함으로써 이를 지속 가능하게 하며, 지정된 감사자는 키로 이를 복호화할 수 있습니다. 이는 시장에는 기밀이고 지정된 규제 당국에는 공개되는 선택적 공개를 결제에서 프로그램 실행으로 확장합니다.
출처: docs/confidential.md (‘Call input envelopes’)
25. 제약 집합의 변경은 왜 하드 포크입니까?
모든 노드는 동기화 중에 모든 증명을 다시 검증하며, 증명은 그것을 생성한 제약 집합(AIR)에 대해서만 유효합니다. 따라서 AIR의 변경은 유효한 체인의 집합을 바꾸며, 노드별로 채택되는 것이 아니라 제네시스 컷에서 도입됩니다.
출처: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. 기준이 AIR가 아니라 왜 에뮬레이터입니까?
에뮬레이터는 머신의 읽을 수 있는 사양이고, AIR는 그 사양을 다항식 제약으로 인코딩한 것입니다. 둘이 일치하지 않으면 정의상 AIR가 오류입니다. 이로써 규범적 정의는 사람이 감사하기에 가장 실용적인 산출물에 놓입니다.
출처: docs/zkvm.md §5
합의와 노드
27. 왜 체인드 HotStuff BFT입니까?
체인드 HotStuff는 결정론적 최종성을 제공합니다. 스테이크 가중치 기준 3분의 2를 넘는 쿼럼에서, 블록 위에 연속된 세 개의 쿼럼 인증서가 형성되면 해당 블록은 최종 확정되며, 확정된 블록은 재구성되지 않습니다. 측정된 블록 간격은 1.2초이고 최종성에 이르는 시간은 약 3.6초입니다. 대상 기관 사용자는 장부 기입의 기준이 되는 결제 최종성을 필요로 하는데, 확률적 최종성을 가진 체인은 이를 제공하지 못합니다.
출처: fullnode README; randprotocol.org (성능 섹션); docs/architecture.md §6
28. 증명 검증은 왜 합의 루프 밖에 있습니까?
노드는 트랜잭션을 수락할 때(웜 상태에서 약 32 ms) 릴레이하기 전에 각 STARK를 검증하므로, 검증이 블록 제안의 크리티컬 패스에 놓이는 일이 없습니다. 따라서 블록 간격은 증명 크기가 아니라 합의 지연으로 결정됩니다. 검사는 비용 순으로 정렬되어 STARK가 마지막에 검증되며, 형식이 잘못된 트랜잭션은 가장 비싼 단계 이전에 거부됩니다.
출처: randprotocol.org; docs/architecture.md (‘How it works’)
29. 다른 모든 것이 차폐되는데 검증자 레지스터는 왜 공개입니까?
모든 레플리카는 어떤 검증자가 제안할 수 있는지, 어떤 투표가 쿼럼을 구성하는지에 합의해야 하며, 이를 위해서는 스테이크 가중치가 공개되어야 합니다. 따라서 레지스터는 스테이크 금액을 평문으로 보관합니다. 소유권과의 연결은 숨겨진 채로 유지됩니다. 본드는 차폐된 노트로 조달되고 인출금은 차폐된 노트로 지급되며, 어느 작업도 그 노트가 누구의 것인지 드러내지 않습니다.
출처: docs/staking.md §1
30. 동기화 중인 노드는 왜 인증서를 신뢰하지 않고 모든 블록을 다시 실행합니까?
늦게 합류한 노드는 체인을 수락하기 전에 모든 쿼럼 인증서를 검증하고, 모든 번들 증명과 호출 증명을 다시 검증하며, 그 결과로 얻은 영수증을 서로 비교합니다. 유효성이 서명만으로 확립되지 않고 증명으로 확립되므로, 이 절차는 서명만으로 보호되는 체인에 영향을 미치는 롱레인지 공격에 노출되지 않습니다. 이력에서 증명을 제거(pruning)하는 방안은 이 보장을 없애게 되므로 채택하지 않았습니다.
출처: docs/architecture.md; docs/aggregation.md (소개)
31. 증명이 1 MB를 넘는데도 블록 상한을 4 MiB로 유지하는 이유는 무엇입니까?
상한이 고정되어 있으면 블록 크기는 커질 수 없습니다. 수요가 용량을 초과하면 대신 처리량이 제한됩니다(80-query 프로파일에서는 블록당 차폐 전송 3건). 처리량 제한이 블록 크기의 무제한 증가보다 더 안전한 장애 양상이라고 판단했습니다. 선택한 해결책은 상한을 높이거나 건전성 수준을 낮추는 것이 아니라, 블록당 재귀 증명 하나로 구성하는 블록 수준 집계입니다.
출처: docs/block-space.md §1, §6
32. testnet은 왜 이력을 하루치만 남기고 정리합니까?
Dilithium2 서명 18개를 담은 쿼럼 인증서는 약 44 KB이며 블록마다 두 번 저장됩니다. 대부분 비어 있는 블록이 1.4 s마다 생성되는 상황에서 이는 노드당 하루 약 6.6 GB에 달했고, 노드 디스크가 가득 차 체인은 높이 248,953에서 쿼럼을 잃었습니다. 현재 testnet 풀 노드는 하루치 이력만 보관하고, 아카이브 노드 하나가 전체 이력을 보관하며, mainnet 노드는 전체 이력을 보관할 예정입니다. 원장 상태(트리, 널리파이어 집합, 레지스터, 프로그램)는 정리되지 않습니다.
출처: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. 왜 libp2p입니까?
노드는 Noise와 Yamux를 사용하는 TCP, 트랜잭션과 투표를 위한 gossipsub, 부트스트랩 목록을 사용하는 피어 검색용 Kademlia, 로컬 네트워크용 mDNS, 블록 동기화를 위한 request-response를 사용합니다. 이들은 널리 배포된 표준 구성 요소이므로, 노드는 자체 구현을 유지하지 않고도 피어 점수 산정, 재연결, 전송 계층 업그레이드를 그대로 이어받습니다.
출처: fullnode README (networking 행)
증명 시장과 집계
34. 왜 블록 수준 증명 집계입니까?
번들마다 약 1.3 MB의 자체 증명을 싣는다면 블록 공간은 번들 수에 비례하여 선형으로 증가합니다. N개의 번들 증명을 모두 검증하는 블록당 재귀 STARK 하나를 사용하면 온체인 증명 비용이 N에 관계없이 일정하게 유지됩니다. 그러면 밸리데이터는 CPU에서 집계 증명 하나(웜 상태에서 약 16 ms)만 검증하면 되므로 범용 하드웨어로도 검증이 가능하고, GPU를 갖춘 어그리게이터는 수수료의 증명 몫과 블록 보조금을 두고 별도의 허가 불필요(permissionless) 시장에서 경쟁합니다.
출처: docs/aggregation.md §1
35. 왜 밸리데이터, 어그리게이터, 위임 증명자의 세 역할입니까?
세 역할은 하드웨어 요구 사항이 서로 다르며 보수를 지급하는 주체도 다릅니다. 밸리데이터는 CPU에서 트랜잭션을 정렬하고 검증하며 수수료 중 검증 몫으로 보수를 받습니다. 어그리게이터는 GPU에서 재귀 블록 증명을 생성하며 증명 몫과 보조금으로 보수를 받습니다. 위임 증명자는 기기 성능이 부족한 발신자(휴대전화나 브라우저)를 대신해 번들 증명 하나를 생성하며, 해당 발신자로부터 비공개로 보수를 받습니다. 역할을 분리하면 검증 비용이 낮게 유지되고 증명 생성에는 경쟁이 생깁니다.
출처: docs/prover.md §1
36. 위임 증명자가 자금을 훔칠 수 없는 이유는 무엇입니까?
분리 승인(split authorisation) 방식에서 증명자는 조회 키 nk를 받지만 지출 키 sk는 받지 않습니다. 번들 증명은 c = H(AUTH, nk || salt)에 커밋하고, 지갑의 별도 승인 증명은 같은 c에 대한 sk의 지식을 증명합니다. sk가 없으면 증명자는 번들 증명은 계산할 수 있지만 유효한 승인은 만들 수 없으며, 지갑은 반환된 증명을 제출하기 전에 검증합니다.
출처: docs/shielded.md (분리 승인); docs/prover.md §8
브리지와 zUSD
37. 새 스테이블코인을 발행하지 않고 USDT/USDC를 원래 체인에 잠그는 이유는 무엇입니까?
Rand에서 자체 발행을 하면 준비금 용량이 발행사의 배포 결정에 좌우되는데, 이는 프로젝트가 통제할 수 없습니다. Ethereum, BSC, Tron, Solana에 USDT와 USDC를 잠그면 이 자산이 이미 유통되는 체인에서 준비금을 확보할 수 있고 새로운 발행 주체도 생기지 않습니다. zUSD 한 단위는 공개적으로 읽을 수 있는 보관 컨트랙트에 보관된 USDT 또는 USDC에 대한 청구권입니다.
출처: randprotocol.org (준비금 섹션)
38. 왜 t-of-n 가디언 집합이며, 왜 그 사실을 분명히 밝힙니까?
어테스테이션은 다른 체인에서 잠금이 발생했다는 사실을 Rand가 알 수 있는 유일한 증거이므로 임계값 그룹이 서명해야 하며, 유효한 어테스테이션에는 가디언의 3분의 2를 넘는 서명이 필요합니다. 그 결과로 생기는 신뢰 가정은 명시적으로 밝힙니다. 실질적인 보장은 준비금 지급 능력과 브리지 무결성 중 약한 쪽의 수준이며, t명의 가디언 연합은 대응하는 잠금 없이 발행을 승인할 수 있고, 노출 규모는 각 체인에 보관된 자산으로 제한됩니다. 이 가정은 원래 브리지를 구축하지 않아야 한다는 논거였습니다. 이 논거를 철회한 것은 아니며, 준비금 용량을 얻는 대가로 이 가정을 받아들인 것입니다.
출처: randprotocol.org (준비금 섹션, ‘이 구조의 비용’)
39. ECDSA 어테스테이션 외에 Dilithium2 공동 서명을 두는 이유는 무엇입니까?
원본 체인에는 격자 기반 서명 검증기가 없으므로 해당 체인에서의 출금은 기존의 고전적 ECDSA로 보호되며, 노출 규모는 보관 자산과 한도로 제한됩니다. Rand 원장이 가디언으로부터 수락하는 모든 메시지(입금과 가디언 집합 교체)에는 같은 가디언들의 Dilithium2 서명 쿼럼이 추가로 포함되어야 합니다. 따라서 외부 종단은 그렇지 않더라도 발행 경로는 양자 내성을 갖습니다. 공동 서명은 어테스테이션과 함께 전달되며 이미 배포된 컨트랙트를 변경할 필요가 없습니다.
출처: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. 입금 노트의 블라인딩을 선택하지 않고 유도하는 이유는 무엇입니까?
이전에는 릴레이어가 어테스테이션을 제출하기 전까지 입금 노트의 커미트먼트가 정해지지 않았기 때문에, 두 릴레이어가 같은 어테스테이션을 서로 다른 노트로 제출할 수 있었습니다. 블라인딩 인자 r을 어테스테이션에서 결정론적으로 유도하면 커미트먼트가 고정되므로, 경쟁하는 제출들은 하나의 커미트먼트로 충돌하게 되어 입금이 두 번 발행될 수 없습니다.
출처: docs/bridge.md (F1, chain 14)
41. Tron에 잠긴 USDT를 Ethereum에서 USDT로 인출할 수 있는 이유는 무엇입니까?
zUSD는 대체 가능합니다. 각 단위는 유입된 체인이 아니라 전체 준비금에 대한 청구권입니다. 유입과 유출을 분리하면, 목적지 체인에 충분한 준비금이 있다는 조건하에 유동성이 수요가 있는 곳으로 이동할 수 있습니다. 스테이블코인 논문은 총공급량이 체인별 준비금의 합을 넘지 않는다는 불변식 S ≤ Σ_c R_c가 모든 상태 전이에서 보존됨을 증명합니다.
출처: randprotocol.org (준비금 섹션)
42. 차폐가 분포는 숨기면서 수량은 숨기지 않는 이유는 무엇입니까?
zUSD 총공급량은 토큰 레지스트리에 공개되어 있고 각 체인의 준비금은 공개 잔액이므로 누구나 지급 능력을 검증할 수 있습니다. 숨겨지는 것은 소유자들 사이의 보유 분포입니다. 한 가지 한계가 있습니다. 네 체인의 준비금 잔액은 한 시점에 원자적으로 관측할 수 없으므로, 해당 체인들에 대한 검사는 지급불능을 사전에 막지 못하고 사후에 탐지합니다.
출처: randprotocol.org (준비금 섹션)
43. 소각이 자산을 명시하는 유일한 트랜잭션인 이유는 무엇입니까?
소각은 특정 체인의 특정 자산을 출금하므로, 보관 컨트랙트가 어떤 자산과 어떤 체인인지 알아야 합니다. 그 외의 모든 트랜잭션은 식별되지 않은 자산을 전송합니다. 소각은 브리지 수수료도 함께 담는데, 발신자가 곧 수혜자인 브리지 트랜잭션은 소각뿐이기 때문입니다.
출처: docs/architecture.md; docs/shielded.md §2
컴플라이언스와 공개
44. 왜 ‘모두에게 비공개’가 아니라 조회 키입니까?
Tornado Cash 사례가 보여 주듯, 규제 당국은 조사 대상 당사자의 협조에 공개 여부가 달린 프라이버시 시스템을 받아들이지 않았습니다. 따라서 Rand는 공개를 프로토콜의 객체로 다룹니다. 보유자 또는 규제를 받는 중개자가 조회 키를 보유하고, 감사인은 적법한 요청에 명시된 트랜잭션을 복호화할 수 있으며, 설계 목표는 거래 전략은 드러내지 않으면서 거래 상대방과 금액은 드러내는 범위 한정 키입니다. 급여 지급 같은 응용에서는 이러한 감사 가능성이 제약이 아니라 요구 사항입니다.
출처: randprotocol.org/usecases (규제 섹션, 급여 지급 사례)
45. 발신 조회 키를 수신 조회 키와 분리하는 이유는 무엇입니까?
분리하면 발신자는 수신자의 이력에 접근하지 않고도 자신이 지급한 내역을 증명할 수 있으며, 그 반대도 가능합니다. 발신 조회 키 ovk는 지갑이 보낸 봉투를 복호화하고, ML-KEM 역캡슐화 키는 지갑에 보내진 봉투를 복호화하며, 트랜잭션별 키는 정확히 하나의 출력만 제3자에게 공개합니다.
출처: docs/shielded.md §1–2
알려진 한계
46. 현재 증명은 무엇을 유출하며, 이를 문서화하는 이유는 무엇입니까?
2026-09-27의 검토에서, v1 게스트(chain 14–15)에서는 각 번들 증명이 어느 입력 슬롯에 실제 노트가 들어 있는지와 지출된 각 리프 인덱스의 해밍 가중치를 드러낸다는 사실이 확인되었습니다. 원인은 두 가지입니다. 테이블별 LogUp 합계가 블라인딩 없이 공개되며, 게스트의 제어 흐름이 입력이 더미인지 여부에 따라 분기합니다. 해결책은 분기 없는 게스트(v2)이며, 다음 제네시스에서 선택됩니다. 이 네트워크는 testnet이고 문서가 감사 기록의 역할을 하므로 이 발견 사항을 공개합니다.
출처: docs/shielded.md (‘현재 증명이 유출하는 정보’)
47. 상태 증가의 가격이 낮게 책정된 이유는 무엇입니까?
Ethereum은 저장된 상태가 모든 노드에 영구적인 비용을 부과하기 때문에 스토리지 쓰기에 가격을 매깁니다. 현재 Rand는 commitment tree, nullifier set, 프로그램 스토리지의 증가에 대해 워드당 배포 수수료와 고정 번들 수수료로만 가격을 매기고 있습니다. 이는 testnet에는 적절하지만, mainnet 이전에 해결해야 할 미결 가격 책정 문제로 기록되어 있습니다. 이 문제의 해결에 옵코드별 미터링이 필요한 것은 아닙니다.
출처: docs/fees.md §3 (caveats)
48. 독립적인 감사가 아직 완료되지 않은 이유는 무엇입니까?
이 프로토콜은 팀이 운영하는 testnet에서 활발히 개발 중이며, 설계가 안정되기 전까지 제약 집합과 체인 컷이 추가로 필요할 것으로 예상됩니다. 웹사이트는 모든 페이지에 이 사실을 명시하고 있습니다. 내부 감사 라운드(v3–v5)는 docs/consensus.md와 설계 명세서에 공개되어 있으므로, 향후 외부 감사가 참고할 수 있는 완전한 기록이 마련되어 있습니다.
출처: randprotocol.org (footer); docs/consensus.md