이 페이지는 증명 머신의 규모를 산정하고, 전송 하나에 1분 넘게 걸리는 이유와 처리량의 한계를 정하는 것이 연산이 아니라 블록 공간인 이유를 이해하며, 증명 시스템이 바뀔 때 무엇이 깨지는지 파악하는 데 쓰입니다. 검증자(validator)가 수락하는 모든 것은 검증자가 직접 검증한 증명으로 뒷받침됩니다.
증명이 진술하는 것
체인이 실행하는 모든 프로그램에 대해 하나의 관계가 성립합니다.
이 RV32IM 프로그램은
base_pc에서 시작하여,H_IN으로 커밋된 비공개 입력 벡터와H_PUB으로 커밋된 공개 입력 세그먼트를 가지고 실행되었으며,2ᵗ − 1사이클 이내에 종료했고, 최대GAS_LIMIT의 가스를 소비했으며, 이 여덟 개의 출력 워드를 공개했다.
프로그램은 회로 내부 다이제스트 hc로 식별되며, 검증자(verifier)는 명령어 워드를 전혀 보지 않습니다. 셀딩된(shielded) 전송은 이 관계를 **숨김 자산 번들 게스트(hidden-asset bundle guest)**에 적용한 것입니다. 이 게스트는 수작업으로 어셈블된 4-입력-4-출력 프로그램이며, 그 hc는 제네시스 파일에 hc_bundle로 고정되어 있습니다. 체인 20은 게스트 v3(guests::bundle_hidden_v3, 60af094a…6e3fce, 체인 17부터)를 고정합니다. 체인 14와 15는 v1(83d3a370…cd0ef8)을, 체인 16은 분기 없는 v2(651043e2…839b)를 고정했습니다. 체인 17부터 모든 번들은 두 번째 증명, 즉 인증 게스트(auth guest)(guests::auth, 제네시스 hc_auth, 1e4e347f…5639c1)의 증명도 함께 담습니다. 번들 증명은 조회 키(viewing key)를 입력으로 받고, 인증 증명은 발신자가 그 키에 대응하는 지출 키(spend key)를 보유하고 있음을 보입니다. 이것이 분할 인증이며, 조회 키만 가진 짝지어진 프로버(paired prover)가 번들 증명을 만들 수 있게 해 줍니다. 숨김 자산 게스트는 체인 13까지 쓰인 2-입력-2-출력 bundle 게스트를 대체했습니다. 이전 게스트는 fullnode에 테스트용으로만 남아 있으며 어떤 체인도 고정하지 않습니다. 기밀 호출(confidential call)은 배포된 프로그램에 같은 관계를 적용한 것입니다(Programs).
지갑이 번들을 증명하는 방법
rand send <rand1…> <amount>는 비공개 작업을 로컬에서 수행하며, 증명, 커밋먼트, 널리파이어(nullifier), 봉인된 봉투(envelope)만 체인에 도달합니다.
- 조회 키로 트리를 스캔하고 입력을 고릅니다. 금액과 수수료를 충당하는 RAND 노트는 슬롯 2–3에 최대 두 개입니다. 토큰 전송이나 소각의 경우에는 해당 토큰의 노트를 슬롯 0–1에 최대 두 개 두고, RAND 노트는 수수료만 충당합니다. 사용하지 않는 입력 슬롯은 더미입니다. 금액은 0이고 지갑이 소유하며, 회로 내에서 멤버십 실패가 마스킹되고, 널리파이어는 그대로 공개됩니다. 게스트 v2부터 게스트는 분기가 없습니다. 더미의 경로도 실제 노트와 마찬가지로 32개 레벨 전체에 걸쳐 해시됩니다.
- 헤드 앵커(
rand_getAnchor)와 각 실제 입력의 32레벨 머클 증인(rand_getWitness(index))을 가져오고, 반환된 루트를 앵커와 대조합니다. - 출력 네 개를 구성합니다. 가치를 이동시키는 그룹에는 수신자의 노트와 거스름돈 노트를 두며(0이어도 존재합니다), 그 외에는 금액 0의 더미를 일회용 키로 봉인하여 둡니다.
- 각 출력을 봉투에 봉인합니다(수신자에게는 ML-KEM-768, 거기에 지갑의
ovk로 감싼 트랜잭션 키를 더합니다). 액션과 함께 전체 트랜잭션을 조립한 뒤 그 **바인딩(binding)**을 구합니다. 바인딩은 증명을 비운 트랜잭션에 대한blake3("rand-tx-bind-1" || …)이며 여덟 워드입니다(Transactions). 제네시스가binding_domain: 1을 설정한 체인 20에서는blake3("rand-tx-bind-2" || …)이고 제네시스 해시가 먼저, 그다음 체인 ID가 오므로, 한 체인을 위해 만든 증명은 체인 ID가 같은 체인을 포함하여 다른 어떤 체인에서도 검증되지 않습니다. v0.6.8보다 오래된 지갑은 이전 바인딩을 사용하며, 체인 20은 그 증명을 거부합니다. - 인증합니다. 새로운 256비트 솔트를 뽑고, 16워드 비공개 입력(지출 키와 솔트)에 대해 인증 게스트를 증명하되, 바인딩을 공개 입력 세그먼트로 하여 티어 10에서 수행합니다. 인증 게스트는 지출 키에서
nk를 유도하고c = H(AUTH, nk ‖ salt)를 공개하며, 번들은 이를auth_commit으로 담습니다. - 번들 게스트를 1,212워드 비공개 입력(조회 키
nk, 경로가 있는 입력 슬롯 네 개, 앵커, 출력 네 개,fee,burn_a,burn_r, 비공개 자산A,time, 솔트)에 대해 같은 바인딩을 공개 입력 세그먼트로 하여 티어 14에서 증명합니다. 이 증명은 소유권, 멤버십, 각 실제 입력이 자기 슬롯의 자산을 담고 있다는 사실, 네 개의 널리파이어, 동일한c, 그리고 두 개의 잔액식in₀ + in₁ = out₀ + out₁ + burn_a와in₂ + in₃ = out₂ + out₃ + fee + burn_r을 보입니다. 이것은 짝지어진 프로버가 지갑을 대신해 만들 수 있는 증명이며, 인증 증명은 지갑 자신의 머신에서 만듭니다. - 증명이 공개한 다이제스트를 평문에서 계산한 값과 대조하고,
Transaction { chain_id, bundle, action: None }을 제출합니다.
체인 14부터 순서가 중요합니다. 증명이 봉투와 액션에 커밋하므로, 봉투와 액션이 증명보다 먼저 존재해야 합니다. 호출의 경우 호출 증명이 먼저 만들어지며 이 역시 바인딩 안에 들어갑니다. hardening_v6 체인에서 호출 증명은 두 증명을 모두 비운 트랜잭션의 호출 바인딩 위에서 만들어지는데(체인 16~19는 rand-call-bind-1, 체인 20은 제네시스 해시를 포함한 rand-call-bind-2), 이 바인딩은 수수료 번들의 널리파이어를 포함하므로 다른 번들 아래로 복사될 수 없습니다.
proving bundle (tier 14; about a minute on a laptop)…
proved in 98.3s: tier 14, 1423170 bytes
submitted transfer 4f2c… 1.5 RAND out, 98.499 RAND change, fee 0.001 RAND, anchored at height 192이 트랜스크립트는 체인 14 기준 fullnode 가이드에 실린 지갑의 출력 형식이며, 표시된 바이트 수는 체인 14에 커밋된 프로덕션 프로파일 번들 증명의 값입니다. 체인 17 이후의 지갑(체인 20의 v0.6.8 포함)은 이 줄들 앞에 proving the spend authorisation on this machine (tier 10; seconds)…와 authorisation proved in …: tier 10, … bytes 두 줄을 출력하고, 번들 줄은 proving the bundle (tier 14; about a minute and a half on a laptop)…로 표시합니다.
같은 구조가 모든 액션의 비용을 치르며, 항상 번들은 정확히 하나입니다. 배포, 호출, 토큰 등록, 토큰 발행은 RAND의 0값 자기 전송 위에 실리고, 본드(bond)는 burn_r로 지분을 소각하는 번들 위에 실리며, 토큰 소각이나 브리지 소각은 슬롯 0–1의 자산을 소각하고(burn_a, burn_asset) 슬롯 2–3에서 RAND 수수료를 지불하는 하나의 번들 위에 실립니다. 전송이 이동시키는 자산은 증인 워드이며 어떤 공개 필드에도 나타나지 않습니다.
비용
개발용 노트북(Apple Silicon, 릴리스 빌드)에서 측정한, fullnode 자체 문서에 기록된 수치입니다.
| 게스트 | 워드 | 사이클 | 티어 | 증명 | 증명 크기(프로덕션, 쿼리 80회) |
|---|---|---|---|---|---|
| 번들 게스트 v3 (체인 17~20) | — | 티어 14 예산에서 4,024 사이클과 Poseidon2 순열 273회의 여유 | 14 | ≈ 100 s, 최대 5.7 GB; 체인 18에서 102.5~134.0 s 측정(2026-09-30) | ≈ 1.50 MB; 체인 18에서 1,494,151~1,504,260 바이트 측정(2026-09-30) |
| 인증 게스트 (체인 17~20) | — | 250 | 10 | ≈ 7 s; 체인 18에서 6.6~19.9 s 측정(2026-09-30) | ≈ 1.37 MB; 체인 18에서 1,364,940~1,375,371 바이트 측정(2026-09-30) |
| 숨김 자산 번들 v1, 4-입력-4-출력 (체인 14, 15) | — | 티어 14 예산 미만이며 약 2,071 사이클(13%) 여유 | 14 | ≈ 98–100 s, 최대 5.7 GB | ≈ 1.43 MB; 체인 14에서 1,422,116 및 1,423,170 바이트 측정 |
bundle, 2-입력-2-출력 (폐기됨; 체인 13까지) | 3,811 | ≈ 9,160 | 14 | ≈ 100 s (단독 94.6–97.9 s; 동시 두 건은 각각 114 s) | 체인 8에서 1,321,773 바이트 측정 |
private_payment (호출) | 소량 | < 1,000 | 10 | ≈ 7 s | ≈ 1.37 MB (티어 10의 fib: 제약 집합 7에서 1,367,688 바이트, 제약 집합 6에서 1,298,729 바이트) |
| 해시 테이블 없는 호출 (오프체인 원장, 체인 18) | 773 | — | 14 | 114.8 s | 1,498,589 바이트 |
| SHA-256 테이블이 있는 호출 (부채 증명, 체인 18) | 994 | — | 14 | 122.9 s | 1,911,152 바이트 |
| Keccak 테이블이 있는 호출 (익명 투표, 체인 18) | — | — | 12 | 29.2 s | 3,346,865 바이트 |
검증은 모든 노드가 치르는 합의 비용입니다. 검증 키가 준비된 상태에서 약 16 ms이며, 특정 형상(shape)에 대한 키를 처음 만들 때는 약 230 ms입니다. 검증 키는 프로그램 내용에 의존하지 않고 (tier, program_log_height, input_log_height, keccak_log_height, sha256_log_height, public_log_height)로 키가 정해지므로, 노드는 형상마다 하나를 만들어 재사용합니다. 배포된 프로그램의 경우 키는 배포 시점에 백그라운드에서 한 번 계산됩니다(노트북에서 약 2 s, 2-vCPU 서버에서 7 s). 체인 13 이전의 2-입력-2-출력 번들은 program 12, input 10, keccak 0, sha256 0, public 2, mem 16 형상을 선언했습니다. 체인 14의 번들 증명은 여덟 개 바인딩 워드의 높이인 public 4를 선언하고, 해시 테이블을 전혀 갖지 않으며, 다른 티어, 어느 한쪽 테이블, 또는 다른 공개 높이를 선언하면 검증 키가 만들어지기도 전에 거부됩니다. 제약 집합 7부터는 선언된 모든 테이블이 최소 2⁷ 행을 가지므로, 체인 20의 번들 증명은 public 7을 선언합니다.
체인 20의 전송 트랜잭션은 번들 증명과 인증 증명을 합해 약 2.87 MB의 증명을 담고, 호출은 여기에 세 번째 증명이 더해집니다. 각 증명은 제네시스의 max_proof_bytes에 맞아야 하며, 체인 20에서 이 값은 4,194,304(4 MiB)입니다. 체인 1719와 같고, 체인 1316의 8 MiB에서 줄어든 값입니다.
숨겨진 자산 게스트가 티어 14에 들어가는 것은 비공개 입력을 루프로 읽고 Merkle 검사의 형제 노드 읽기를 하나로 합쳤기 때문입니다. 같은 관계를 이전의 펼친(unrolled) 방식으로 작성하면 티어 16에 해당하여 약 400초, 21–22 GB가 필요하므로 16 GB 지갑은 제외됩니다.
증명은 CPU 연산에 좌우되며, 지갑은 현재 모든 플랫폼에서 CPU 백엔드를 사용합니다. 대형 티어 실행에서 증명자는 단일 스레드로 동작했습니다. 16-vCPU 드롭릿은 코어 하나의 99%로 실행되었고, 증명이 완료되는지는 코어가 아니라 메모리가 결정했습니다(증명 메모리). send, bond, call, deploy, bridge-mint, bridge-burn의 --cuda 플래그는 NVIDIA 백엔드를 선택하며, --features cuda로 빌드해야 합니다. 이 커널은 2026-09-28에 실제 하드웨어인 NVIDIA H100에서 처음 실행되었고 CPU 기준 구현과 일치했습니다. 그러나 릴리스가 벤더링하는 circuits 체크아웃에는 PTX가 커밋되어 있지 않으므로, 커널을 컴파일하기 전까지 빌드는 no PTX for the GPU kernels 오류로 실패합니다. 플릿 GPU 노드에서 측정된 프로덕션 증명은 아직 없습니다. CPU로의 폴백은 의도적으로 두지 않았습니다. 또한 솔트가 증명자 밖으로 나가지 않기 때문에 CUDA 호출은 입력 봉투를 봉인할 수 없습니다. 티어 14 숨겨진 자산 번들 증명의 최대 메모리는 약 5.7 GB(Production FRI, CPU)이며, 더 큰 메모리 등급은 아래의 인터프리터 및 재귀 증명에 해당합니다(≥ 64 GB 이상).
노드의 검증 방식
수락 단계에서는 먼저 비용이 낮은 검사를 수행하고(트랜잭션), 이어서 다음을 수행합니다.
- 공개된 평문(앵커, 네 개의 널리파이어, 네 개의 커밋먼트,
fee,burn_a,burn_r,burn_asset,time, 번들의auth_commit, 그리고 0으로 고정된 오염(taint) 워드)으로부터 번들 다이제스트를 다시 계산하고, 이것이 증명이 공개한 값과 같아야 한다고 요구합니다. 증인이 관계를 위반한 증명은 어떤 평문과도 일치하지 않는 오염된 다이제스트를 공개합니다. 일부 검사는 구조적입니다(게스트가 출력의 발신자, 자산, 시간을 직접 제공하므로 증명자가 이를 선택할 수 없습니다). 비공개 자산은 다이제스트에 포함되지 않습니다. - 증명을 디코딩하고 선언된 높이를 티어와 대조합니다(
check_declared_heights). 따라서 증명의 형태에 대한 체인의 제한은 검증자의 제한입니다. 서명이나 증명을 검사하기 전에, 제출되거나 가십으로 전파된 모든 트랜잭션에 대해(그리고hardening_v6에서는 블록 검증에서도) 정규 증명 선별(canonical-proof screen)이 실행됩니다. fullnode v0.6.8(audit v6, ZKV-4)부터 이 선별은 먼저 선언된 모든 차수를 25비트(MAX_HONEST_DEGREE_BITS, 메모리 테이블의 상한에 1을 더한 값)로 제한합니다. 따라서 차수가 매우 큰 헤더가 정직한 폴딩 스케줄을 다시 도출하는 동안 노드를 붙잡아 두지 못하며, 선별 내부에서 패닉이 발생하면 노드가 멈추는 대신 해당 트랜잭션이 거부됩니다. - 트랜잭션의 바인딩을 계산하고
Machine::verify_public(hc_bundle, &binding, proof)를 실행합니다. 이는 배치 검증자에 더해H_PUB가 그 여덟 워드의 다이제스트임을 확인하는 검사이므로, 다른 액션, 다른 봉투 또는 다른 체인 id에 복사된 증명, 그리고 체인 20에서는 다른 체인의 제네시스에 복사된 증명은 검증되지 않습니다(체인 13까지는 세그먼트가 비어 있어 증명을 트랜잭션에 묶는 것이 없었습니다). - 인증 증명을
hc_auth및 동일한 바인딩에 대해 검증하고, 증명이 공개하는c가auth_commit과 같아야 한다고 요구합니다. 인증 증명이 없는 번들은 거부되며(AuthMissing),c가 다른 번들도 거부됩니다(AuthMismatch). - 번들 증명의
GAS_LIMIT가 제네시스의bundle_gas_limit인 20,479와 같아야 하고, 인증 증명의 값은 1,279와 같아야 한다고 요구합니다. 이는 두 게스트의 헤더 상한입니다(BundleGasLimit,AuthGasLimit). - 호출의 경우, 프로그램에 저장된
code_hash에 대해 같은 검증을 수행하며, 세그먼트로는 프로그램의 공개 워드 뒤에 호출 바인딩이 이어집니다(RPL-2Invoke는 자신의 전이를 컨텍스트 워드로 덧붙입니다, 프로그램). 이어서 증명이 선언한 가스 한도와 증명의 바이트 수에 대해 수수료를 검사합니다(수수료).
RPC 또는 가십으로 제출된 트랜잭션은 합의 루프 밖에서 64개 깊이의 큐 뒤에 있는 네 개의 워커 중 하나에서 검증되며, 검증을 통과한 뒤에야 다른 노드로 전파됩니다. 피어별 토큰 버킷(버스트 16, 초당 4회 보충)이 피어가 노드에 검증시킬 수 있는 양을 제한하고, 8,192개 항목의 캐시가 영구적으로 거부된 트랜잭션의 재제출에 비용 없이 응답합니다. 제안된 블록 안의 증명에 대한 검증은 블록이 적용될 때 여전히 합의 루프에서 실행됩니다. 동기화하는 노드는 블록을 수락하기 전에 모든 블록의 모든 인증서와 모든 증명을 다시 검증하며, 정족수가 서명했다는 이유만으로 신뢰되는 것은 없습니다.
티어
| 티어 | 사이클 예산 (2ᵗ − 1) | cpu 행 | 사용처 |
|---|---|---|---|
| 10 | 1,023 | 2¹⁰ | 인증 게스트; private_payment, fib |
| 12 | 4,095 | 2¹² | |
| 14 | 16,383 | 2¹⁴ | 숨겨진 자산 번들 게스트(및 폐기된 bundle 게스트); 가장 큰 호출 |
| 16 | 65,535 | 2¹⁶ | 테스트 스위트의 EVM 호출 증명; 변환된 ERC-20 approve(체인 13에서 호출됨) |
| 18 | 262,143 | 2¹⁸ | ERC-20 transfer 및 transferFrom, 변환 또는 인터프리터 방식 |
| 20 | 1,048,575 | 2²⁰ | SPL Token, 변환 또는 sBPF 인터프리터 게스트 |
fullnode v0.5.6(2026-09-25)부터 티어 14를 넘는 호출 증명은 검증자 키를 만들기 전에 거부되며(CallTierTooHigh), 이를 담은 블록은 무효입니다. 또한 호출은 Keccak-f 순열 최대 128회, SHA-256 압축 최대 128회만 담을 수 있습니다. 티어 16~20은 여전히 증명이 가능하지만 체인 밖에서만 가능합니다. 위 표에서 그 윗줄의 어느 것도 체인 20에서는 호출할 수 없으며, 체인 20은 어떤 티어 14 호출에도 너무 큰 프로그램, 즉 공개 입력 없이 8,180 워드를 넘는 프로그램의 배포를 거부합니다(ProgramUncallable)(예산).
증명자는 사이클 수에 프로그램 및 입력 다이제스트 행을 더한 값을 예산이 충족하는 가장 작은 티어를 선택하며, 맞지 않는 실행은 증명 전에 실패합니다. 공개되는 것은 티어뿐입니다. 한 단계 올라갈 때마다 증명 시간은 대략 네 배가 되고 증명 크기는 조금 늘어납니다. 체인 20에서 호출의 수수료는 티어가 아니라 증명이 선언한 가스 한도와 바이트 크기를 따릅니다(수수료).
제약 집합과 하드 포크
제약 집합은 검증자가 검사하는 테이블, 열, 버스, 공개 값, FRI 파라미터의 정확한 집합입니다. 한 집합에서 만든 증명은 다른 집합에서 어느 방향으로도 검증되지 않으며, 노드의 시작 시 리플레이는 체인의 모든 증명을 다시 검증합니다. 따라서 다른 집합으로 빌드된 노드는 첫 번째 증명에서 실패하고 체인이 잘려 나갑니다. 그래서 집합이 바뀔 때마다 모든 노드가 하나의 빌드를 쓰는 새 체인 id로 컷하며, rand_status가 hc_bundle과 hc_auth를 보고하고 빌드가 제네시스와 일치하지 않는 노드가 시작을 거부하는 것도 이 때문입니다.
| 집합 | 날짜 | 변경 내용 |
|---|---|---|
| 2 | 2026-09-10 | 첫 번째 리뷰 이후 다섯 가지 건전성 수정 |
| 3 | 2026-09-11 | Poseidon2 칩, 회로 내 hc, 증인으로서의 프로그램 테이블, 서브워드 메모리, RV32M, 27개 쿼리로 재조정된 FRI |
| 4 | 2026-09-11 | 자체 테이블을 가진 솔트된 입력 커밋먼트 H_IN; 플랫 바이너리 로더 |
| 5 | 2026-09-12 | 선택적 keccak 테이블; 증명이 선언하는 메모리 높이; zk 감사의 두 가지 치명적 수정; 80개 쿼리로 되돌린 FRI; MAX_PROOF_BYTES를 2 MiB로 |
| 6 | 2026-09-14 | 필수 public 테이블과 H_PUB; 선택적 sha256 테이블; 라이브러리로서의 EVM 및 sBPF 인터프리터 게스트; 34개의 공개 값. 체인 12~15가 실행한 집합. |
| 7 | 2026-09-28 | BLIND 버스를 통해 블라인딩된 모든 LogUp 터미널; 선언된 모든 테이블의 하한을 2⁷ 행으로; 입력, 공개, 솔트 워드에 대한 32비트 범위 검사; POSEIDON2_LEN 시스콜(7); JALR가 대상의 0번 비트를 지우고 funct3 = 0을 요구; key_derivation_v2로 솔트된 검증자 키. 체인 16과 17이 실행한 집합. |
| 8 | 2026-09-29 | 가스 미터: cpu 테이블의 GAS 열과 공개 값 GAS_LIMIT; 35개의 공개 값. 체인 18~20이 실행하는 집합. |
체인 14와 15는 제약을 변경하지 않았습니다. 체인 15의 노드는 Poseidon2의 86개 라운드 상수를 시드 기반 추출 대신 리터럴 테이블로 보유합니다(audit ZKV-2). 값은 같으므로 어떤 해시, 다이제스트, 증명도 바뀌지 않았습니다. 체인 14에서는 숨겨진 자산 번들이 새 게스트(새 hc_bundle)가 되었고, 트랜잭션 바인딩은 집합 6이 이미 회로에서 바인딩하는 공개 세그먼트를 사용합니다. 그럼에도 이것은 하드 포크입니다. 번들의 와이어 포맷, 고정된 게스트, 모든 트랜잭션 id가 바뀌었고, 번들을 담은 체인 13 트랜잭션은 새 빌드에서 거부되며, 포크 이전에 빌드된 지갑은 체인이 거부하는 빈 세그먼트 증명을 만들어 냅니다.
세 체인은 각각 증명이 무엇인지를 바꾸었습니다. 체인 16(fullnode v0.6.1, 2026-09-28)은 제약 집합 7로 옮겨 가면서 분기 없는 번들 게스트 v2를 고정하고 hardening_v6를 설정했습니다. 2026-09-27 검토에서 짧은 테이블과 블라인딩되지 않은 LogUp 종단값이 비공개 데이터를 유출한다는 점이 드러났기 때문입니다(How the zkVM works). 모든 검증자 키가 바뀌었습니다. 체인 17(v0.6.3, 2026-09-29)은 집합 7을 유지하면서 분리 인가를 추가했습니다. 번들 게스트 v3, 인가 게스트, 번들 와이어 형식의 새 필드 두 개, 트랜잭션 id 도메인 rand-txid-3가 그 내용입니다. 체인 18(v0.6.7-rc1, 2026-09-29)은 가스 미터를 위해 제약 집합 8로 옮겨 갔습니다. 증명 크기 측면에서 측정된 비용은 1% 미만입니다. 체인 19(2026-10-01)는 동일한 v0.6.7 빌드에서 체인 18을 다시 제네시스한 것이며, 증명에는 아무것도 바꾸지 않았습니다. 체인 20(fullnode v0.6.8, 2026-10-01)은 제약 집합 8과 동일한 게스트 및 검증자 키를 유지하면서, 증명이 무엇에 결속되는지를 바꿉니다. 트랜잭션 및 호출 바인딩이 제네시스 해시(binding_domain: 1)를 담으며, 이는 지갑과 원장이 계산하는 공개 입력이므로 회로는 하나도 바뀌지 않았습니다. 그럼에도 v0.6.7 지갑의 증명이 이 체인에서 검증되지 않으므로 하드 포크입니다. 각 빌드는 제네시스 해시로 이전 체인을 거부합니다.
코드에 남아 있어 알아 둘 만한 감사 메모가 두 가지 있습니다. 첫째, TIER 공개값은 검증자가 증명 헤더 및 배치의 degree bits와 대조하여 확인하지만 회로 자체가 제약하지는 않습니다(감사 ZL1). 이를 제거하면 공개값 레이아웃이 바뀌므로, 지금 고치지 않고 다음 집합에서 처리하도록 표시해 두었습니다. 둘째, H_IN은 게스트에게 보이는 커밋먼트이며, 검증자는 호출자가 제공한 값과 비교하지 않습니다. 이는 설계에 따른 것입니다.
Upcoming: block aggregation
체인 14와 15에서 숨겨진 자산 번들 증명 하나가 약 1.43 MB였기 때문에, 4 MiB 블록(기본값이자 체인 12의 값)에는 차폐 전송이 두 건 들어갔습니다. 2-in-2-out 번들의 약 1.3 MB에서는 세 건이 들어갔습니다. 체인 13, 14, 15는 블록 상한(max_block_bytes)을 20 MiB로 올려 열네 건을 담을 수 있게 했습니다. 체인 20도 20 MiB를 유지하며, 여기서 전송 한 건의 증명은 약 2.87 MB이므로 블록 하나에 약 일곱 건이 들어갑니다. fullnode가 (2026-09-12에) 프루닝이나 더 큰 블록 대신 택한 해법은 블록 수준 집계입니다. 봉인된 구간마다 N개의 번들 증명을 검증하는 재귀 증명 하나를 두어, 원본 증명을 버리더라도 히스토리가 끝까지 증명을 지닌 채로 남도록 하는 것입니다. 이는 구현되어 병합되었지만 활성화되지 않았으며, 체인 14 이후로는 활성화하기 전에 다시 측정해야 합니다. 허용되는 번들 형태를 빈 공개 세그먼트(public 2)로 측정했는데, 트랜잭션에 결속된 번들은 public 4를 선언하므로 체인 14에서 증명된 번들 중 이것과 일치하는 것이 없기 때문입니다. 제약 집합 7과 8은 이 형태를 다시 바꾸었습니다. 이제 번들 증명은 public 7을 선언하고 35개의 값을 공개하므로, 집계의 인터페이스는 증명당 35 워드입니다. 노드 빌드는 aggregation 섹션이 있는 제네시스에서는 시작을 거부하며, 체인 14부터 20까지는 이 섹션 없이 생성되었습니다. 체인 20처럼 동적 가스 가격을 가진 제네시스 역시 aggregation 섹션과 함께 있으면 거부됩니다. fullnode v0.5.8부터 집계 증명은 집계자에게도 결속됩니다(감사 AGG-2: 프로그램이 aggregate_binding(chain_id, aggregator, nonce)를 흡수합니다). 따라서 허용되는 형태의 프로그램 다이제스트는 이 변경이 포함된 빌드에서 측정해야 합니다. 활성화는 또한 수정된 재귀 검증자를 상대로 한 종단 간 위조 집계 시험을 기다리고 있는데, 이는 아직 수행되지 않았습니다. 인가 증명에 관한 결정도 남아 있습니다. 집계 프로그램은 번들 증명만 검증하므로, 분리 인가 체인에서 구간을 봉인하면 전송 한 건이 약 2.87 MB에서 약 1.37 MB로 줄어들 뿐 사라지지는 않습니다.
구현된 것은 다음과 같습니다.
- 두 번째 Goldilocks 네이티브 머신(재귀 VM,
randprotocol-rvm)으로, 이 머신의 검증자 프로그램은 티어 21에서 약 197만 행으로 RV32 증명을 검증합니다(제약 집합 7에서는 2,044,506행). 여기에 번들 증명 구간에 대한 N에 일반화된 집계 프로그램이 있습니다. - 두 가지 역할: 밸리데이터는 CPU 부담을 낮게 유지하면서 봉인된 블록마다 집계 하나를 검증합니다. 집계자(차폐 지급 주소를 가진, 허가 없이 참여하는 본드 등록제)는 GPU급 머신에서 집계를 증명하고, 포함된 번들의 증명 몫과 반감 일정에 따라 새로 발행되는 RAND로 지급되는 블록 보조금을 받습니다.
- 다섯 가지 액션(
RegisterAggregator,UnbondAggregator,WithdrawAggregator,SlashAggregator,Aggregate).SlashAggregator는 와이어 형식에 남아 있지만 거부됩니다. 재시도된 집계는 같은 nonce에 다시 서명하므로 이중 서명(equivocation)이 아니기 때문입니다. 아홉 단계의 허용 절차, 포함된 번들을 각각 약 3 KB의 공개 필드로 줄이는 봉인과 프루닝, 새 노드가 구간마다 재귀 검증 한 번만 치르면 되는 봉인 형태 동기화, RPC 메서드rand_getAggregate,rand_getAggregators,rand_getUnsealed,rand_getRawTransaction, 그리고rand-node aggregate --watch데몬이 있습니다.
테스트 FRI 프로파일에서 측정한 결과, 부하가 걸린 노트북에서 N=1 집계 하나를 증명하는 데 약 26분이 걸렸고(327,035 바이트), 새 노드는 7개 블록의 봉인 배치를 재귀 검증 한 번으로 1초 이내에 적용했습니다. 처음 정한 머신 등급은 N=1에 호스트 메모리 64 GB 이상, N=2에 128 GB 이상, N=3에 160 GB 이상입니다. 프로덕션의 N ≥ 2는 CUDA 백엔드의 몫인데, 이를 위한 GPU 노드는 아직 존재하지 않습니다. 256 GB 머신에서 제약 집합 7로 측정한 결과(2026-09-28 및 29), N=2 집계는 133 GB, N=3은 221 GB를 사용했고, 프로덕션 종료 증명(내부 증명 하나에 대한 검증자 프로그램)은 256 GB를 초과했습니다. 어느 것도 제약 집합 8에서는 다시 측정되지 않았습니다. 집계가 활성화되기 전까지 체인 20에서는 어떤 집계도 증명을 대신하지 않습니다. 두 아카이브 노드가 모든 원본 증명을 보관하고, 밸리데이터는 24시간보다 오래된 히스토리를 프루닝합니다.