Betrieb eines Validators und eines Aggregators

Nutzen Sie diese Seite, um eine Maschine zu dimensionieren, bevor Sie eine betreiben. Ein Validator ist günstig. Das Beweisen ist es nicht: Der Speicherbedarf eines Beweises wächst steil mit seiner Stufe, und diese eine Zahl entscheidet, ob eine Maschine die Aufgabe leisten kann. Jede Angabe hier ist eine Messung aus dem testnet oder aus den Aufzeichnungen des Fullnode. Angaben, die nicht final sind, sind gekennzeichnet.

Was jede Rolle tut

Validatoren und Observer beweisen nie. Ein abgeschirmter Transfer oder ein Aufruf wird von dem Wallet bewiesen, das ihn sendet, oder, nur für den Bundle-Beweis, von einem Prover, mit dem dieses Wallet gekoppelt ist (Running a node). Die Validatoren der Flotte beweisen heute nichts.

Die Block-Aggregation ist gebaut, aber nicht aktiv. Sie benötigt einen Abschnitt aggregation im Genesis. Chain 20 hat keinen: Die Aggregation ist aus, wie auf den Chains 9 bis 19, und der Build weigert sich, mit einem Genesis zu starten, der den Abschnitt enthält.

Dimensionierung auf einen Blick

Der Prover ist heute single-threaded. Ein Droplet mit 16 vCPUs lief mit 99 % eines Kerns. Mehr Kerne machen einen einzelnen Beweis nicht schneller; mehr RAM entscheidet, ob er fertig wird.

Validatoren und Observer

Speicher und CPU

Die ursprünglichen achtzehn Validatoren laufen auf Droplets mit 2 GB. Das Verifizieren eines Beweises ist günstig:

Der Speicher, den ein Validator zum Verifizieren eines Aufruf-Beweises der Stufe 18 oder 20 benötigt, ist nun teilweise gemessen, auf einem Apple-Silicon-Laptop mit 48 GB, unabhängig vom DigitalOcean-Droplet, das den jeweiligen Beweis erzeugt hat: Das Verifizieren des transfer-Beweises der Stufe 18 dauerte 50,2 s bei 3,66 GB Spitzen-RSS (übersetzt) bzw. 49,6 s (Interpreter, RSS nicht gesondert erfasst); das Verifizieren des approve-Beweises der Stufe 16 dauerte 12,2 s (RSS nicht gesondert erfasst). Stufe 20 ist nicht gemessen – es existiert noch kein Beweis der Stufe 20, den man verifizieren könnte. Seit v0.5.6 baut ein Validator nie einen so großen Key: Der Header eines Aufruf-Beweises wird geprüft, bevor ein Verifier Key gebaut wird, und ein Aufruf oberhalb der Stufe 14 (oder mit einer keccak-Tabelle über 2^12 oder einer sha256-Tabelle über 2^13) wird abgelehnt, bei der Zulassung und als Regel für die Blockgültigkeit. Der schlechteste zulässige Aufruf-Header benötigte gemessen 4,7 s und 312 MB zum Verifizieren.

Ein Droplet mit 1 vCPU und 2 GB kann die Binärdateien nicht bauen. Bauen Sie auf einer größeren Maschine und kopieren Sie sie hinüber (siehe Einrichtung).

Festplatte

Auf Chain 20 laufen, wie auf Chain 19, 24 der 26 Validatoren mit --prune-history 24h und halten etwa einen Tag an Blöcken vor; das Ledger selbst (Notes, Nullifier, Anker, das Register) wird nie beschnitten. Die Archive, obs1 und rand-archive-2 (beide zugleich Validatoren), laufen ohne das Flag. Ein mainnet-Node übergibt es nie. Der Node verweigert den Start, wenn im Dateisystem seines Datenverzeichnisses weniger als --min-free-disk-mb (standardmäßig 1.024 MB) frei sind, und rand_getHealth antwortet mit disk_low unterhalb des Vierfachen davon; ein Roll, der auf ok wartet, bleibt an einem Node stehen, der sich füllt. Siehe History pruning, was ein beschnittener Node noch beantwortet.

