证明

使用本页可以确定证明机器的规格,理解为什么一笔转账需要一分多钟、为什么吞吐量的上限是区块空间而不是计算,并了解证明系统变更时哪些部分会失效。验证节点接受的一切,都有一份由它自己验证过的证明作为支撑。

证明陈述什么

链上运行的每个程序,都对应同一个关系:

这个 RV32IM 程序从 base_pc 开始,在由 H_IN 承诺的私有输入向量和由 H_PUB 承诺的公开输入段上运行,在 2ᵗ − 1 个周期内停机,至多消耗 GAS_LIMIT 的 gas,并发布了这八个输出字。

程序由其电路内摘要 hc 标识;验证者从不接触任何指令字。一笔屏蔽转账,就是把这一关系应用于隐藏资产捆绑客户机程序:这是一个手工汇编的 4 入 4 出程序,其 hc 在创世文件中固定为 hc_bundle。链 21 固定使用 guest v3(guests::bundle_hidden_v3,60af094a…6e3fce,自链 17 起;其摘要未随约束集 9 变化,验证密钥则变了)。链 14 和链 15 固定使用 v1(83d3a370…cd0ef8),链 16 固定使用无分支的 v2(651043e2…839b)。自链 17 起,每个捆绑包还携带第二份证明,即授权客户机程序(guests::auth,创世文件中的 hc_auth,1e4e347f…5639c1)的证明:捆绑包证明以查看密钥为输入,授权证明则证明发送者持有其背后的花费密钥。这就是拆分授权,它使得仅持有查看密钥的配对证明者也能生成捆绑包证明。隐藏资产客户机程序取代了链 13 及之前使用的 2 入 2 出 bundle 客户机程序;后者仅作为测试保留在全节点中,没有任何链固定它。机密调用是同一关系应用于已部署程序的情形(程序)。

钱包如何证明一个捆绑包

rand send <rand1…> <amount> 在本地完成全部私密工作,只有证明、承诺、作废符和密封信封会到达链上:

1. 用查看密钥扫描树并选取输入:最多两张 RAND 票据,其总额覆盖转账金额与槽位 2–3 中的手续费;对于代币转账或销毁,则在槽位 0–1 中最多选取两张该代币的票据,而手续费完全由 RAND 票据覆盖。未使用的输入槽位是一个哑元:金额为 0,归钱包所有,其成员资格检验失败在电路内被屏蔽,作废符仍然发布。自 guest v2 起,客户机程序是无分支的:哑元的路径与真实票据一样,沿全部 32 层逐层哈希。
2. 获取头部锚点(rand_getAnchor),以及每个真实输入的 32 层默克尔见证(rand_getWitness(index)),并将返回的根与锚点核对。
3. 构建四个输出:在转移价值的那一组中,放入接收者的票据和找零票据(即使金额为零也要有),其余位置为零金额哑元,封装给一次性密钥。
4. 将每个输出密封在一个信封中(以 ML-KEM-768 封装给接收者,并将交易密钥用钱包的 ovk 包裹),连同其 action 组装出完整交易,并计算其绑定值:blake3("rand-tx-bind-1" || …),作用于清空证明后的交易,共八个字(交易)。自链 20 起(其创世文件设置了 binding_domain: 1,链 21 沿用),绑定值为 blake3("rand-tx-bind-2" || …),前面依次是创世哈希和链 id,因此为某条链生成的证明在其他任何链上都无法通过验证,即使该链的链 id 相同。早于 v0.6.8 的钱包使用旧的绑定值,链 20 和链 21 会拒绝其证明;在链 21 上,早于 v0.8.0 的钱包更早就会被拒绝,因为它的证明属于约束集 8,无法解码。
5. 授权:取一个新的 256 位盐,在其 16 字的私有输入(花费密钥和盐)上证明授权客户机程序,以绑定值作为公开输入段,层级为层级 10。它由花费密钥派生出 nk,并发布 c = H(AUTH, nk ‖ salt),捆绑包将其作为 auth_commit 携带。
6. 在 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。配对证明者可以代替钱包生成的正是这份证明;授权证明则在钱包自己的机器上生成。
7. 核对证明所发布的摘要与由明文计算出的摘要是否一致,然后提交 Transaction { chain_id, bundle, action: None }。

