此页记录了 Rand 中每项主要设计决策的依据：组件必须提供的性质、提供该性质所依赖的假设，以及为此接受的代价。本页编制于 2026 年 9 月 29 日，资料来自本网站、白皮书摘要和参考全节点（github.com/randprotocol/fullnode：其 README、docs/ 和 docs/superpowers/specs/）。每个回答都注明了陈述该依据的文档；除以 randprotocol.org 开头的路径外，其余路径均指 fullnode 仓库。
状态。 Rand 运行在由创始团队运营的 testnet 上，协议尚未经过独立审计。下文若干决策分阶段在各个链版本中实现。所有数字均为编制时对运行中节点的测量值；它们预计会变化，引用前应重新测量。
密码学原语
1. 为什么票据加密使用 ML-KEM-768（Kyber）？
票据的明文被加密给接收方，封装在一个信封中，该信封会永久保留在公共账本上。因此，其机密性是一种不可撤销的性质（问题 8）：由于 Shor 算法可在多项式时间内求解离散对数，任何在日后某一时刻获得具有密码学意义的量子计算机的对手，都能解密所有以椭圆曲线 KEM 封装的历史信封。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. 为什么使用 Poseidon2 承诺而不是 Pedersen？
Pedersen 承诺具有完美隐藏性，但只有计算绑定性，其绑定性归约到离散对数假设，而量子对手可以破解该假设；能够计算离散对数的对手可以把承诺打开为另一个值。由于今天发布的承诺必须在账本的整个生命周期内保持可靠和隐藏，该方案必须建立在被认为可抵御量子对手的假设之上，实践中就是哈希函数。Poseidon2 是定义在 Goldilocks 域上的面向算术化的哈希，因此在 STARK 内部计算它所需的约束很少。票据承诺、深度为 32 的 Merkle 树和 nullifier 均由同一个哈希实例化。
来源：randprotocol.org（后量子部分）；docs/shielded.md §1–2
3. 为什么使用两种哈希函数——BLAKE3 和 Poseidon2？
这两种函数针对不同的成本模型进行了优化。凡是必须在证明内部计算哈希的地方都使用 Poseidon2——票据、承诺树、nullifier 以及 zkVM 的内部表——因为它的成本以约束数衡量。凡是不涉及证明、且原生吞吐量起主导作用的地方都使用 BLAKE3：区块哈希，覆盖树、nullifier 集合、validator 登记表和程序表的状态根，以及 validator 地址（公钥的 BLAKE3 摘要）。Poseidon2 在 CPU 上相对较慢；BLAKE3 的算术化成本相对较高。两者各自只用于其成本模型适用的地方。
来源：fullnode README（signatures / hashes 一行）；docs/architecture.md
4. 为什么 validator 签名使用 Dilithium2（ML-DSA）？
共识签名提供的是一种可更新的性质（问题 8）：日后若该方案被破解，只会使未来消息可被伪造，并不会追溯性地使已经最终确认的区块失效，因此原则上可以在量子对手出现之前替换该方案。尽管如此，我们仍从创世起就采用了格方案，使共识投票、桥守护者的联合签名和 validator 登记表共用同一种后量子密钥类型。节点实现的是第三轮 Dilithium2 参数集（crystals-dilithium crate），它与最终的 FIPS 204 ML-DSA-44 有所不同；公钥为 1,312 字节，签名为 2,420 字节。
来源：docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2；randprotocol.org
5. 为什么使用透明的 STARK（Goldilocks 上的 FRI）而不是 SNARK？
这一选择源于三项要求。第一，无需可信设置：可靠性只依赖哈希函数的抗碰撞性，而不依赖结构化参考串或配对友好曲线。第二，可信的后量子可靠性：该论证不作离散对数或配对假设。第三，与问题 2 中基于哈希的承诺方案兼容。代价是证明大小：一个 bundle 证明约为 1.3 MB，是 Zcash 或 Monero 屏蔽交易的 300–600 倍。这一代价是被接受的，并通过区块级聚合单独解决（问题 31 和 34）。
来源：randprotocol.org；docs/block-space.md §1；docs/zkvm.md
6. 为什么使用 80 次查询的 FRI 配置而不是 27 次？
生产配置（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 比特的转录哈希、仅在需要原像抗性处使用的 256 比特哈希、Dilithium2、ML-KEM-768，以及扩域上的 FRI——在 Module-LWE 和 Module-SIS 假设下，并将哈希函数建模为量子随机预言机。节点当前的转录哈希是 Poseidon2；文档将此列为一项尚未解决的配置缺口。
来源：randprotocol.org（后量子部分）
8. 什么是“不可撤销与可更新”分类，它为何决定了各项选择？
若某项安全性质在对手于未来任何时刻获得新能力后，仍可被其针对已发布数据追溯性地破坏，则该性质是不可撤销的；票据机密性和承诺隐藏性属于此类，因此它们在发布之时就必须具备抗量子能力。若某项性质在每次使用时都会重新建立，从而可以在威胁成为现实之前替换方案，则该性质是可更新的；签名和证明可靠性属于此类。本节中每个原语的选择，都源于对其所保护性质的分类。
来源：randprotocol.org（后量子部分）
屏蔽池
9. 为什么采用票据/UTXO 模型，没有账户和余额？
基于账户的账本在构造上就会公开余额；要隐藏余额，就必须加密状态并对密文证明命题，成本要高得多。票据池只存储承诺和 nullifier，两者都不会泄露所有者或金额，因此公共状态不含任何余额信息。唯一的例外是 validator 登记表，其权益权重必须公开，以便各副本对法定人数成员资格达成一致（问题 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)、nullifier H(NF, nk, cm)、出站查看密钥和 ML-KEM 解封装密钥，各自使用独立的域分隔符。因此密钥文件只存储 sk，备份就是单个值，从叶子 0 开始重新扫描树即可恢复所有票据。由于没有第二份副本可供恢复，钱包拒绝覆盖已有的密钥文件。
来源：docs/shielded.md §1
12. 为什么使用固定的 4 入 4 出 bundle 形状？
固定形状使每个 bundle 的大小和结构相同，与其所转移的内容无关。每个 bundle 恰好公布四个 nullifier 和四个承诺；未使用的槽位是零值的哑票据，找零输出即使价值为零也要公布，因为缺少找零输出会使该交易变得可区分。最初的规范是 2 入 2 出，沿用 Sapling。随着隐藏资产 bundle 的引入，它被扩展为 4 入 4 出，使槽位 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 链之前,一笔代币转账包含两个 bundle,一个用于支付 RAND 手续费,一个用于资产本身。这需要两次证明,并且会让任何观察者看出转移的是哪种代币。隐藏资产 guest 将资产标识符作为私有输入,因此 zUSD 转账与 RAND 支付无法区分。该 guest 之所以能在第 14 档(约 100 s、5.7 GB 内存)完成,仅因为它循环读取输入并融合了 Merkle 成员资格检查;完全展开的实现需要第 16 档(约 400 s、21 GB),超出了 16 GB 机器的内存。
来源:docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. 为什么手续费是公开的,并支付给提议者?
公开手续费与公开的质押登记册一致,并使准入成本低廉:节点在执行任何验证之前,就可以检查手续费下限。bundle 证明强制执行平衡方程 Σ inputs = Σ outputs + fee + burn,因此手续费从隐藏票据中支付,而不会泄露具体是哪些票据。所接受的代价是,手续费金额可能暴露交易的类别(转账或程序调用)。
来源:docs/superpowers/specs/2026-09-11-shielded-pool-design.md(裁定表);docs/fees.md §1
15. 为什么存入(mint、bridge attest)的金额是公开的?
进入资金池的价值必须被公开记账,而桥接证明(bridge attestation)是源链上发生了相应锁定的公开证据。由此产生的可见性仅限于进入这一步,类似于 Zcash 中从透明地址到屏蔽地址(t-to-z)的交易;所存入票据的后续花费是隐藏的。
来源:docs/superpowers/specs/2026-09-11-shielded-pool-design.md;docs/shielded.md(公开内容表)
16. 为什么备注(memo)是固定 512 字节的字段?
固定长度的字段确保账本不会泄露备注是否存在或其长度:在启用备注的链上,每个创建票据的信封,包括虚设票据和找零,都恰好是 1,860 字节。备注只存在于加密信封内部,绝不会出现在票据、承诺或证明中,并且只有本来就能解密该票据的各方才能读取。格式错误的备注会被解码为空备注,从而不会导致票据本身无法恢复。
来源:docs/shielded.md §2;docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. 为什么证明在本地生成,委托证明者(delegated prover)又为何不会破坏这一点?
证明本身就是花费授权:bundle 不携带签名,也没有发送方字段,因此花费密钥无需离开钱包。第 14 档的 bundle 证明需要约 5.7 GB 内存,超出了手机和浏览器所能提供的范围,因此有了委托证明者。拆分授权(bundle guest v3,创世参数 hc_auth)将这两个角色分开:证明者只接收查看密钥 nk 并生成 bundle 证明,而钱包使用 sk 生成一个小型的第 10 档授权证明。因此,证明者可以构造 bundle 证明,却无法授权花费(问题 36)。
来源:docs/prover.md §1;docs/shielded.md(拆分授权);docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. 为什么锚点窗口是 256 个区块?
证明是针对某个特定的承诺树根(即其锚点)构造的,而构造一个第 14 档的 bundle 证明约需 100 s。因此,账本必须接受提交时已有数分钟之久的锚点。最初的规范中该窗口为 64 个区块,随着出块间隔缩短,它被放宽到 256 个区块,使其以挂钟时间计的时长始终高于证明时间。
来源:docs/shielded.md;docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM 与机密计算
19. 为什么选择 RV32I 作为 guest 指令集架构(而不是 RV64)?
32 位字恰好分解为四个字节肢(limb),而 Goldilocks 素数 p = 2^64 − 2^32 + 1 足够大,使得两个 32 位值的乘积不会在该域中溢出。RV64 会使 ALU 表和内存表中的肢列数量翻倍。RISC-V 也是主流编译器已有的目标架构,因此 guest 程序是普通的编译后二进制文件,而不是用专门设计的语言编写的程序。
来源:docs/zkvm.md §2;research/docs/01-isa.md(「为什么是 RV32,而不是 RV64」)
20. 为什么选择 Goldilocks,而不是 256 位的域?
Goldilocks 是一个 64 位素数,其算术可以高效地映射到原生 64 位 CPU 指令上,并且其乘法群具有 FRI 所要求的大型 2 的幂次子群。结合 32 位字,它使每个轨迹行都保持较窄,从而使生产配置下的证明在笔记本电脑上也可行。在小域上工作所损失的可靠性,通过从扩展域中抽取 FRI 挑战来弥补。
来源:docs/zkvm.md §2;randprotocol.org(性能部分)
21. 为什么采用 gas 档位,而不是逐操作码的 gas 计量?
以太坊之所以有逐操作码的 gas,是因为每个节点都要重新执行每笔交易,且执行长度无法事先限定。在 Rand 中,没有任何节点执行程序:发送方在链下执行一次,节点验证单个 STARK,其验证成本只取决于档位,而与所执行的计算无关。终止性由档位强制保证,因为在 2^t 个周期内不能停机的执行,在第 t 档不存在证明。定价是一个固定的下限加上由区块头限定的 gas 估算值,区块容量则是字节预算。gas 仅作为私有状态出现在 EVM 和 sBPF 解释器 guest 内部,在那里需要它来复现源链的语义。
来源:docs/fees.md §3–4;docs/superpowers/specs/2026-09-28-gas-model-design.md
22. 为什么轨迹被拆分为由 LogUp 总线连接的九张表?
单一的整体式表会把每一行都填充到最宽操作的宽度。将轨迹拆分为九张表——CPU、内存、ALU、范围、半字节(nibble)、Poseidon2、程序、输入和公开表——每张表只填充到自身的高度,从而使总轨迹保持较小。LogUp 论证建立各表之间的多重集关系。Keccak 表和 SHA-256 表是可选的,仅当 guest 调用相应的系统调用时才会包含。
来源:docs/zkvm.md §5
23. 为什么一次程序调用只发布八个输出字?
程序调用是一个证明,表明公开代码在私有输入上被正确执行;账本只记录回执。八个 32 位字足以绑定一个结果、一个承诺或一项决定,而固定的输出大小确保回执的形状不会泄露关于程序的任何信息。输出目前仅为数据:程序本身无法转移价值。
来源:randprotocol.org/usecases(平台说明);docs/confidential.md
24. 为什么需要调用输入信封?
保留私有输入的调用者之后可以证明一次调用是基于什么计算的。调用输入信封使这一点变得持久:它将输入加密后与调用一并存储,指定的审计方可以用密钥将其解密。这把选择性披露——对市场保密、对指定监管方开放——从支付扩展到了程序执行。
来源:docs/confidential.md(「调用输入信封」)
25. 为什么约束集变更属于硬分叉?
每个节点在同步期间都会重新验证每个证明,而证明只有相对于生成它时所用的约束集(AIR)才有效。因此,AIR 的变更会改变有效链的集合,它在创世切换点引入,而不是由各节点逐个采纳。
来源:docs/architecture.md(「为什么约束集变更是硬分叉」)
26. 为什么以模拟器而不是 AIR 作为参照?
模拟器是机器的可读规范,而 AIR 是将该规范编码为多项式约束的结果。当两者不一致时,按定义是 AIR 有误。这使规范性定义位于最便于人工审计的制品之中。
来源:docs/zkvm.md §5
共识与节点
27. 为什么采用链式 HotStuff BFT?
链式 HotStuff 提供确定性最终性:在按质押加权的法定人数超过三分之二时,一个区块在其之上形成连续三个法定人数证书后即告最终确定,最终确定的区块绝不会被重组。实测出块间隔为 1.2 s,最终确定时间约为 3.6 s。目标机构用户需要可据以记账的结算最终性,而具有概率性最终性的链无法提供这一点。
来源:fullnode README;randprotocol.org(性能部分);docs/architecture.md §6
28. 为什么证明验证不在共识循环之内?
节点在接纳交易时(热状态下约 32 ms)验证每个 STARK,且在转发之前完成,因此验证永远不位于区块提议的关键路径上。出块间隔因此由共识延迟而非证明大小决定。各项检查按成本排序,STARK 最后验证,使格式错误的交易在最昂贵的步骤之前就被拒绝。
来源:randprotocol.org;docs/architecture.md(「工作原理」)
29. 既然其他一切都是屏蔽的,为什么验证者登记册是公开的?
所有副本必须就哪些验证者可以提议、哪些投票构成法定人数达成一致,这要求质押权重是公开的。因此,登记册以明文记录质押金额。与所有权的关联仍然是隐藏的:绑定(bond)由一张屏蔽票据出资,提取则支付到一张屏蔽票据中,两种操作都不会泄露该票据属于谁。
来源:docs/staking.md §1
30. 为什么同步中的节点要重新执行每个区块，而不是信任证书？
后加入的节点会验证每一份法定人数证书，重新验证每个 bundle 和调用证明，并在接受该链之前比对得出的收据。由于有效性由证明确立，而不是仅由签名确立，这一流程不会受到那些仅靠签名保障安全的链所面临的长程攻击。从历史中裁剪证明的方案被否决，因为它会取消这一保证。
来源：docs/architecture.md；docs/aggregation.md（简介）
31. 证明超过 1 MB，为什么仍将区块上限保持在 4 MiB？
上限固定时，区块大小无法增长；需求超出容量时，受限的是吞吐量（在 80 次查询的参数配置下，每个区块最多容纳三笔屏蔽转账）。吞吐量受限被认为比区块无限增长更安全的失效模式。选定的解决办法是区块级聚合，即每个区块一份递归证明，而不是提高上限或降低安全性级别。
来源：docs/block-space.md §1, §6
32. 为什么 testnet 只将历史裁剪保留一天？
携带 18 个 Dilithium2 签名的法定人数证书约为 44 KB，且每个区块存储两份。在每 1.4 s 产出一个、且大多为空块的情况下，这相当于每个节点每天约 6.6 GB；节点磁盘被写满，链在高度 248,953 处失去法定人数。testnet 全节点现在保留一天的历史，由单个归档节点保留全部历史，mainnet 节点将保留全部历史。账本状态——树、nullifier 集合、注册表和程序——从不裁剪。
来源：docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. 为什么选用 libp2p？
该节点使用带 Noise 和 Yamux 的 TCP，用 gossipsub 传播交易和投票，用带引导列表的 Kademlia 发现对等节点，在本地网络中使用 mDNS，并用请求-响应机制同步区块。这些都是标准且被广泛部署的组件，因此节点可以直接获得对等节点评分、重连和传输层升级，而无需自行维护这些实现。
来源：fullnode README（networking 一行）
证明市场与聚合
34. 为什么要做区块级证明聚合？
如果每个 bundle 都携带各自约 1.3 MB 的证明，区块空间会随 bundle 数量线性增长。每个区块只用一份递归 STARK 来验证全部 N 个 bundle 证明，就能让链上证明成本不随 N 变化。验证节点只需在 CPU 上验证一份聚合证明（预热后约 16 ms），因此普通硬件仍可参与验证；而配备 GPU 的聚合者则在一个独立的无许可市场中竞争，争取手续费中的证明份额和区块补贴。
来源：docs/aggregation.md §1
35. 为什么设三种角色——验证节点、聚合者、委托证明者？
三种角色的硬件要求不同，由不同的当事方付费。验证节点在 CPU 上对交易排序并验证，从手续费的验证份额中获得报酬。聚合者在 GPU 上生成递归区块证明，从证明份额和补贴中获得报酬。委托证明者为设备无法自行证明的发送方（手机或浏览器）生成单个 bundle 证明，由该发送方私下付费。角色分离使验证保持低成本，并使证明环节具有竞争性。
来源：docs/prover.md §1
36. 为什么委托证明者无法盗取资金？
在拆分授权下，证明者获得查看密钥 nk，但得不到花费密钥 sk。bundle 证明承诺于 c = H(AUTH, nk || salt)，而钱包另行生成的授权证明则证明其知道对应同一 c 的 sk。没有 sk，证明者可以计算 bundle 证明，却无法生成有效的授权；钱包在提交之前还会验证返回的证明。
来源：docs/shielded.md（拆分授权）；docs/prover.md §8
跨链桥与 zUSD
37. 为什么将 USDT/USDC 锁定在其原生链上，而不是发行新的稳定币？
在 Rand 上原生发行，会使储备容量取决于发行方的部署决策，而这些决策不在本项目的控制范围之内。将 USDT 和 USDC 锁定在 Ethereum、BSC、Tron 和 Solana 上，则是从这些资产已在流通的链上获取储备，且不引入新的发行方：每一单位 zUSD 都是对存放于公开可读托管合约中的 USDT 或 USDC 的索取权。
来源：randprotocol.org（储备部分）
38. 为什么采用 t-of-n 守护者集合，又为什么要明言这一点？
这份证明是 Rand 能够获得的、关于另一条链上发生过锁定的唯一证据，因此必须由一个阈值群体签署；有效的证明需要超过三分之二守护者的签名。由此产生的信任假设被明确陈述。实际的保证取决于储备偿付能力与桥完整性中较弱的一方；t 个守护者组成的联盟可以在没有对应锁定的情况下授权铸造；而风险敞口以各条链上所持有的托管资产为上限。这一假设最初正是反对构建桥的理由。它并未被撤回，而是为换取储备容量而被接受。
来源：randprotocol.org（储备部分，“What this costs”）
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 可以作为 USDT 在 Ethereum 上退出？
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 解封装密钥解密发给它的信封；而每笔交易的密钥则只向第三方披露恰好一个输出。
来源：docs/shielded.md §1–2
已知局限
46. 目前证明会泄露什么，为什么要将其写入文档？
2026-09-27 的审查发现，在 v1 guest（chain 14–15）下，每个 bundle 证明都会泄露哪些输入槽位持有真实票据，以及每个被花费叶子索引的汉明重量。原因有两方面：各表的 LogUp 总和未经盲化即被公布，且 guest 的控制流会根据输入是否为占位输入而分支。补救办法是一个无分支的 guest（v2），将在下一次创世时选用。公布这一发现，是因为该网络是 testnet，而文档即是其审计记录。
来源：docs/shielded.md（“What the proofs leak today”）
47. 为什么状态增长的定价偏低？
Ethereum 对存储写入定价,是因为被存储的状态会给每个节点带来永久性成本。目前,Rand 仅通过按字计费的部署费和固定的捆绑交易费,对承诺树、nullifier 集合和程序存储的增长定价。这对 testnet 而言是足够的,但已被记录为一个开放的定价问题,须在 mainnet-beta 之前解决;解决该问题并不需要按操作码计量。
来源:docs/fees.md §3(注意事项)
48. 为什么尚未完成独立审计?
该协议正处于活跃开发阶段,运行在由团队运营的 testnet 上,在设计稳定之前预计还会有更多约束集和链切换。网站在每一页上都有此说明。内部审计轮次(v3–v5)已发布在 docs/consensus.md 和各设计规范中,以便日后的外部审计有完整的记录可依据。
来源:randprotocol.org(页脚);docs/consensus.md