Ein Datenverzeichnis einer stillgelegten Chain löschen Sie nach einer Umstellung. Datenverzeichnisse sind nach dem Genesis-Hash benannt (data-<name>-<hash8>: -6210cf07 für Chain 20, -a3defc93 für Chain 19; die sechs Guardian-Hosts verwenden /var/lib/randnode/data-20), alte Verzeichnisse bleiben also bestehen, bis Sie sie entfernen. Bei der Umstellung auf Chain 20 startete ein regionaler Validator (syd1) mit disk_low und 3,9 GB freiem Speicher und hielt den Start bei 25 von 26 an, weil die Verzeichnisse der Chains 14 bis 17 noch darauf lagen; ihr Löschen gab 22 GB frei. Behalten Sie das Verzeichnis der vorherigen Chain einen Tag lang als Rollback-Ziel und entfernen Sie es dann. Bei vollen Blöcken ist jeder rohe Bundle-Beweis seit Chain 14 etwa 1,42 MB groß (bis Chain 13 etwa 1,3 MB). Seit Chain 17 trägt jedes Bundle zusätzlich einen Autorisierungsbeweis, sodass eine Überweisung etwa 2,85 MB an Beweisen umfasst: etwa 1,49 MB für den Bundle-Beweis und 1,36 MB für den Autorisierungsbeweis (Produktionsprofil, gemessen am 2026-09-29). Sobald die Aggregation aktiv ist, beschneidet sie den Beweis eines versiegelten Bundles auf etwa 3 KB, es sei denn, der Node läuft mit --keep-raw-proofs. Den Autorisierungsbeweis erfasst sie nicht; er behält seine volle Größe.

Netzwerk

Öffnen Sie bei einem öffentlichen Node TCP 30303 eingehend. Nodes hinter NAT wählen sich mit --bootstrap nach außen ein. Bei vollen 4-MiB-Blöcken überträgt eine Validator-Verbindung etwa 2 MB/s.

Uhr

Ein Validator braucht NTP. Chain 14 ist die erste Chain, auf der die Echtzeituhr Teil des Konsenses ist (Bridge-Härtung B2):

Ein Validator, dessen Uhr 20 s nachgeht, hört stillschweigend auf abzustimmen: Er sieht jeden ehrlichen Block als seiner Uhr voraus und hält seine Stimme zurück, und nichts schlägt fehl. Auf Chain 20 müssen achtzehn von sechsundzwanzig abstimmen, damit überhaupt etwas committet wird. Prüfen Sie jeden Validator und installieren Sie chrony, wo die Uhr nicht synchronisiert ist:

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

Dieselbe 15-s-Grenze gilt für einen Genesis. Setzen Sie timestamp_ms nahe an die Startzeit und nie davor: Ein Genesis, der mehr als 15 s in der Zukunft liegt, committet keinen Block 1, bis die Echtzeit ihn erreicht, und einer, der weit in der Vergangenheit liegt, lässt die Blockzeit hinter der Echtzeit zurück, die sie mit höchstens 60 s pro Block aufholt (docs/deploy.md). Ein Observer stimmt nicht ab, daher bindet ihn die Abstimmungsregel nicht.

DigitalOcean-Größen, auf denen das testnet läuft

Diese Tabelle deckt die ursprünglichen achtzehn Validatoren ab. Seit 2026-09-27 läuft auch Validator A auf einem Droplet (sgp1), nicht mehr auf einem Laptop. Auf Chain 15 wurden acht weitere Validatoren gebondet (2026-09-27): die beiden Archivknoten, obs1 und rand-archive-2 (fra1), sowie die sechs Guardian-Hosts. Ihre Droplet-Größen sind hier nicht festgehalten, ebenso wenig, ob mkc1 und mem1 vergrößert wurden. Alle 26 sind auf Chain 20 Genesis-Validatoren, wie auf Chain 19, mit je 1.000 RAND, und Stand 2026-09-30 liegen alle 26 Schlüssel bei einem einzigen Betreiber.

Proving-Speicher

Die Wallet beweist jede Transaktion, die sie sendet, daher braucht der Aufrufer eines Programms den Speicher für die Stufe dieses Programms. Dies sind die gemessenen Grenzen. Die Läufe auf Stufe 18 sind auf DigitalOcean abgeschlossen, bewiesen und verifiziert; Stufe 20 nicht. Seit v0.5.6 lehnt die Chain einen Aufrufbeweis oberhalb von Stufe 14 ab (MAX_CALL_TIER), die Zeilen für Stufe 16, 18 und 20 unten sind also Messungen und keine Aufrufe, die Chain 20 zulässt; jeder auf Chain 14 committete Aufruf war Stufe 10.

