运行验证者与聚合者

使用本页可在运行机器之前确定其配置规格。验证者开销很小，证明则不然：证明的内存随层级急剧增长，这是决定一台机器能否胜任的唯一数字。这里的每个数字都来自 testnet 或 fullnode 记录的实测。尚未最终确定的数字已作标注。

各角色的职责

验证者和观察者从不证明。屏蔽转账或调用由发送它的钱包证明；仅就交易包证明而言，则由与该钱包配对的证明者完成（运行节点）。目前机群中的验证者不做任何证明。

区块聚合已实现，但尚未启用。它需要创世配置中包含 aggregation 部分。Chain 21 没有该部分：聚合处于关闭状态，与 chain 9 至 20 相同，并且在创世配置带有该部分时，该构建拒绝启动。

配置速查

目前证明者是单线程的。 一台 16 vCPU 的 droplet 以一个核心 99% 的负载运行。更多核心不会让单个证明更快；决定证明能否完成的是更多内存。

验证者和观察者

内存和 CPU

最初的十八个验证者运行在 2 GB 的 droplet 上。验证一个证明开销很小：

验证者验证层级 18 或层级 20 的调用证明所需的内存，现已部分实测：在一台 48 GB 的 Apple Silicon 笔记本电脑上，独立于生成各证明的 DigitalOcean droplet，验证层级 18 的 transfer 证明耗时 50.2 秒，峰值 RSS 为 3.66 GB（已翻译），或 49.6 秒（解释器，RSS 未单独记录）；验证层级 16 的 approve 证明耗时 12.2 秒（RSS 未单独记录）。层级 20 尚未测量——目前还没有可供验证的层级 20 证明。自 v0.5.6 起，验证者不再构建如此之大的密钥：在构建任何验证密钥之前，会先检查调用证明的头部，层级高于 14 的调用（或 keccak 表大于 2^12、sha256 表大于 2^13 的调用）会被拒绝，既在准入时拒绝，也作为区块有效性规则拒绝。实测最坏的可准入调用头部验证耗时 4.7 秒、312 MB。

1 vCPU、2 GB 的 droplet 无法构建这些二进制文件。请在更大的机器上构建后再复制过去（见设置）。

磁盘

在 chain 21 上，与 chain 19 和 20 一样，26 个验证者中有 24 个运行 --prune-history 24h，保留约一天的区块；账本本身（票据、作废符、锚点、注册表）从不被裁剪。归档节点 obs1 和 rand-archive-2（二者同时也是验证者）不带该标志运行。mainnet 节点从不传入该标志。当数据目录所在文件系统的空闲空间低于 --min-free-disk-mb（默认 1,024 MB）时，节点拒绝启动；空闲空间低于其四倍时，rand_getHealth 返回 disk_low；等待 ok 的滚动升级会在正在填满磁盘的节点处停下。关于被裁剪的节点仍能应答什么，见历史裁剪。

删除已退役链的数据目录,在切换完成后进行。数据目录以创世哈希为键(data-<name>-<hash8>:chain 21 为 -ca76c276,chain 20 为 -6210cf07;六台 guardian 主机使用 /var/lib/randnode/data-21),因此旧目录会一直保留,直到你手动删除。chain 20 切换时,一台区域验证节点(syd1)启动后报 disk_low,仅剩 3.9 GB 可用空间,并将启动卡在 26 个中的 25 个,原因是 chain 14 至 17 的目录仍留在其上;删除后释放了 22 GB。将上一条链的目录保留一天作为回滚目标,然后删除。在满块情况下,自 chain 14 起每个原始捆绑包证明约为 1.42 MB(chain 13 及之前约为 1.3 MB)。自 chain 17 起,每个捆绑包还附带一个授权证明,因此一笔转账的证明约为 2.85 MB:捆绑包证明约 1.49 MB,授权证明约 1.36 MB(生产配置,2026-09-29 实测)。聚合一旦启用,会将已封存捆绑包的证明裁剪至约 3 KB,除非节点以 --keep-raw-proofs 运行。聚合不涵盖授权证明,后者保持完整大小。