自链 14 起,顺序至关重要:信封和 action 先于证明存在,因为证明要对它们作出承诺。对于调用,调用证明最先生成,并同样包含在绑定值之内。在 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 起的钱包输出格式;所示字节数是链 14 上提交的生产配置捆绑包证明的字节数。自链 17 起的钱包(包括链 21 上的 v0.8.0)会在这些行之前多打印两行,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 自转账上;质押搭载在一个通过 burn_r 销毁质押金的捆绑包上;代币销毁或桥销毁搭载在一个捆绑包上,该捆绑包从槽位 0–1 销毁资产(burn_a、burn_asset),并从槽位 2–3 支付 RAND 手续费。一笔转账所转移的资产是一个见证字,不出现在任何公开字段中。

成本

以下数字在开发用笔记本电脑(Apple Silicon,release 构建)上测得,即全节点自身文档所记录的数字:

验证是共识成本，由每个节点承担：验证密钥已预热时约 16 ms，为给定形状首次构建密钥时约 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 出 bundle 声明的形状为 program 12, input 10, keccak 0, sha256 0, public 2, mem 16；第 14 链的 bundle 证明声明 public 4，即八个绑定字的高度，不带任何哈希表，若声明了其他 tier、任一哈希表或其他 public 高度，则在构建任何验证密钥之前即被拒绝。自约束集 7 起，每个已声明的表至少有 2⁷ 行，因此第 20 链的 bundle 证明声明 public 7。

因此，第 20 链上的一笔转账携带约 2.87 MB 的证明（bundle 证明与 auth 证明），一次调用还要再加第三个证明；在约束集 9 下，不含 chip 的证明约增大 1 至 4 KB（cpu 表更宽），第 21 链的尺寸尚未测量。每个证明都必须不超过创世的 max_proof_bytes：第 21 链为 6,291,456（6 MiB），在其切换时为私有多签授权证明调高（估计为 3.4 MB 或更多，尚未测量）；第 17 至 20 链为 4 MiB；第 13 至 16 链为 8 MiB。在第 21 链上，一个 bundle 可以携带第二种形状的 auth 证明，即多签 auth guest 的证明（hc_auth_multisig，tier 18），账本依据证明声明的头部来区分二者（交易）。

隐藏资产 guest 之所以能放进 tier 14，仅仅是因为它在循环中读取私有输入，并融合了 Merkle 校验的兄弟节点读取；若以旧的展开式写法编写，同一关系会落在 tier 16，约需 400 s 和 21–22 GB，这将把 16 GB 的钱包排除在外。

证明是 CPU 密集型的，目前钱包在所有平台上都使用 CPU 后端。在大 tier 的运行中，prover 是单线程的：一台 16 vCPU 的 droplet 占用了一个核心的 99%，决定证明能否完成的是内存，而不是核心数（证明内存）。send、bond、call、deploy、bridge-mint 和 bridge-burn 上的 --cuda 标志选择 NVIDIA 后端，这需要以 --features cuda 构建。其内核于 2026-09-28 首次在真实硬件 NVIDIA H100 上运行，并与 CPU 参考实现一致，但发行版所 vendor 的 circuits 检出中没有提交任何 PTX，因此构建会以 no PTX for the GPU kernels 失败，直到内核被编译。尚未在任何机群 GPU 节点上测量过生产环境的证明。这里有意不回退到 CPU。CUDA 调用也无法封装输入信封，因为盐值从不离开 prover。tier 14 隐藏资产 bundle 证明的峰值内存约为 5.7 GB（Production FRI，CPU）；更大的内存级别涉及下文的解释器与递归证明（≥ 64 GB 及以上）。

节点如何验证