Die ERC-20-Aufrufe landen auf den Stufen 16 und 18 und SPL Token auf Stufe 20 (Ethereum, Solana). Auf einer Maschine mit 48 GB wurde kein Beweis auf Stufe 18 oder 20 erzeugt.

Aggregatoren

Ein Aggregator beobachtet die Chain, nimmt die Bundle-Beweise eines Fensters finalisierter Blöcke, beweist darüber einen rekursiven Aggregatbeweis und reicht ihn ein. Der Block, der ihn aufnimmt, ist ein versiegelnder Block. Der Aggregator erhält den Proving-Anteil der abgedeckten Bundles plus eine Blocksubvention in neuen RAND, an seine registrierte Auszahlungsadresse. Die Aggregation ist permissionless: Jeder Betreiber mit einem Bond kann sich registrieren.

Sie existiert nur auf einer Chain, deren Genesis einen Abschnitt aggregation hat. Chain 20 hat keinen, und ihr Build weigert sich, mit einem Genesis zu starten, der einen hat.

Hardware

Die Werte für N = 2 und N = 3 wurden am 2026-09-28/29 auf einem DigitalOcean-Droplet mit 256 GB unter Constraint-Set 7 gemessen, und der Produktions-Exit-Beweis brauchte mehr als die 256 GB dieser Maschine. Keiner wurde unter Constraint-Set 8, das die Chains 18 bis 20 verwenden, erneut gemessen; betrachten Sie die Zeile für N = 1 daher als Untergrenze. Das CUDA-Backend lief am 2026-09-28 erstmals auf echter Hardware, auf einer NVIDIA H100: Seine Kernel werden zu PTX für sm_80 und sm_90 gebaut und stimmen mit der CPU-Referenz überein. Die Produktionsmessung auf einem GPU-Node der Flotte steht noch aus. Jeder Node zahlt außerdem einmalig beim Start den Key-Build für das Aggregatprogramm: 13,0 bis 13,4 s beim Testprofil (2¹⁹) und erwartet 30 bis 70 s in der Produktion (2²¹).

Befehle

# 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 zeigt auf einer solchen Chain einen Abschnitt aggregation: registrierte Aggregatoren, nicht versiegelte Blöcke und den Index des Subventionsplans. rand_getUnsealed ist die Arbeitsliste.

Einrichtung

Diese Schritte folgen den Skripten, die das testnet verwendet (deploy/vps-setup.sh, deploy/update-droplet.sh). Sie ergeben einen Linux-Validator oder -Observer.

1. Auf einem Build-Host bauen

Der Build benötigt build-essential clang cmake pkg-config libssl-dev, Rust 1.98.1 (festgelegt durch rust-toolchain.toml) und einen circuits-Checkout neben dem fullnode-Checkout. Der erste Build dauert 10 bis 20 Minuten.

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 benötigt vor init auf jedem Node v0.6.8. Ihr Genesis enthält Felder, die kein früherer Build liest (testnet, binding_domain, proof_window_blocks, program_state, die Gruppen rotation und fees der Bridge, die Gas-Obergrenzen, Staking-Zulassung per Abstimmung), und v0.6.8 enthält die Konsensänderungen CON-4 und CH-1 aus Audit v6. Beweise werden weiterhin unter Constraint-Set 8 erzeugt, wie auf den Chains 18 und 19, mit einem Autorisierungsbeweis neben jedem Bundle-Beweis (hc_auth). Ein v0.6.8-Build weist das Genesis der Chains 14 bis 17 bei run und verify zurück. Führen Sie genau den Build aus, den die Flotte ausführt. Die Genesis-Datei liegt im main des fullnode (Commit 74cfaca0), nicht im Tag v0.6.8, daher die dritte git-Zeile. Der circuits-Checkout muss auf dem Commit stehen, aus dem das Release vendored wurde; diesen liest die zweite git-Zeile oben aus dem fullnode-Baum aus. Fügen Sie -p randprotocol-prover hinzu, um auch rand-prover zu bauen.

