Menjalankan validator dan aggregator

Gunakan halaman ini untuk menentukan ukuran mesin sebelum Anda menjalankannya. Validator itu murah. Pembuktian tidak: memori sebuah bukti (proof) tumbuh curam seiring tier-nya, dan itulah satu-satunya angka yang menentukan apakah sebuah mesin sanggup mengerjakannya. Setiap angka di sini adalah hasil pengukuran dari testnet atau catatan fullnode. Angka yang belum final ditandai.

Peran masing-masing

Validator dan pengamat tidak pernah membuktikan. Transfer shielded atau sebuah panggilan dibuktikan oleh wallet yang mengirimkannya, atau, khusus untuk proof bundle, oleh prover yang dipasangkan dengan wallet tersebut (Menjalankan node). Validator milik fleet saat ini tidak membuktikan apa pun.

Agregasi blok sudah dibangun tetapi belum aktif. Agregasi memerlukan bagian aggregation dalam genesis. Chain 20 tidak memilikinya: agregasi nonaktif, seperti pada chain 9 sampai 19, dan build menolak berjalan pada genesis yang memuat bagian tersebut.

Ukuran sekilas

Prover saat ini berjalan dengan satu thread. Droplet 16 vCPU berjalan pada 99% dari satu core. Lebih banyak core tidak membuat satu proof lebih cepat; RAM yang lebih besarlah yang menentukan apakah proof selesai.

Validator dan pengamat

Memori dan CPU

Delapan belas validator awal berjalan pada droplet 2 GB. Memverifikasi sebuah proof itu murah:

Memori yang dibutuhkan validator untuk memverifikasi proof panggilan tier 18 atau tier 20 kini sebagian telah diukur, pada laptop Apple-silicon 48 GB, terpisah dari droplet DigitalOcean yang menghasilkan setiap proof: memverifikasi proof transfer tier 18 memakan 50,2 s dengan puncak RSS 3,66 GB (hasil terjemahan) atau 49,6 s (interpreter, RSS tidak dicatat terpisah); memverifikasi proof approve tier 16 memakan 12,2 s (RSS tidak dicatat terpisah). Tier 20 belum diukur — belum ada proof tier 20 yang dapat diverifikasi. Sejak v0.5.6 validator tidak pernah membangun key sebesar itu: header proof panggilan diperiksa sebelum verifier key apa pun dibangun, dan panggilan di atas tier 14 (atau dengan tabel keccak di atas 2^12, atau tabel sha256 di atas 2^13) ditolak, pada tahap penerimaan maupun sebagai aturan validitas blok. Header panggilan terburuk yang masih dapat diterima terukur 4,7 s dan 312 MB untuk diverifikasi.

Droplet 1 vCPU, 2 GB tidak dapat membangun binary. Lakukan build pada mesin yang lebih besar lalu salin hasilnya (lihat penyiapan).

Disk

Pada chain 20, seperti pada chain 19, 24 dari 26 validator menjalankan --prune-history 24h dan menyimpan sekitar satu hari blok; ledger itu sendiri (note, nullifier, anchor, register) tidak pernah dipangkas. Arsip, obs1 dan rand-archive-2 (keduanya juga validator), berjalan tanpa flag tersebut. Node mainnet tidak pernah memakainya. Node menolak mulai jika ruang kosong pada filesystem direktori datanya kurang dari --min-free-disk-mb (secara default 1.024 MB), dan rand_getHealth menjawab disk_low di bawah empat kali nilai itu; sebuah roll yang menunggu ok akan berhenti pada node yang mulai penuh. Lihat Pemangkasan riwayat untuk apa yang masih dijawab oleh node yang dipangkas.

Hapus direktori data milik chain yang sudah dipensiunkan setelah cut-over. Direktori data diberi kunci berdasarkan hash genesis (data-<name>-<hash8>: -6210cf07 untuk chain 20, -a3defc93 untuk chain 19; keenam host guardian memakai /var/lib/randnode/data-20), sehingga direktori lama tetap ada sampai Anda menghapusnya. Pada cut chain-20, satu validator regional (syd1) naik dengan status disk_low dengan sisa ruang 3.9 GB dan menahan proses mulai di 25 dari 26, karena direktori chain 14 sampai 17 masih ada di dalamnya; menghapusnya membebaskan 22 GB. Simpan direktori chain sebelumnya selama satu hari sebagai target rollback, lalu hapus. Pada blok penuh, setiap bundle proof mentah berukuran sekitar 1.42 MB sejak chain 14 (sekitar 1.3 MB hingga chain 13). Sejak chain 17, setiap bundle juga membawa authorisation proof, sehingga satu transfer menghasilkan proof sekitar 2.85 MB: sekitar 1.49 MB untuk bundle proof dan 1.36 MB untuk authorisation proof (profil produksi, diukur 2026-09-29). Agregasi, setelah aktif, memangkas proof sebuah bundle yang telah tersegel menjadi sekitar 3 KB, kecuali node dijalankan dengan --keep-raw-proofs. Pemangkasan ini tidak mencakup authorisation proof, yang tetap berukuran penuh.

