Mitmachen

Einen Rand Node betreiben

Der Referenz-Full-Node und seine Wallet sind in Rust geschrieben und werden aus dem Quellcode gebaut. Dabei entstehen zwei Binärdateien: rand-node, der Node samt Betreiberwerkzeugen, und rand, eine Wallet, die einen Shielded-Spend-Key hält, mit jedem Node über JSON-RPC kommuniziert und für jede Überweisung und jeden vertraulichen Aufruf den zkVM-Prover lokal ausführt. Ein experimentelles Testnet, Chain 21, läuft mit 26 Validatoren auf DigitalOcean-Droplets. Es ist nicht auditiert und hat keinen realen Wert. Linux-x86_64-Binärdateien beider Programme hängen am Release v0.8.0, dem Build, auf den die Flotte umgestellt wurde.

Lokal bauen und ausführen

bash

# 1. Rust (rustup übernimmt die festgelegte Toolchain 1.98.1) und die Build-Abhängigkeiten von RocksDB
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
sudo apt install build-essential clang cmake pkg-config libssl-dev   # Linux

# 2. Klonen und bauen (beim ersten Mal 10–20 Min.)
git clone https://github.com/randprotocol/fullnode.git
cd fullnode
cargo build --release        # target/release/rand-node, target/release/rand

# 3. Eine Chain mit zwei Validatoren auf diesem Rechner (RPC auf 8545 und 8546)
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status

# 4. Tests; im Release-Modus, weil STARK-Beweise im Debug-Modus langsam sind (678 Tests, rund 43 Minuten, gemessen am 2026-09-14)
cargo test --workspace --release

Dem öffentlichen Testnet als Beobachter beitreten

Chain 21

# Release v0.8.0 (c0878c3f) betreibt chain 21, und keine frühere Release tut das: chain 21 läuft mit constraint set 9, dessen verifier keys und Proof-Kodierung in keiner älteren Version enthalten sind. Bauen Sie es aus dem Tag oder unter Linux x86_64
# die Release-Binärdateien und prüfen Sie sie anhand der mitveröffentlichten SHA256SUMS
git checkout v0.8.0 && cargo build --release
curl -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand-node -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/rand \
     -LO https://github.com/randprotocol/fullnode/releases/download/v0.8.0/msauth-vk-production.bin# der fest hinterlegte Multisig-Verifier-Schlüssel: rand-node lädt ihn neben seiner Binärdatei und verweigert ohne ihn den Start
sha256sum rand-node rand msauth-vk-production.bin   # muss die Werte der Release ausgeben (SHA256SUMS, signiert als SHA256SUMS.sig):
# 324a4ab1029d39e67fc2de36b036341b0f88f13089997d7fe24c596363a58278  rand-node
# e3a38e74ee28743a960fc1c3eb1ac6c538e18dc259411e10afff7f54e268bbf4  rand
# 68facb06c7f321aaf1d4d541acf6b5c0e9d7f17788ed1c9add6c5a8a8f7acd30  msauth-vk-production.bin

# Ihre Node-Identität: Dilithium2-Validator-Schlüssel und p2p-Peer-ID in einer Datei. Erzeugen Sie Ihre eigene
# und bewahren Sie sie außerhalb des Checkouts auf; das Repository enthält keinen Schlüssel mehr
rand-node keygen --out node.key.json

# Der Genesis-Block liegt im Repository; jeder Node muss die identische Datei besitzen.
# init gibt seinen Hash aus, der mit dem unten stehenden übereinstimmen muss
rand-node init --datadir ./data --genesis deploy/genesis-chain21.json

# Verbinden Sie sich mit den öffentlichen Validatoren (chain 21 behielt die Schlüssel von chain 14, also deren Peer-IDs und IPs).
# Lassen Sie --validator weg: Ihr Schlüssel gehört nicht zur Validatorenmenge. Ein Validator benötigt außerdem NTP
rand-node run --datadir ./data --key node.key.json \
    --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns \
    --bootstrap /ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe \
    --bootstrap /ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw \
    --bootstrap /ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ

# Eine Wallet ist ein separater, shielded Schlüssel. Ihre rand1…-Adresse umfasst etwa 1,6 KB Text
rand keygen && rand address

