validator と aggregator の運用

このページは、マシンを用意する前にサイズを見積もるためのものです。バリデータは軽量です。証明はそうではありません。証明のメモリはティアが上がるにつれて急激に増え、そのマシンで処理を完了できるかどうかは、この数値で決まります。ここに挙げた数値はすべて、testnet またはフルノードの記録による実測値です。確定していない数値にはその旨を記しています。

各ロールの役割

バリデータとオブザーバは証明を行いません。シールドされた送金や呼び出しは、それを送信するウォレットが証明します。バンドル証明のみであれば、そのウォレットがペアリングされたプルーバが証明します(ノードの運用)。現時点では、フリートのバリデータは何も証明していません。

ブロックアグリゲーションは実装済みですが、有効になっていません。ジェネシスに aggregation セクションが必要です。chain 20 にはこのセクションがありません。chain 9 から 19 と同様、アグリゲーションは無効であり、このセクションを含むジェネシスではビルドは起動を拒否します。

サイズの目安

プルーバは現時点ではシングルスレッドです。 16 vCPU の droplet は 1 コアの 99% で動作しました。コア数を増やしても 1 件の証明は速くなりません。証明が完了するかどうかを決めるのは RAM です。

バリデータとオブザーバ

メモリと CPU

当初の 18 台のバリデータは 2 GB の droplet で稼働しています。証明の検証は軽量です。

ティア 18 またはティア 20 の呼び出し証明を検証するためにバリデータが必要とするメモリは、現在一部が実測されています。測定は 48 GB の Apple Silicon ノート PC で、各証明を生成した DigitalOcean の droplet とは独立に行いました。ティア 18 の transfer 証明の検証には、ピーク RSS 3.66 GB(変換済み)で 50.2 秒、またはインタプリタで 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 20 では chain 19 と同様に、26 台のバリデータのうち 24 台が --prune-history 24h で稼働し、約 1 日分のブロックを保持します。台帳そのもの(ノート、ヌリファイア、アンカー、レジスタ)は決してプルーニングされません。アーカイブである obs1 と rand-archive-2(どちらもバリデータを兼ねます)は、このフラグなしで稼働しています。mainnet のノードがこれを渡すことはありません。ノードは、データディレクトリのファイルシステムの空きが --min-free-disk-mb(デフォルトは 1,024 MB)未満の場合、起動を拒否します。また rand_getHealth は、その 4 倍未満になると disk_low を返します。ok を待つロールは、容量が逼迫しているノードで停止します。プルーニング済みのノードが引き続き応答できる内容については、履歴のプルーニングを参照してください。

退役したチェーンのデータディレクトリは、カットオーバーの後に削除してください。データディレクトリはジェネシスハッシュをキーとしており(data-<name>-<hash8>。チェーン 20 は -6210cf07、チェーン 19 は -a3defc93、6 台のガーディアンホストは /var/lib/randnode/data-20 を使用)、古いものは削除するまで残ります。チェーン 20 のカット時には、リージョンのバリデーター 1 台(syd1)が空き 3.9 GB で disk_low のまま起動し、26 台中 25 台のところで開始が止まりました。チェーン 14 から 17 のディレクトリが残っていたためで、これらを削除して 22 GB が空きました。直前のチェーンのディレクトリは、ロールバック先として 1 日残してから削除してください。ブロックが満杯のとき、生のバンドル証明 1 件はチェーン 14 以降で約 1.42 MB です(チェーン 13 までは約 1.3 MB)。チェーン 17 以降は、すべてのバンドルが認可証明も運ぶため、トランスファー 1 件の証明は約 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 が必要です。チェーン 14 は、実時間がコンセンサスの一部となる最初のチェーンです(ブリッジ強化 B2)。

クロックが 20 s 遅れているバリデーターは、何も表示されないまま投票をやめます。正直なブロックがすべて自分のクロックより先にあるように見えるため投票を保留し、どこにも失敗は現れません。チェーン 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 をコミットしません。また、はるか過去のジェネシスではブロック時刻が実時間より遅れ、1 ブロックあたり最大 60 s の速さでしか追いつきません(docs/deploy.md)。オブザーバーは投票しないため、投票ルールの制約を受けません。

テストネットが動作する DigitalOcean のサイズ

この表は、当初の 18 台のバリデーターを対象としています。2026-09-27 以降、バリデーター A もノート PC ではなくドロップレット(sgp1)で動いています。チェーン 15(2026-09-27)では、さらに 8 台のバリデーターがボンドされました。2 台のアーカイブ(obs1 と rand-archive-2(fra1))と、6 台のガーディアンホストです。これらのドロップレットのサイズはここには記録されておらず、mkc1 と mem1 がリサイズされたかどうかも記録されていません。チェーン 20 では、チェーン 19 と同様に 26 台すべてがジェネシスバリデーターで、ボンドは各 1,000 RAND です。2026-09-30 時点で、26 個すべての鍵を 1 人のオペレーターが保持しています。