准入先执行低成本的检查（交易），然后：

• 根据公开的明文（anchor、四个 nullifier、四个承诺、fee、burn_a、burn_r、burn_asset、time、该 bundle 的 auth_commit，以及固定为零的 taint 字）重新计算 bundle 摘要，并要求其与证明所公布的摘要相等：见证破坏了该关系的证明会公布一个与任何明文都不匹配的被污染摘要。另一些检查是结构性的（guest 自己提供输出的发送方、资产和时间，因此 prover 无法选择它们），且私有资产不在摘要之中；
• 解码证明，并对照 tier 检查其声明的高度（check_declared_heights），使链对证明形状的约束就是验证者的约束。在检查任何签名或证明之前，每笔提交或经 gossip 到达的交易都会先经过规范证明筛查（在 hardening_v6 下，区块验证中也会如此）；自 fullnode v0.6.8（审计 v6，ZKV-4）起，该筛查首先将每个声明的度限制在 25 位（MAX_HONEST_DEGREE_BITS，即内存表上限加一），因此带有巨大度的头部不再会在为其重新推导诚实折叠调度期间拖住节点，筛查内部的 panic 会拒绝该交易，而不是让节点停止；
• 计算交易的绑定，并运行 Machine::verify_public(hc_bundle, &binding, proof)，即批量验证器，外加检查 H_PUB 是这八个字的摘要，因此被复制到带有另一动作、另一信封或另一链 id 的交易上的证明（自第 20 链起还包括另一条链的创世）无法通过验证（至第 13 链，该段为空，没有任何东西把证明绑定到其交易）；
• 针对 hc_auth 和同一绑定验证 auth 证明，并要求它所公布的 c 等于 auth_commit。没有 auth 证明的 bundle 会被拒绝（AuthMissing），c 不一致的 bundle 同样被拒绝（AuthMismatch）；
• 要求 bundle 证明的 GAS_LIMIT 等于创世的 bundle_gas_limit，即 20,479，auth 证明的则等于 1,279，这是两个 guest 的头部上限（BundleGasLimit、AuthGasLimit）；
• 对于调用，针对程序所存储的 code_hash 做同样的检查，以程序的公共字后接调用绑定作为该段（RPL-2 的 Invoke 会把其转换作为上下文字附加，程序），然后依据证明所声明的 gas 上限及其字节数检查费用（费用）。

通过 RPC 或 gossip 提交的交易，在四个工作线程、64 深的队列之后、共识循环之外被验证，只有验证通过后才会继续 gossip；每个对等节点的令牌桶（突发 16，每秒补充 4）限制对等节点能让节点验证的量，8,192 项的缓存则对已被永久拒绝的交易的重复提交免费作答。所提议区块内的证明，其验证在区块被应用时仍运行于共识循环上。同步的节点在接受每个区块之前，会重新验证其每一份证书和每一个证明；没有任何东西仅因法定人数签过名就被信任。

Tier

自 fullnode v0.5.6（2026-09-25）起，高于 tier 14 的调用证明会在构建验证密钥之前被拒绝（CallTierTooHigh），携带它的区块无效；一次调用最多还可携带 128 次 Keccak-f 置换和 128 次 SHA-256 压缩。tier 16 至 20 仍然可以证明，但仅限链下：其上的各行都无法在第 21 链上被调用，并且第 21 链与第 19、20 链一样，拒绝部署对任何 tier 14 调用而言过大的程序，即没有公共输入且超过 8,180 个字的程序（ProgramUncallable）（预算）。

prover 选择预算足以覆盖周期数加上程序与输入摘要行的最小 tier；放不下的运行会在证明之前失败。只有 tier 是公开的。每上一级，证明时间大致翻两番，证明尺寸略有增加。自第 20 链起，调用的费用取决于其证明所声明的 gas 上限及其字节大小，而非 tier；在第 21 链上，该下限被销毁，而不是支付给提议者（费用）。

约束集与硬分叉