Jaringan

Buka TCP 30303 untuk lalu lintas masuk pada node publik. Node di belakang NAT menghubungi keluar dengan --bootstrap. Pada blok penuh 4 MiB, satu tautan validator membawa sekitar 2 MB/s.

Jam

Validator membutuhkan NTP. Chain 14 adalah chain pertama yang menjadikan waktu jam dinding bagian dari konsensus (bridge hardening B2):

Validator yang jamnya lambat 20 s berhenti memberikan suara tanpa pemberitahuan: ia melihat setiap blok yang jujur sebagai mendahului jamnya dan menahan suaranya, dan tidak ada yang gagal secara eksplisit. Pada chain 20, delapan belas dari dua puluh enam validator harus memberikan suara agar apa pun dapat di-commit. Periksa setiap validator, dan pasang chrony di tempat jam belum tersinkronisasi:

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

Batas 15 s yang sama berlaku untuk genesis. Atur timestamp_ms mendekati waktu peluncuran dan jangan pernah mendahuluinya: genesis yang lebih dari 15 s di masa depan tidak meng-commit block 1 sampai waktu dinding mencapainya, dan genesis yang jauh di masa lalu membuat waktu blok tertinggal dari jam dinding, yang dikejar tidak lebih dari 60 s per blok (docs/deploy.md). Observer tidak memberikan suara, sehingga aturan suara tidak mengikatnya.

Ukuran DigitalOcean yang dipakai testnet

Tabel ini mencakup kedelapan belas validator awal. Sejak 2026-09-27 validator A juga berjalan di droplet (sgp1), bukan di laptop. Delapan validator lagi di-bond pada chain 15 (2026-09-27): dua archive, obs1 dan rand-archive-2 (fra1), serta keenam host guardian. Ukuran droplet mereka tidak dicatat di sini, begitu pula apakah mkc1 dan mem1 sudah di-resize. Kedua puluh enam validator adalah validator genesis pada chain 20, seperti pada chain 19, masing-masing sebesar 1,000 RAND, dan per 2026-09-30 ke-26 kuncinya dipegang oleh satu operator.

Memori pembuktian

Wallet membuktikan setiap transaksi yang dikirimnya, sehingga pemanggil sebuah program memerlukan memori untuk tier program tersebut. Berikut batas-batas yang telah diukur. Eksekusi tier-18 telah selesai, dibuktikan, dan diverifikasi di DigitalOcean; tier-20 belum. Sejak v0.5.6 chain menolak call proof di atas tier 14 (MAX_CALL_TIER), sehingga baris tier-16, 18, dan 20 di bawah adalah hasil pengukuran, bukan call yang diterima chain 20; setiap call yang di-commit pada chain 14 berada di tier 10.

Call ERC-20 berada di tier 16 dan 18, dan SPL Token di tier 20 (Ethereum, Solana). Belum ada proof pada tier 18 atau 20 yang dibuat di mesin 48 GB.

Agregator

Agregator memantau chain, mengambil bundle proof dari sebuah jendela blok yang telah final, membuktikan satu agregat rekursif atas proof tersebut, lalu mengirimkannya. Blok yang memuatnya disebut blok penyegel (sealing). Agregator dibayar bagian pembuktian dari bundle yang tercakup ditambah subsidi blok berupa RAND baru, ke alamat pembayaran yang didaftarkannya. Agregasi bersifat permissionless: setiap operator yang memiliki bond dapat mendaftar.

Agregasi hanya ada pada chain yang genesis-nya memiliki bagian aggregation. Chain 20 tidak memilikinya, dan build-nya menolak start pada genesis yang memilikinya.

Perangkat keras

Angka N = 2 dan N = 3 diukur pada droplet DigitalOcean 256 GB pada 2026-09-28/29, di bawah constraint set 7, dan exit proof produksi membutuhkan lebih dari 256 GB yang dimiliki mesin itu. Belum ada yang diukur ulang di bawah constraint set 8, yang dijalankan chain 18 hingga 20, sehingga perlakukan baris N = 1 sebagai batas bawah. Backend CUDA pertama kali berjalan pada perangkat keras nyata pada 2026-09-28, pada NVIDIA H100: kernel-nya dibangun menjadi PTX untuk sm_80 dan sm_90 dan cocok dengan referensi CPU. Pengukuran produksi pada node GPU armada masih harus dilakukan. Setiap node juga membayar sekali saat startup untuk key-build program agregat: 13.0 hingga 13.4 s pada profil pengujian (2¹⁹), dan diperkirakan 30 hingga 70 s pada produksi (2²¹).