証明に必要なメモリ

ウォレットは送信するすべてのトランザクションを証明するため、プログラムの呼び出し側には、そのプログラムのティアに見合うメモリが必要です。以下は計測された下限です。ティア 18 の実行は DigitalOcean 上で完了し、証明と検証まで済んでいます。ティア 20 は未完了です。v0.5.6 以降、チェーンはティア 14 を超えるコール証明を拒否します(MAX_CALL_TIER)。したがって、以下のティア 16、18、20 の行は計測値であり、チェーン 20 が受け付けるコールではありません。チェーン 14 でコミットされたコールはすべてティア 10 でした。

ERC-20 のコールはティア 16 と 18、SPL Token はティア 20 に位置します(Ethereum、Solana)。ティア 18 や 20 の証明は、48 GB のマシンではまだ生成されていません。

アグリゲーター

アグリゲーターはチェーンを監視し、ファイナライズされたブロックのウィンドウからバンドル証明を集めて、それらに対する 1 つの再帰的なアグリゲートを証明し、提出します。それを含むブロックが封印ブロックです。アグリゲーターには、対象となったバンドルの証明シェアに加えて、新規 RAND によるブロック補助金が、登録済みのペイアウトアドレスに支払われます。アグリゲーションはパーミッションレスで、ボンドを持つオペレーターなら誰でも登録できます。

アグリゲーションは、ジェネシスに aggregation セクションがあるチェーンにのみ存在します。チェーン 20 にはそれがなく、そのビルドは、このセクションを持つジェネシスでは起動を拒否します。

ハードウェア

N = 2 と N = 3 の値は、2026-09-28/29 に 256 GB の DigitalOcean ドロップレットで、制約セット 7 のもとで計測したものです。本番のイグジット証明は、そのマシンの 256 GB を超えて必要でした。チェーン 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 セクションが表示されます。登録済みの aggregator、未封印のブロック、補助金スケジュールのインデックスです。rand_getUnsealed が作業リストです。

セットアップ

以下の手順は、testnet が使用するスクリプト(deploy/vps-setup.sh、deploy/update-droplet.sh)に沿っています。Linux の validator または observer を構築できます。

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.6.8                       # c9c9bd3c, the build chain 20 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"   # aeacf31 for v0.6.8
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

chain 20 では、init の前にすべてのノードを v0.6.8 にする必要があります。 そのジェネシスには、それ以前のビルドが読み取らないフィールド(testnet、binding_domain、proof_window_blocks、program_state、ブリッジの rotation グループと fees グループ、ガス上限、投票によるステーキング参加承認)が含まれており、v0.6.8 には audit v6 の CON-4 と CH-1 のコンセンサス変更が入っています。証明は、chain 18 および chain 19 と同様に制約セット 8 のもとで生成され、各バンドル証明に認可証明(hc_auth)が添えられます。v0.6.8 のビルドは、chain 14 から 17 のジェネシスを run と verify で拒否します。フリートが実行しているビルドと同じものを実行してください。ジェネシスファイルは fullnode の main(コミット 74cfaca0)にあり、v0.6.8 タグには含まれていません。そのため 3 行目の git があります。circuits のチェックアウトは、リリースがベンダリングされたコミットでなければならず、そのコミットは上の 2 行目の 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 リポジトリでは、キーはもう追跡されていません(audit v3、OPS-1)。chain 8 から 13 向けにコミットされた deploy/node-*.key.json ファイルは公開されたシードです。chain 20 の validator キー(chain 14 用に生成された 18 個と、chain 15 でボンドされた 8 個)はリポジトリ外で生成されており、フリートは各 droplet のキーをソースツリーの外にある /root/keys/node-<name>.key.json に保管しています。フリートのスクリプトでプロビジョニングされたノードでは、この場所が重要です。deploy/rebuild-vps.sh と deploy/push-to-vps.sh は /root/fullnode を --delete 付きで rsync するため、そのツリー内に置いたキーは次回のリビルドで削除され、ユニットは再起動できなくなります。v0.6.8 以降、keygen は既存のファイルの上書きを拒否します(v0.6.7 は確認なしに上書きしていました)。test -e により、どちらのバージョンでも再実行して安全な行になります。ボンドする前に、キーをホストの外にバックアップしてください。

init はジェネシスハッシュを出力します。その値は 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135(chain 20)でなければなりません。ジェネシスファイルは、fullnode リポジトリの main にある deploy/ 内の genesis-chain20.json です。データディレクトリには、フリートと同様にハッシュの先頭 8 文字にちなんだ名前(data-<name>-6210cf07)を付けてください。そうすれば、chain 19(-a3defc93)や後続のチェーンのものと衝突しません。ジェネシスは次の上限を設定します。証明の上限は chain 13 から 16 では 8 MiB でしたが、トランザクションが最大 3 つの証明を運ぶようになった chain 17 以降は 4 MiB です。