约束集是验证者所检查的表、列、总线、公共值和 FRI 参数的精确集合。在一个约束集下生成的证明无法在另一个约束集下通过验证，双向皆然，而节点启动时的重放会重新验证其链中的每一个证明，因此以不同约束集构建的节点会在第一个证明处失败并被截断。这就是为什么对约束集的每一次更改都要作为新的链 id 切换、且所有节点使用同一构建，也是为什么 rand_status 会报告 hc_bundle 和 hc_auth，以及构建与创世不一致的节点拒绝启动。

链 14 和链 15 没有改变任何约束。链 15 的节点将 Poseidon2 的 86 个轮常数作为字面量表内置,而不是由种子抽取(审计 ZKV-2)——数值相同,因此没有任何哈希、摘要或证明发生变化。链 14:隐藏资产的 bundle 是一个新的 guest(新的 hc_bundle),交易绑定使用集 6 已在电路中绑定的公开段。它仍然是一次硬分叉——bundle 的传输格式、固定的 guest 以及每个交易 id 都发生了变化,携带 bundle 的链 13 交易会被新版本拒绝,而在分叉之前构建的钱包所生成的空段证明也会被链拒绝。

此后的各条链都改变了证明的构成。链 16(fullnode v0.6.1,2026-09-28)迁移到约束集 7,固定了无分支的 bundle guest v2 和集 hardening_v6,起因是 2026-09-27 的审查表明,过短的表和未加盲的 LogUp 终端会泄露私有数据(zkVM 的工作原理)。每个验证者密钥都发生了变化。链 17(v0.6.3,2026-09-29)保持集 7,并加入了拆分授权:bundle guest v3、auth guest、bundle 传输格式中的两个新字段,以及交易 id 域 rand-txid-3。链 18(v0.6.7-rc1,2026-09-29)为 gas 计量迁移到约束集 8,其在证明大小上的实测开销不到 1%。链 19(2026-10-01)是在同一个 v0.6.7 版本上对链 18 的重新创世,证明方面没有任何改变。链 20(fullnode v0.6.8,2026-10-01)保持约束集 8 以及相同的 guest 和验证者密钥,改变的是证明所绑定的对象:交易绑定和调用绑定携带创世哈希(binding_domain: 1),这是由钱包和账本计算的公开输入,因此没有电路发生变化。它仍然是一次硬分叉,因为 v0.6.7 钱包的证明无法在其上通过验证。链 21(fullnode v0.8.0,2026-10-12)为私密多签迁移到约束集 9:一次 Dilithium2 验证主要是模 q 的多项式运算,按 RV32 指令计为 880,102 个周期,使用 MODQ 系统调用时为 80,572 个周期,这使得多签 auth guest(hc_auth_multisig,9705f8e2…8247,tier 18)能够在 tier 18 的 262,143 个周期内检查最多三个签名。bundle guest 和单密钥 auth guest 保持原有摘要,每个验证者密钥和证明编码都发生了变化,v0.8.0 版本在启动时会拒绝链 18 至 20;来自旧版钱包的证明无法在链 21 上解码。每个版本都按创世哈希拒绝其之前的链。

代码中有两条值得了解的审计说明:TIER 公开值由验证者对照证明头部和批次的度数位进行检查,但电路本身并不对其施加约束(审计 ZL1,标记留待下一个集处理而未修复,因为移除它会改变公开值的布局);H_IN 是 guest 可见的承诺,验证者不会将其与调用方提供的值进行比较,这是有意为之的设计。

即将推出:区块聚合