网络

在公共节点上开放 TCP 30303 入站端口。位于 NAT 之后的节点通过 --bootstrap 主动向外连接。在满 4 MiB 区块的情况下,一条验证节点链路约承载 2 MB/s。

时钟

验证节点需要 NTP。chain 14 是第一条将挂钟时间纳入共识的链(桥加固 B2):

时钟慢 20 s 的验证节点会悄然停止投票:它看到每个诚实区块的时间戳都领先于自身时钟,因而扣留其投票,且不会出现任何故障提示。在 chain 21 上,与 chain 20 一样,26 个验证节点中须有 18 个投票才能提交任何内容。请检查每一个验证节点,并在时钟未同步的节点上安装 chrony:

timedatectl                     # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking 2>/dev/null || timedatectl show-timesync --all 2>/dev/null
apt-get install -y chrony && systemctl enable --now chrony

同样的 15 s 界限也适用于创世文件。请将 timestamp_ms 设置为接近启动时刻,且绝不要晚于它:创世时间戳比当前时间超前超过 15 s,则在挂钟时间到达之前不会提交任何区块 1;而远早于当前时间,则会使区块时间落后于挂钟,以每块不超过 60 s 的速度追赶(docs/deploy.md)。观察者节点不投票,因此投票规则不约束它。

testnet 运行所用的 DigitalOcean 规格

此表涵盖最初的十八个验证节点。自 2026-09-27 起,验证节点 A 也运行在 droplet(sgp1)上,而非笔记本电脑。另有八个验证节点在 chain 15 上缴纳了保证金(2026-09-27):两个归档节点 obs1 和 rand-archive-2(fra1),以及六台 guardian 主机。它们的 droplet 规格未在此记录,mkc1 和 mem1 是否已扩容也未记录。与 chain 19 和 20 一样,全部 26 个节点都是 chain 21 的创世验证节点,每个质押 1,000 RAND,截至 2026-09-30,全部 26 个密钥由同一运营者持有。

证明内存

钱包会为其发送的每笔交易生成证明,因此程序调用方需要具备该程序所在层级所需的内存。以下为实测界限。tier-18 的运行已在 DigitalOcean 上完成、生成证明并通过验证;tier-20 尚未完成。自 v0.5.6 起,链拒绝高于 tier 14 的调用证明(MAX_CALL_TIER),因此下表中 tier-16、18 和 20 的行是测量值,而非 chain 21 所接纳的调用(perp 状态证明与 private-multisig 授权证明均为 tier 18,是 chain 21 的例外:二者都不是调用);chain 14 上提交的每个调用均为 tier 10。

ERC-20 调用落在 tier 16 和 18,SPL Token 落在 tier 20(Ethereum、Solana)。尚无 tier 18 或 20 的证明是在 48 GB 机器上生成的。

聚合器

聚合器监视链,取一个窗口内已最终确认区块的捆绑包证明,对它们生成一个递归聚合证明并提交。包含该证明的区块称为封存区块。聚合器会因所涵盖捆绑包的证明份额,以及以新铸造 RAND 计的区块补贴,获得报酬,支付至其登记的收款地址。聚合是无需许可的:任何缴纳保证金的运营者都可以注册。

它仅存在于创世文件中带有 aggregation 部分的链上。chain 21 没有该部分,且其构建在遇到带有该部分的创世文件时会拒绝启动。

硬件

N = 2 和 N = 3 的数值于 2026-09-28/29 在一台 256 GB 的 DigitalOcean droplet 上、于约束集 7 下测得,而生产退出证明所需内存超过该机器的 256 GB。这些数值均未在 chain 18 至 20 所运行的约束集 8 下重新测量,因此应将 N = 1 一行视为下界。CUDA 后端于 2026-09-28 首次在真实硬件上运行,使用 NVIDIA H100:其内核为 sm_80 和 sm_90 构建为 PTX,并与 CPU 参考实现一致。在集群 GPU 节点上的生产测量仍待完成。每个节点还需为聚合程序支付一次性的启动密钥构建开销:测试配置(2¹⁹)下为 13.0 至 13.4 s,生产配置(2²¹)下预计为 30 至 70 s。