chain 20 のジェネシスには、consensus_domain: 1、binding_domain: 1、testnet: true、投票による参加承認を伴う staking セクション、価格上限を持つ gas セクション、ブリッジの rotation グループと fees グループ、hardening_v6、2 つのゲストピン 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

observer では --validator を外してください。--prune-history 24h は testnet の validator が実行しているオプションですが、アーカイブは除きます。完全な履歴を保持するノードでは外してください。mainnet では決して指定しないでください。chain 20 のブートストラップ multiaddr は、ノード C(fra1)、D(ric1)、E(sgp1)で、chain 19 から変更ありません。chain 20 は chain 14 用に生成された validator キーで動作し、p2p ID は validator キーから導出されるため、これらの peer id は chain 14 で使われたものと同じです。ジェネシスから同期する新しいノードには、完全な履歴を持つピアも必要です。2 つのアーカイブ(obs1、次に rand-archive-2)のうち 1 つを追加してください。

/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. validator セットに参加する

新しいキーは、どのエポックのセットにも含まれていません。chain 20 では、まず投票で承認される必要があります。そのジェネシスは staking.admission_by_vote を設定しているため、投票権重の 3 分の 2 を超える validator がそれぞれ rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash> で署名し、1 つが rand-node admit submit で投票を送信します。その後、rand_getAdmitted がそのキーを一覧表示します。次に、少なくとも 1,000 RAND をボンドします。rand-node register --key /root/keys/node.key.json --payout rand1… --v2 で登録情報を出力し(chain 20 は v1 の登録を拒否します)、ウォレットから rand bond <address> 1000 --registration <hex> でボンドします。ボンドはアクティベーションのエポックまで待機します。コミットされてから最短で 1,000 ブロック境界 3 つ後で、境界ごとに新たな権重となるのはアクティブ権重の最大 2,500 bps です(chain 19 では固定の 10,000 RAND が上限でした)。ステーキングで順を追って説明しています。

6. アップデート

これは、同じチェーンを実行するビルドに適用されます。以前のチェーンから chain 20 への移行はアップデートではありません。新しいバイナリ、新しいジェネシス、新しいデータディレクトリが必要で、古いチェーンのデータディレクトリは後で削除できます(deploy/retire-chain-dirs.sh。フリートはロールバックに備えて 1 日保持します)。チェーンの切り替えを伴わずに新しいビルドをロールアウトするには、一度ビルドし、rand-node と rand の両方の sha256 を比較し、サービスを停止し、インストールして再起動します。これを 1 ノードずつ行います。リリースによっては、1 ノードずつではなく、全停止・全起動でロールアウトされます(v0.5.6 のコールティア規則、v0.5.7 の Status ワイヤ変更、v0.6 のより厳格な証明検証)。どちらの方法かは、各リリースのノートに記載されています。v0.6.7 は chain 18 に 1 ノードずつロールアウトされました。v0.6.8 は chain 20 とともに、全停止・全起動で行われました。その CON-4 と CH-1 のコンセンサス変更は、ノードごとに順次ロールアウトしてはならないためです。次のノードに進む前に、各ノードが再参加するのを待ってください。そうすれば、定足数が 1 ノードを超えて不足することはありません。deploy/update-droplet.sh <ip> [build-host] は、これを SSH 経由でそのまま実行します。

v0.6.8 までのリリースは、1 台のホストで手作業でビルドされており、署名されていません。v0.6.8 の GitHub リリースには、ノード E でビルドされた rand-node、rand、rand-prover、SHA256SUMS が含まれます。このチェックサムは破損したダウンロードを検出しますが、ビルドホストを保証するものではありません。v0.6.8 にはタグからバイナリをビルドするリリースワークフローが付属しており、deploy/update-droplet.sh は ALLOW_UNSIGNED=1 が設定されていない限り、署名済みの SHA256SUMS がないインストールを拒否します。deploy/release-signers にはまだキーが一覧されていないため、署名付きの経路は使われたことがありません。

chain 15、16、17、18 は 2.7 日以内(2026-09-26 から 2026-09-29)に稼働を開始し、いずれもフリートの全停止でした。chain 19 は 2026-10-01 の 03:43 UTC に続き、同じビルドでの chain 18 の再ジェネシスでした。chain 20 は同日の 06:17 UTC に、v0.6.8 のハードフォークで chain 19 のスナップショットから切り出されました。すべてのノードは chain 19 の高さ 7,700 で停止しました。文書化されたカット方針(2026-09-30)は chain 20 以降に適用されます。chain 20 のカット記録では、1 人のオペレーターがすべてのキーを保持しているため、2 人目のオペレーターによるリビルドは免除されました。カットには、ローリングアップデートでは満たせない理由、カットが引き継ぐものと切り捨てるものの公開リスト、事前に完了したクライアントのリビルドチェックリスト、ジェネシスを同じハッシュに再構築する 2 人目のオペレーター、ロールバック計画、そして一度も使われたことのないチェーン ID が必要です。