# Ein Faucet-Mint wird von einem Validator signiert und benötigt daher die RPC eines Validators: Er funktioniert auf der
# lokalen Chain mit zwei Validatoren unverändert; ein Observer antwortet "ask a validator node". Auf chain 21
# prägt der Faucet nur an die 16 Wallets, die seine Genesis auf die Allowlist setzt, und nur von den Validatoren, die sie nennt
rand faucet                                  # 100 RAND in eine Note, die nur Sie öffnen können
rand balance                                 # durchsucht den Baum mit Ihrem Schlüssel; niemand sonst kann das
rand send <rand1 address> 1.5              # fragt nach Bestätigung, erzeugt den Beweis (~2 min), wartet auf den Commit

Validatoren

Quorum

18 of 26

Genesis

ca76c2766ed6090ac6ba5dad86b724dd5d2b80c0edfaed287cd8b129e663ca9a

Einen vertraulichen Aufruf ausführen

rand

# Ein eingebautes Guest-Programm assemblieren: den Überschuss über 1000 zahlen, wenn vier private Guthaben ihn decken
rand program build --guest private_payment --arg 1000 --out pp.json
rand program deploy pp.json                  # gibt die Programm-ID aus (ihren Inhalts-Hash)

# Lokal beweisen; nur der Beweis, acht Ausgabewörter und ein versiegeltes Eingabeprotokoll gelangen auf die Chain
rand call <program id> --input 400 --input 250 --input 300 --input 75
rand receipt <tx>                            # Ausgaben [1, 0, 25, 0, ...]: der Überschuss, als Daten veröffentlicht

# Später das Protokoll öffnen und gegen den vom Beweis veröffentlichten H_IN prüfen
rand open-call <tx>                          # inputs: [400, 250, 300, 75] — verdict: faithful

Die Chain sieht die Programm-ID, die Gas-Stufe und die acht Ausgabewörter. Die Guthaben sieht sie nie, und weil die Gebühr von einem Shielded-Bundle bezahlt wird, erfährt sie auch nicht, wer aufgerufen hat; Ausgaben sind Daten, und jede Zahlung ist ein Bundle, das der Aufrufer erzeugt. Gemessen auf Apple Silicon: Beweiserzeugung in rund 7 s bei Stufe 10, ein Beweis von rund 1,2 MB beim FRI-Profil mit 80 Queries und Verifikation in rund 16 ms mit warmem Verifier-Schlüssel, den ein Node einmal pro Stufe berechnet und über Programme hinweg wiederverwendet.

Voraussetzungen

Betriebssystem: Linux x86_64 oder macOS arm64
Rust: 1.98.1, festgelegt durch rust-toolchain.toml; rustup installiert es
Build-Abhängigkeiten: C++-Compiler, cmake, pkg-config, OpenSSL-Header (RocksDB)
Erster Build: 10 bis 20 Minuten: RocksDB und Plonky3 aus dem Quellcode
Ports: TCP 30303 eingehend bei öffentlichen Nodes; RPC auf 127.0.0.1:8545
Server: Eine Cloud-Instanz mit 1 bis 2 vCPU betreibt einen Testnet-Validator
Uhr: NTP (chrony) auf einem Validator: Er hält seine Stimme für einen Block zurück, der mehr als 15 s seiner eigenen Uhr voraus ist, sodass eine nachgehende Uhr unbemerkt das Abstimmen beendet
Beweiserzeugung: Heute nur auf der CPU: Eine Shielded-Überweisung dauert auf einem Laptop rund zwei Minuten (ein Autorisierungsbeweis von 7 s und ein Bundle-Beweis von rund 110 s) und braucht rund 6 GB Speicher; ein kleiner Aufruf kostet rund 30 s zusätzlich

Eine Rolle wählen

Beobachter offen für alle

Dieselbe Binärdatei ohne --validator. Sie synchronisiert die Chain, verifiziert jedes Zertifikat sowie jeden Bundle- und Aufruf-Beweis, führt jeden Block erneut aus, vergleicht die Receipts und stellt JSON-RPC bereit. Das führt ein neuer Schlüssel im öffentlichen Testnet aus.
Validator mit Bond