命令

# print a signed registration; the bond burns out of a wallet bundle as the register bundle's burn
rand-node aggregator register --key agg.key.json --bond <RAND> --payout rand1… --rpc http://127.0.0.1:8545

# the daemon: poll rand_getUnsealed, fetch the raw bundles, prove, seal the payment note, submit
rand-node aggregate --key agg.key.json --rpc http://127.0.0.1:8545 --watch

# leave, then withdraw the released bond into a note at the payout address
rand-node aggregator unbond --key agg.key.json --rpc http://127.0.0.1:8545
rand-node aggregator withdraw --key agg.key.json --rpc http://127.0.0.1:8545

在这类链上,rand status 会显示一个 aggregation 部分:已注册的聚合器、未封存的区块以及补贴计划索引。rand_getUnsealed 即为工作清单。

设置

这些步骤沿用测试网所用的脚本(deploy/vps-setup.sh、deploy/update-droplet.sh),用于搭建 Linux 验证者或观察者节点。

1. 在构建主机上构建

构建需要 build-essential clang cmake pkg-config libssl-dev、Rust 1.98.1(由 rust-toolchain.toml 固定),以及与 fullnode 检出目录并列的 circuits 检出目录。首次构建需要 10 到 20 分钟。

git clone https://github.com/randprotocol/fullnode
git clone https://github.com/randprotocol/zkp-circuits circuits
cd fullnode
git checkout v0.8.0                       # c0878c3f, the build chain 21 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"   # d217252 for v0.8.0
git show origin/main:deploy/genesis-chain20.json > deploy/genesis-chain20.json   # committed after the tag
cargo build --release -p randprotocol-node -p randprotocol-client
sha256sum target/release/rand-node         # compare on every node you copy it to

链 21 要求每个节点在 init 之前都升级到 v0.8.0。 它运行约束集 9,在该约束集下,每个验证密钥以及每个证明的编码都已改变,因此该构建拒绝链 18 至 20,更早的构建也无法运行链 21;其创世文件还包含更早构建都不会读取的部分(fees、perps、multisig、hc_auth_multisig)。每个捆绑包证明旁仍附带一个授权证明(hc_auth),而私密多签 guest 固定的验证密钥,即发行版中的 msauth-vk-production.bin(SHA-256 68facb06…cd30),必须与 rand-node 一同放在每个节点上,否则 run 和 verify 会拒绝启动。请运行整个舰队所运行的同一个构建。创世文件位于 fullnode 的 main 分支(提交 246cb5f9),不在 v0.8.0 标签中,因此才有第三行 git。circuits 检出目录必须位于该发行版所引入的提交上,上面第二行 git 会从 fullnode 源码树中读出该提交。如需同时构建 rand-prover,请添加 -p randprotocol-prover。

2. 在节点上安装二进制文件

scp target/release/rand-node target/release/rand deploy/genesis-chain20.json root@<node>:/root/
ssh root@<node> 'install -m 755 /root/rand-node /root/rand /usr/local/bin/'

3. 密钥、创世文件、防火墙

在节点上:

install -d -m 700 /root/keys
test -e /root/keys/node.key.json || rand-node keygen --out /root/keys/node.key.json   # prints the address; keep the seed secret
rand-node init --datadir /root/data-6210cf07 --genesis /root/genesis-chain20.json
timedatectl                                        # "System clock synchronized: yes" (see Clock)
ufw allow 22/tcp && ufw allow 30303/tcp && ufw enable