在链 14 和链 15 上,每个隐藏资产 bundle 证明约为 1.43 MB,4 MiB 的区块(默认值,也是链 12 的取值)只能容纳两笔 shielded 转账;在 2 入 2 出 bundle 的约 1.3 MB 下可容纳三笔。链 13、14 和 15 将区块上限提高到 20 MiB(max_block_bytes),可容纳十四笔。链 20 保持 20 MiB,其上一笔转账携带约 2.87 MB 的证明,因此一个区块约容纳七笔;链 21 设为 19 MiB(19,922,944 字节,即三个 6 MiB 的证明外加 1 MiB),约容纳六笔。fullnode 在 2026-09-12 选择的补救方案,优于修剪历史和增大区块,是区块级聚合:每个封存窗口生成一个递归证明,用来验证 N 个 bundle 证明,从而使历史保持端到端的证明携带,同时原始证明可以被丢弃。它已构建并合并,但尚未激活,而且自链 14 起,它在激活之前必须重新测量:其所接纳的 bundle 形态是在空公开段(public 2)下测得的,而绑定交易的 bundle 声明 public 4,因此在链 14 上生成的 bundle 证明都不匹配。约束集 7 和 8 再次改变了该形态:一个 bundle 证明现在声明 public 7 并发布 35 个值,因此聚合的接口是每个证明 35 个字。节点版本在遇到带有 aggregation 部分的创世时会拒绝启动,而链 14 至 20 在创建时均没有该部分。带有动态 gas 价格的创世(例如链 20 的创世)同样会在与 aggregation 部分并存时被拒绝。自 fullnode v0.5.8 起,聚合证明还会绑定其聚合者(审计 AGG-2:程序吸收 aggregate_binding(chain_id, aggregator, nonce)),因此所接纳形态的程序摘要必须在带有该变更的版本上测量。激活还需要针对已修复的递归验证者完成端到端的伪造聚合演练,该演练尚未进行,并且需要就 auth 证明作出决定:聚合程序只验证 bundle 证明,因此在拆分授权的链上,封存一个窗口会把一笔转账从约 2.87 MB 缩小到约 1.37 MB,而不是缩小到零。

已构建的部分:

• 第二台以 Goldilocks 为原生域的机器(递归 VM,randprotocol-rvm),其验证者程序在 tier 21 下用约 197 万行检查一个 RV32 证明(约束集 7 下为 2,044,506 行),以及一个对一个窗口内的 bundle 证明做 N 泛化的聚合程序;
• 两种角色:验证者保持低 CPU 开销,每个封存区块只验证一个聚合;聚合者(无需许可、带保证金的登记,配有 shielded 收款地址)在 GPU 级机器上生成聚合证明,并获得所覆盖 bundle 的证明份额,外加按减半计划发放的新 RAND 区块补贴;
• 五种操作(RegisterAggregator、UnbondAggregator、WithdrawAggregator、SlashAggregator、Aggregate;SlashAggregator 保留在传输格式中但会被拒绝,因为重试的聚合会重新签署相同的 nonce,并不构成双重签名),九步接纳流程,将所覆盖的 bundle 封存并修剪为每个约 3 KB 的公开字段,使新节点每个窗口只需一次递归验证的封存形式同步,RPC 方法 rand_getAggregate、rand_getAggregators、rand_getUnsealed、rand_getRawTransaction,以及 rand-node aggregate --watch 守护进程。

在测试 FRI 配置下的测量结果:一个 N=1 的聚合在负载较高的笔记本电脑上约用 26 分钟完成证明(327,035 字节);一个新节点在不到一秒内应用了一个七区块的封存批次,仅需一次递归验证。最初界定的机器等级:N=1 需要 ≥ 64 GB 主机内存,N=2 需要 ≥ 128 GB,N=3 需要 ≥ 160 GB;生产环境中 N ≥ 2 属于 CUDA 后端,而它需要一个尚不存在的 GPU 节点。在约束集 7 下于 256 GB 机器上测得(2026-09-28 和 29),N=2 聚合占用 133 GB,N=3 占用 221 GB,而生产退出证明(针对一个内层证明的验证者程序)超过了 256 GB。上述数据均未在约束集 8 或 9 下重新测量。在聚合激活之前,链 21(其创世与链 20 一样没有 aggregation 部分)上没有任何聚合可以替代证明:它的两个归档节点保留所有原始证明,其验证者则修剪 24 小时之前的历史。