Stimmt ab und schlägt Blöcke vor unter Chained HotStuff. Auf chain 21 wird, wie schon auf chain 20, ein neuer Validator zuerst per Abstimmung zugelassen: Validatoren, die mehr als zwei Drittel des Stakes halten, signieren eine AdmitValidator-Aktion für seinen Schlüssel. Danach registriert er den Node-Schlüssel (rand-node register --v2), hinterlegt mindestens 1.000 RAND aus einer Wallet als Bond und tritt an der dritten 1.000-Block-Epochengrenze nach dem Bond in die Menge ein (die Zwei-Epochen-Bond-Verzögerung von chain 18). Chain 18 startete mit 26 Validatoren zu je 1.000 RAND; mehr als zwei Drittel des Stakes, 18 von 26, müssen online sein und abstimmen, damit ein Commit zustande kommt. Erzeugen Sie Ihren eigenen Schlüssel: Im Repository wird kein Validator-Schlüssel mehr geführt, und die für frühere Chains committeten Schlüsseldateien sind veröffentlichte Seeds.
Wallet und Prover lokal

Der rand-Client hält einen 256-Bit-Spend-Key und signiert nichts: Die Autorisierung besteht aus zwei Beweisen, einem kleinen, der mit dem Spend-Key erzeugt wird, und dem Bundle-Beweis mit 4 Ein- und 4 Ausgängen. Er durchsucht den Baum nach den eigenen Notes, erzeugt beide Beweise auf Ihrem Rechner, in derselben Form für RAND wie für jeden RPL-Token, und beweist bei einem vertraulichen Aufruf auch das Programm. Nur Beweise, Commitments, Nullifier und versiegelte Umschläge erreichen die Chain.

Sie betreiben keinen Node? Dieselbe Wallet gibt es als App für iOS, Android, Chrome und Firefox: Wallets.

Quellcode

randprotocol/fullnode

GPL-3.0-only · das Testnet läuft mit v0.8.0, dem neuesten Release

Verifizieren

Jeder Node prüft alles

Ein Node, der synchronisiert, verifiziert vor der Annahme jedes Zertifikat erneut, führt jeden Block samt seinen Beweisen erneut aus und vergleicht die Receipts. Beim Start prüft er seine eigene Datenbank, kürzt alles Inkonsistente, behält dabei aber seinen Vote-Safety-Zustand, und lädt die Lücke von Peers nach.

# Node gestoppt: Hashes, QCs, Signaturen, Beweise, Replay
rand-node verify --datadir ./data --mode full
rand-node verify --datadir ./data --repair

Fehlertests laufen im Live-Testnet

›Einen von vier Validatoren stoppen: Die Chain committet weiter, und der Node holt in Sekunden auf, sobald er zurückkehrt.
›Zwei von vier stoppen: Die Chain hält ohne Quorum an und läuft ohne Fork weiter, wenn sie zurückkehren.
›Die Datenbank eines Nodes beschädigen: Beim Start erkannt, gekürzt, von Peers neu synchronisiert, danach byteidentisch.
›Überweisungen über verschiedene Nodes: alle committet, Guthaben überall identisch, Gesamtmenge unverändert.
›Eine getrennte Peer-Verbindung wird von der Redial-Logik innerhalb von rund 30 Sekunden wiederhergestellt.

Noch nicht implementiert

Aufgeführt, damit die Lücke zwischen dem Paper und dem Node erkennbar ist, statt erschlossen werden zu müssen.

›Persistenter Zustand pro Programm und programmübergreifende Aufrufe
›Ein Compiler in der Wallet selbst: Ein Programm ist entweder ein eingebautes, assembliertes Guest-Programm oder ein Image, das mit der separaten rand-guest-Toolchain erstellt wurde
›Slashing und Jailing, Blockbelohnungen, Gebührenmärkte, der Hash-Sortition-Leader-Beacon
›Ein Nullifier-Akkumulator, Proof-Pruning nach der Finalität, Proof-Batching
›Ein Tier-20-Proof des SPL-Token-Transfers und der GPU-Prover-Markt aus dem Paper