请在节点上按上述方式生成密钥,并让它远离任何检出目录。fullnode 仓库中不再跟踪任何密钥(审计 v3,OPS-1)。为链 8 至 13 提交的 deploy/node-*.key.json 文件是已公开的种子;链 21 的验证者密钥(为链 14 生成的十八个,以及在链 15 上绑定的八个,此后在每次切换中沿用)均在仓库之外生成,舰队将每台 droplet 的密钥保存在 /root/keys/node-<name>.key.json,位于源码树之外。对于由舰队脚本配置的节点,这个位置很重要:deploy/rebuild-vps.sh 和 deploy/push-to-vps.sh 会以 --delete 方式对 /root/fullnode 执行 rsync,因此保存在该目录树内的密钥会在下一次重建时被删除,服务单元随后也将无法重启。自 v0.6.8 起,keygen 拒绝覆盖已有文件(v0.6.7 会不加询问地覆盖);无论哪种情况,test -e 都能让该行命令可以安全地重复执行。绑定密钥之前,请先将其备份到主机之外。

init 会打印创世哈希,其值必须为 ca76c2766ed6090ac6ba5dad86b724dd5d2b80c0edfaed287cd8b129e663ca9a(链 21)。创世文件是 fullnode 仓库 main 分支 deploy/ 目录中的 genesis-chain21.json。请按舰队的做法,以哈希的前八个字符命名数据目录(data-<name>-ca76c276),这样它就不会与链 20 的(-6210cf07)或之后某条链的目录冲突。创世文件设定了以下限制。证明上限在链 13 至 16 上为 8 MiB,在链 17 至 20 上为 4 MiB(交易自此开始最多携带三个证明),在链 21 上为 6 MiB,用于 tier-18 多签授权证明;区块上限随之从 20 MiB 降至 19 MiB:

链 21 的创世文件还包含 consensus_domain: 1、binding_domain: 1、testnet: true、带投票准入的 staking 部分、带价格上限和 9,961,472 字节目标的 gas 部分、桥的 rotation 与 fees 分组、hardening_v6,以及 guest 固定项 hc_bundle 和 hc_auth;运行节点列出了它们的具体设置。

4. systemd 服务单元

这是 deploy/vps-setup.sh 写入的服务单元,路径同上:

[Unit]
Description=RAND full node
After=network-online.target
[Service]
Environment=RUST_LOG=info,libp2p=warn,libp2p_mdns=off
ExecStart=/usr/local/bin/rand-node run --datadir /root/data-6210cf07 --key /root/keys/node.key.json --validator --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns --prune-history 24h --bootstrap <multiaddr> --bootstrap <multiaddr>
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

观察者节点请去掉 --validator。--prune-history 24h 是测试网验证者(归档节点除外)所运行的参数;若节点需要保留完整历史,请去掉它,并且切勿在主网上传入该参数。链 21 的引导 multiaddr 为节点 C(fra1)、D(ric1)和 E(sgp1),自链 19 起未变。链 21 运行在为链 14 生成的验证者密钥上,而 p2p 身份由验证者密钥派生,因此这些 peer id 与链 14 所用的相同。从创世开始同步的新节点还需要一个保存完整历史的对等节点,因此请加入两个归档节点之一(先是 obs1,然后是 rand-archive-2):

/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
/ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf
/ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh

除非有防火墙保护,否则请将 RPC 保持在 127.0.0.1 上。需要对外提供服务的节点,应在其旁边开放公共监听器(自 v0.6.8 起,--public-rpc <ADDR>),并把代理放在它前面,绝不能放在 --rpc 前面(JSON-RPC)。从 v0.6.7 沿用下来的服务单元不得传入 --prover-accept-spend-key,v0.6.8 会在启动时拒绝它。

systemctl daemon-reload && systemctl enable --now rand-node
journalctl -u rand-node -f
rand status                       # height climbing, peer_count rising

5. 加入验证者集合

新密钥不在任何 epoch 的集合中。在链 21 上,与链 20 一样,它必须先被投票准入:创世文件设置了 staking.admission_by_vote,因此持有超过三分之二投票权重的验证者各自用 rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 21's hash> 签名,并由其中一人用 rand-node admit submit 提交这些投票;随后 rand_getAdmitted 会列出该密钥。然后至少向它绑定 1,000 RAND:用 rand-node register --key /root/keys/node.key.json --payout rand1… --v2 打印注册信息(链 20 和 21 拒绝 v1 注册),再从钱包用 rand bond <address> 1000 --registration <hex> 进行绑定。绑定要等到其激活 epoch 才生效,最早是在提交之后跨过三个 1,000 区块的边界,且每个边界新增的权重至多为活跃权重的 2,500 bps(链 19 将其限制为固定的 10,000 RAND)。质押对此有完整说明。