2. Die Binärdateien auf dem Node installieren

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. Schlüssel, Genesis, Firewall

Auf dem 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

Erzeugen Sie den Schlüssel wie oben auf dem Node und halten Sie ihn aus jedem Checkout heraus. Im fullnode-Repository ist kein Schlüssel mehr versioniert (Audit v3, OPS-1). Die für die Chains 8 bis 13 committeten Dateien deploy/node-*.key.json sind veröffentlichte Seeds; die Validator-Schlüssel von Chain 20 (die achtzehn für Chain 14 erzeugten und die acht, die auf Chain 15 gebondet wurden) wurden außerhalb des Repositorys erzeugt, und die Flotte legt den Schlüssel jedes Droplets in /root/keys/node-<name>.key.json ab, außerhalb des Quellbaums. Der Speicherort ist wichtig auf einem Node, der mit den Skripten der Flotte bereitgestellt wurde: deploy/rebuild-vps.sh und deploy/push-to-vps.sh übertragen /root/fullnode per rsync mit --delete, sodass ein Schlüssel innerhalb dieses Baums vom nächsten Rebuild gelöscht wird und die Unit danach nicht mehr startet. Seit v0.6.8 weigert sich keygen, eine vorhandene Datei zu überschreiben (v0.6.7 überschrieb sie ohne Rückfrage); das test -e macht die Zeile in beiden Fällen gefahrlos wiederholbar. Sichern Sie den Schlüssel außerhalb des Hosts, bevor Sie ihn bonden.

init gibt den Genesis-Hash aus. Er muss 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 lauten (Chain 20). Die Genesis-Datei ist genesis-chain20.json in deploy/ des fullnode-Repositorys auf main. Benennen Sie das Datenverzeichnis nach den ersten acht Zeichen des Hashs, wie es die Flotte tut (data-<name>-6210cf07), damit es nie mit dem von Chain 19 (-a3defc93) oder einer späteren Chain kollidiert. Das Genesis legt diese Grenzen fest. Das Beweislimit betrug auf den Chains 13 bis 16 8 MiB und beträgt seit Chain 17 4 MiB, ab der eine Transaktion bis zu drei Beweise tragen konnte:

Das Genesis von Chain 20 enthält außerdem consensus_domain: 1, binding_domain: 1, testnet: true, einen Abschnitt staking mit Zulassung per Abstimmung, einen Abschnitt gas mit Preisobergrenzen, die Gruppen rotation und fees der Bridge, hardening_v6 und die beiden Guest-Pins hc_bundle und hc_auth; Running a node listet auf, was sie festlegen.

4. Eine systemd-Unit

Dies ist die Unit, die deploy/vps-setup.sh mit den obigen Pfaden schreibt:

[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

Lassen Sie --validator für einen Observer weg. --prune-history 24h ist das, was die Validatoren des testnet ausführen, mit Ausnahme der Archive; lassen Sie es bei einem Node weg, der die vollständige Historie behält, und übergeben Sie es niemals auf mainnet-beta. Die Bootstrap-Multiaddrs für Chain 20 sind die Nodes C (fra1), D (ric1) und E (sgp1), unverändert gegenüber Chain 19. Chain 20 läuft auf den für Chain 14 erzeugten Validator-Schlüsseln, und eine p2p-Identität wird aus dem Validator-Schlüssel abgeleitet, daher sind dies die Peer-IDs, die Chain 14 verwendet hat. Ein neuer Node, der ab Genesis synchronisiert, braucht außerdem einen Peer mit vollständiger Historie; fügen Sie also eines der beiden Archive hinzu (obs1, dann 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

Belassen Sie den RPC auf 127.0.0.1, sofern keine Firewall ihn schützt. Ein Node, der die Öffentlichkeit bedienen soll, öffnet daneben den öffentlichen Listener von v0.6.8 (--public-rpc <ADDR>) und setzt einen Proxy davor, niemals vor --rpc (JSON-RPC). Eine von v0.6.7 übernommene Unit darf nicht --prover-accept-spend-key übergeben, was v0.6.8 beim Start verweigert.

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

5. Dem Validator-Set beitreten

Ein neuer Schlüssel gehört zu keinem Epochen-Set. Auf Chain 20 muss er zuerst hineingewählt werden: Ihr Genesis setzt staking.admission_by_vote, sodass Validatoren, die mehr als zwei Drittel des Stimmgewichts halten, ihn jeweils mit rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash> signieren, und einer übermittelt die Stimmen mit rand-node admit submit; rand_getAdmitted listet ihn dann auf. Binden Sie danach mindestens 1,000 RAND an ihn: Geben Sie eine Registrierung aus mit rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (Chain 20 weist eine v1-Registrierung zurück), und bonden Sie dann aus einem Wallet mit rand bond <address> 1000 --registration <hex>. Der Bond wartet auf seine Aktivierungsepoche, frühestens drei 1,000-Block-Grenzen nach seinem Commit, und höchstens 2,500 bps des aktiven Gewichts werden pro Grenze zu neuem Gewicht (Chain 19 deckelte es auf feste 10,000 RAND). Staking führt Sie durch den Ablauf.

6. Aktualisieren

Dies gilt für einen Build, der dieselbe Chain ausführt. Der Wechsel von einer früheren Chain auf Chain 20 ist kein Update: Er erfordert die neue Binärdatei, das neue Genesis und ein frisches Datenverzeichnis, und das Datenverzeichnis der alten Chain kann danach gelöscht werden (deploy/retire-chain-dirs.sh; die Flotte behält es einen Tag für ein Rollback). Um einen neuen Build ohne Chain-Cut auszurollen, bauen Sie einmal, vergleichen Sie den sha256 von rand-node und rand, stoppen Sie den Dienst, installieren Sie und starten Sie neu, jeweils einen Node nach dem anderen. Einige Releases werden stattdessen komplett gestoppt und komplett gestartet (die Call-Tier-Regel von v0.5.6, die Status-Wire-Änderung von v0.5.7, die strengere Beweisverifikation von v0.6); die Hinweise jedes Releases nennen, welches Vorgehen gilt. v0.6.7 wurde auf Chain 18 Node für Node ausgerollt; v0.6.8 kam mit Chain 20, komplett gestoppt, komplett gestartet, weil seine Konsensänderungen CON-4 und CH-1 niemals Node für Node ausgerollt werden dürfen. Warten Sie, bis jeder Node wieder beigetreten ist, bevor der nächste folgt, damit das Quorum nie um mehr als einen fehlt. deploy/update-droplet.sh <ip> [build-host] tut genau das über SSH.

Die Releases bis v0.6.8 wurden von Hand auf einem Host gebaut und sind unsigniert. Das GitHub-Release v0.6.8 enthält rand-node, rand, rand-prover und SHA256SUMS, gebaut auf Node E; diese Prüfsumme erkennt einen beschädigten Download und bürgt nicht für den Build-Host. v0.6.8 liefert einen Release-Workflow mit, der die Binärdateien aus dem Tag baut, und deploy/update-droplet.sh verweigert eine Installation ohne signierte SHA256SUMS, sofern nicht ALLOW_UNSIGNED=1 gesetzt ist. deploy/release-signers listet noch keinen Schlüssel, daher wurde der signierte Pfad noch nicht genutzt.

Die Chains 15, 16, 17 und 18 gingen innerhalb von 2.7 Tagen live (2026-09-26 bis 2026-09-29), jede als Komplettstopp der Flotte. Chain 19 folgte am 2026-10-01 um 03:43 UTC, ein Re-Genesis von Chain 18 auf demselben Build, und Chain 20 am selben Tag um 06:17 UTC, geschnitten aus einem Snapshot von Chain 19 beim Hard Fork v0.6.8; jeder Node stoppte bei der Chain-19-Höhe 7,700. Eine schriftliche Cut-Richtlinie (2026-09-30) gilt ab Chain 20; der Cut-Eintrag von Chain 20 verzichtete auf den Rebuild durch einen zweiten Operator, weil ein Operator alle Schlüssel hält. Ein Cut braucht einen Grund, den ein Rolling Update nicht erfüllen kann, eine veröffentlichte Liste dessen, was er mitführt und was er streicht, eine zuvor abgeschlossene Checkliste für den Client-Rebuild, einen zweiten Operator, der das Genesis auf denselben Hash neu baut, einen Rollback-Plan und eine nie zuvor verwendete Chain-ID.