Perintah

# 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 menampilkan bagian aggregation pada chain semacam itu: agregator terdaftar, blok yang belum disegel, dan indeks jadwal subsidi. rand_getUnsealed adalah daftar pekerjaannya.

Penyiapan

Langkah-langkah ini mengikuti skrip yang digunakan testnet (deploy/vps-setup.sh, deploy/update-droplet.sh). Hasilnya adalah validator atau node pengamat berbasis Linux.

1. Build di host build

Build membutuhkan build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1 (dipatok oleh rust-toolchain.toml), dan checkout circuits di samping checkout fullnode. Build pertama memakan waktu 10 hingga 20 menit.

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 membutuhkan v0.6.8 pada setiap node sebelum init. Genesisnya membawa field yang tidak dibaca oleh build sebelumnya (testnet, binding_domain, proof_window_blocks, program_state, grup rotation dan fees pada bridge, batas atas gas, admisi staking melalui pemungutan suara), dan v0.6.8 membawa perubahan konsensus CON-4 dan CH-1 dari audit v6. Proof tetap dibuat di bawah constraint set 8, seperti pada chain 18 dan 19, dengan proof otorisasi di samping setiap proof bundle (hc_auth). Build v0.6.8 menolak genesis chain 14 hingga 17 pada run dan verify. Jalankan build yang sama dengan yang dijalankan fleet. File genesis berada di main milik fullnode (commit 74cfaca0), bukan di tag v0.6.8, sehingga ada baris git ketiga. Checkout circuits harus berada pada commit tempat rilis di-vendor, yang dibaca baris git kedua di atas dari pohon fullnode. Tambahkan -p randprotocol-prover untuk membangun rand-prover juga.

2. Memasang binary di node

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. Kunci, genesis, firewall

Di node:

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

Buat kunci di node, seperti di atas, dan simpan di luar checkout mana pun. Tidak ada lagi kunci yang dilacak di repositori fullnode (audit v3, OPS-1). File deploy/node-*.key.json yang di-commit untuk chain 8 hingga 13 adalah seed yang dipublikasikan; kunci validator chain 20 (delapan belas kunci yang dibuat untuk chain 14 dan delapan yang di-bond pada chain 15) dibuat di luar repositori, dan fleet menyimpan kunci setiap droplet di /root/keys/node-<name>.key.json, di luar pohon sumber. Lokasi ini penting pada node yang disediakan oleh skrip fleet: deploy/rebuild-vps.sh dan deploy/push-to-vps.sh melakukan rsync /root/fullnode dengan --delete, sehingga kunci yang disimpan di dalam pohon itu akan terhapus oleh rebuild berikutnya dan unit gagal dimulai ulang. Sejak v0.6.8 keygen menolak menimpa file yang sudah ada (v0.6.7 menimpanya tanpa bertanya); test -e menjaga agar baris ini aman dijalankan ulang dalam kedua kasus. Cadangkan kunci di luar host sebelum melakukan bond.

init mencetak hash genesis. Hasilnya harus berbunyi 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (chain 20). File genesisnya adalah genesis-chain20.json di deploy/ pada repositori fullnode di main. Beri nama direktori data sesuai delapan karakter pertama hash, seperti yang dilakukan fleet (data-<name>-6210cf07), sehingga tidak pernah bentrok dengan direktori chain 19 (-a3defc93) atau chain berikutnya. Genesis menetapkan batas-batas berikut. Batas proof adalah 8 MiB pada chain 13 hingga 16 dan sejak chain 17 menjadi 4 MiB, ketika sebuah transaksi mulai membawa hingga tiga proof:

Genesis chain 20 juga membawa consensus_domain: 1, binding_domain: 1, testnet: true, bagian staking dengan admisi melalui pemungutan suara, bagian gas dengan batas atas harga, grup rotation dan fees milik bridge, hardening_v6, dan dua pin guest hc_bundle dan hc_auth; Menjalankan node mencantumkan apa yang ditetapkan oleh semuanya.

4. Unit systemd

Ini adalah unit yang ditulis oleh deploy/vps-setup.sh, dengan path di atas:

[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

Hapus --validator untuk node pengamat. --prune-history 24h adalah yang dijalankan validator testnet, kecuali arsip; hapus untuk node yang menyimpan riwayat penuh, dan jangan pernah menggunakannya di mainnet. Multiaddr bootstrap untuk chain 20 adalah node C (fra1), D (ric1), dan E (sgp1), tidak berubah dari chain 19. Chain 20 berjalan pada kunci validator yang dibuat untuk chain 14, dan identitas p2p diturunkan dari kunci validator, sehingga id peer ini adalah yang digunakan chain 14. Node baru yang melakukan sinkronisasi dari genesis juga membutuhkan peer riwayat penuh, jadi tambahkan salah satu dari dua arsip (obs1, lalu 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

Biarkan RPC pada 127.0.0.1 kecuali firewall melindunginya. Node yang harus melayani publik membuka listener publik v0.6.8 di sampingnya (--public-rpc <ADDR>) dan menempatkan proxy di depannya, tidak pernah di depan --rpc (JSON-RPC). Unit yang dibawa dari v0.6.7 tidak boleh memberikan --prover-accept-spend-key, yang ditolak v0.6.8 saat startup.

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

5. Bergabung dengan set validator

Kunci baru tidak termasuk dalam set epoch mana pun. Pada chain 20, kunci itu harus terlebih dahulu dipilih melalui pemungutan suara: genesisnya menetapkan staking.admission_by_vote, sehingga validator yang memegang lebih dari dua pertiga bobot suara masing-masing menandatanganinya dengan rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>, dan satu validator mengirimkan suara dengan rand-node admit submit; rand_getAdmitted kemudian mendaftarkannya. Setelah itu lakukan bond sedikitnya 1.000 RAND ke kunci tersebut: cetak registrasi dengan rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (chain 20 menolak registrasi v1), lalu lakukan bond dari wallet dengan rand bond <address> 1000 --registration <hex>. Bond menunggu epoch aktivasinya, paling cepat tiga batas 1.000 blok setelah di-commit, dan paling banyak 2.500 bps dari bobot aktif menjadi bobot baru per batas (chain 19 membatasinya pada 10.000 RAND tetap). Staking menjelaskannya langkah demi langkah.

6. Pembaruan

Bagian ini berlaku untuk build yang menjalankan chain yang sama. Berpindah dari chain sebelumnya ke chain 20 bukanlah pembaruan: dibutuhkan binary baru, genesis baru, dan direktori data baru, dan direktori data chain lama dapat dihapus setelahnya (deploy/retire-chain-dirs.sh; fleet menyimpannya selama sehari untuk rollback). Untuk meluncurkan build baru tanpa pemotongan chain, lakukan build sekali, bandingkan sha256 dari rand-node dan rand, hentikan layanan, pasang, dan mulai ulang, satu node pada satu waktu. Beberapa rilis diluncurkan dengan cara hentikan semua, mulai semua (aturan tier panggilan v0.5.6, perubahan wire Status v0.5.7, verifikasi proof yang lebih ketat pada v0.6); catatan setiap rilis menyebutkan mana yang berlaku. v0.6.7 diluncurkan ke chain 18 satu node pada satu waktu; v0.6.8 datang bersama chain 20, dengan hentikan semua, mulai semua, karena perubahan konsensus CON-4 dan CH-1 tidak boleh diluncurkan node demi node. Tunggu setiap node bergabung kembali sebelum node berikutnya, sehingga kuorum tidak pernah kurang lebih dari satu. deploy/update-droplet.sh <ip> [build-host] melakukan persis hal ini melalui SSH.

Rilis hingga v0.6.8 dibangun dengan tangan di satu host dan tidak ditandatangani. Rilis GitHub v0.6.8 membawa rand-node, rand, rand-prover, dan SHA256SUMS, yang dibangun di node E; checksum itu menangkap unduhan yang rusak dan tidak menjamin host build. v0.6.8 menyertakan workflow rilis yang membangun binary dari tag, dan deploy/update-droplet.sh menolak pemasangan tanpa SHA256SUMS yang ditandatangani kecuali ALLOW_UNSIGNED=1 ditetapkan. deploy/release-signers belum mencantumkan kunci apa pun, sehingga jalur bertanda tangan belum pernah digunakan.

Chain 15, 16, 17, dan 18 mengudara dalam 2,7 hari (2026-09-26 hingga 2026-09-29), masing-masing berupa penghentian seluruh fleet. Chain 19 menyusul pada 2026-10-01 pukul 03:43 UTC, sebuah re-genesis chain 18 pada build yang sama, dan chain 20 pada hari yang sama pukul 06:17 UTC, dipotong dari snapshot chain 19 pada hard fork v0.6.8; setiap node berhenti pada tinggi chain-19 7.700. Kebijakan pemotongan tertulis (2026-09-30) berlaku mulai chain 20; catatan pemotongan chain 20 membebaskan rebuild oleh operator kedua, karena satu operator memegang semua kunci. Sebuah pemotongan membutuhkan alasan yang tidak dapat dipenuhi oleh pembaruan bergulir, daftar terpublikasi tentang apa yang dibawa dan apa yang dibuang, daftar periksa rebuild klien yang diselesaikan sebelumnya, operator kedua yang membangun ulang genesis hingga hash yang sama, rencana rollback, dan id chain yang belum pernah digunakan.