6. 更新

本节适用于运行同一条链的构建。从更早的链迁移到链 21 不属于更新:它需要新的二进制文件、新的创世文件和全新的数据目录,迁移之后可以删除旧链的数据目录(deploy/retire-chain-dirs.sh;舰队会保留一天以便回滚)。若要在不切换链的情况下滚动部署新构建,请构建一次,比对 rand-node 与 rand 两者的 sha256,停止服务、安装并重启,每次一个节点。有些发行版需要全部停止、全部启动(v0.5.6 的调用层级规则、v0.5.7 的 Status 线路格式变更、v0.6 更严格的证明验证);各发行版的说明会注明采用哪种方式。v0.6.7 以每次一个节点的方式滚动部署到链 18;v0.6.8 随链 20 一同发布,采用全部停止、全部启动,因为其 CON-4 和 CH-1 共识变更绝不能逐节点滚动;v0.7.0 与 v0.7.1 以每次一个节点的方式滚动部署到链 20;v0.8.0 随链 21 一同发布,采用全部停止,因为约束集 9 无法运行链 20。请等每个节点重新加入后再处理下一个,这样法定人数的缺口始终不会超过一个节点。deploy/update-droplet.sh <ip> [build-host] 通过 SSH 完全按此流程执行,而 deploy/roll-all.sh 则依据已签名的发行版滚动整个舰队,并将 msauth 验证密钥安装到二进制文件旁。若某个构建更改了 gossip 线路格式(如 v0.8.0 的紧凑区块),应先滚动观察者和归档节点,再同时滚动所有验证者:混合版本的验证者集合可能会停止出块。自 v0.8.0 起,同一干净构建的重启会跳过启动时的链遍历(启动检查点);--verify-chain replay 可强制执行。

直至 v0.6.8 的各发行版均在一台主机上手工构建,未经签名。自 v0.7.0(2026-10-01)起,每个发行版都由发布工作流依据标签构建,经 CI 把关并使用 --locked,其 SHA256SUMS 由发布密钥签名(SHA256SUMS.sig);deploy/update-droplet.sh 和 deploy/roll-all.sh 在安装前会验证签名,除非设置 ALLOW_UNSIGNED=1,否则拒绝未签名的发行版。v0.8.0 发行版包含 rand-node、rand、rand-prover、msauth-vk-production.bin、SHA256SUMS 和 SHA256SUMS.sig;校验和列在运行节点中。

第 15、16、17 和 18 号链在 2.7 天内（2026-09-26 至 2026-09-29）相继上线，每一次都是整个集群的全面停机。第 19 号链于 2026-10-01 03:43 UTC 跟进，是在同一构建上对第 18 号链的重新创世；第 20 号链于同日 06:17 UTC 上线，由第 19 号链在 v0.6.8 硬分叉处的快照切出；所有节点均停在第 19 号链高度 7,700。第 21 号链于 2026-10-12 10:31 UTC 在 v0.8.0 上跟进，由第 20 号链在高度 814,702 处的桥状态以及对运营方钱包的余额扫描切出，承载 26 个验证者、桥、100.001999 zUSD（与四个备份资产上锁定的托管资产相等）、运营方余额 3,938.879078887 RAND，以及作为新增发行的 100,000 RAND 国库，并舍弃第 20 号链资金池中约 36,025 RAND（由运营方并不持有的钱包持有）、第 20 号链上注册的其余十一种代币以及每个程序的状态。自第 20 号链起适用一份书面的切换政策（2026-09-30）；第 20 号链和第 21 号链的切换记录均免除了第二运营方的重建，因为所有密钥均由同一运营方持有。一次切换需要：滚动升级无法满足的理由、一份公开的承载与舍弃内容清单、事先完成的客户端重建检查清单、一个将创世重建为相同哈希的第二运营方、一份回滚方案，以及一个从未使用过的链 ID。