Entwickler

Rand ist Open Source. Der Full Node, der Explorer, die Bridge, die Proving-Forschung und die Wallet-Clients liegen jeweils in einem eigenen Repository auf GitHub. Lesen Sie den Code, führen Sie die Tests aus, senden Sie Patches. Diese Seite ist die Übersichtskarte: wo jede Komponente liegt, womit sie gebaut ist, wie weit das Beweissystem gekommen ist und wo es heute endet.

Repositories

Der Stack

Rust von Anfang bis Ende. Rand ist eine eigene Chain: ein HotStuff-BFT-Node mit einer libp2p-Gossip-Schicht, einem vollständig abgeschirmten Note-Pool als Ledger, postquantensicheren Signaturen und Note-Verschlüsselung sowie der Rand zkVM für vertrauliche Berechnungen, alles im Fullnode-Repository. Das Beweissystem selbst ist der Teil, an dem aktiv geforscht wird, siehe unten.

Eine Relation für jedes Programm

Die universelle Ausführungsrelation R_exec des Whitepapers existiert als Code: rand_zkvm, eine RV32IM-Maschine, bewiesen unter einem einzigen Batch-STARK auf Plonky3 über dem Goldilocks-Körper. Er beweist, dass irgendeine Trace das Programm hc zu diesen öffentlichen Ausgaben ausgeführt hat, auf Eingaben, auf die ein gesalzenes H_IN festlegt, und nichts am Programm ist je ein Parameter des Verifiers. Ein vertrauliches Programm zu veröffentlichen bedeutet, einen Hash zu registrieren, nie, eine maßgeschneiderte Schaltung zu erzeugen.

Das Beweissystem ist transparent, ohne Trusted Setup und ohne Pairing-Kurve, und seine Annahme ist eine kollisionsresistente Hashfunktion. Jede andere Komponente, die mit Beweisen zu tun hat, soll auf dieses Crate konvergieren, statt ein eigenes zu entwickeln. Das Crate liegt in zkp-circuits/research und ist bei Constraint-Set 8 in den Fullnode vendored (circuits aeacf31, Fullnode v0.6.7 und v0.6.8). Die Tabellen und Messungen unten beschreiben Constraint-Set 5 (Meilenstein M4.2), sofern eine Zeile nicht ein späteres Set nennt; sie stammen aus docs/zkvm.md, docs/zkvm-milestones.md und docs/confidential.md des Fullnode, Stand 2026-09-13, und Messwerte werden so angegeben, wie sie auf einem Apple-Silicon-Laptop gemessen wurden, nicht als Zielwerte.

Acht Tabellen auf benannten Bussen, eine neunte bei Bedarf

Eine Festlegung, eine FRI-Öffnung. Tabellen rufen einander nie auf; sie tauschen Fakten über benannte LogUp-Busse aus (PROGRAM, PROGRAM_WORD, MEMORY, ALU, POSEIDON2, INPUT_DIGEST, INPUT_READ, KECCAK sowie die Range- und Nibble-Lookups), und der Verifier prüft, dass jeder Bus global ausgeglichen ist. Der maximale Constraint-Grad jeder Tabelle ist per Test unterhalb der Grenze von 8 festgenagelt, die der FRI-Blowup erlaubt.

Seither sind drei Constraint-Sets hinzugekommen. Set 6 fügte eine obligatorische Tabelle public für die beim Deployment festgelegte öffentliche Eingabe eines Programms hinzu, gebunden an den ungesalzenen Digest H_PUB, sowie eine optionale Tabelle sha256 neben keccak. Set 7 (Chain 16) verblindet jeden LogUp-Terminal auf einem neuen BLIND-Bus und setzt für jede deklarierte Tabelle eine Untergrenze von 2⁷ Zeilen, und es fügt den längengebundenen Syscall POSEIDON2_LEN hinzu. Set 8 (Chain 18) fügt der cpu-Tabelle eine Spalte GAS und einen öffentlichen Wert hinzu, das deklarierte GAS_LIMIT.

Was ein Beweis offenlegt

Öffentlich: der Code-Hash hc (acht Digest-Wörter in der Schaltung), die gesalzene Eingabe-Festlegung H_IN (acht Wörter), die Gas-Stufe und acht Ausgabewörter. Seit Constraint-Set 6 auch H_PUB, der Digest der öffentlichen Eingabe, und seit Constraint-Set 8 das deklarierte Gas-Limit. Der Header des Beweises deklariert die Höhen der Keccak- und SHA-256-Tabellen, sodass er zeigt, ob ein Aufruf gehasht hat und, oberhalb der Untergrenze von 2⁷, ungefähr wie viel.

Verborgen: die privaten Eingaben (H_IN ist gesalzen und daher ebenso verbergend wie bindend); jedes Instruktionswort, weil der Verifier hc prüft und nie das Programm; jeder Register- und Speicherwert; jede genommene Verzweigung; die exakte Zyklenzahl und das exakt verbrauchte Gas; und welche Syscalls liefen, abgesehen von dem, was die Höhen der beiden Hash-Tabellen zeigen.

Die Stufe ist pro Beweis öffentlich, weil schon die Größe eines STARK seine Trace-Höhe verrät; den Index zu verbergen brächte nichts. hc ist bindend, nicht verbergend: siehe wo es heute endet.

Gemessen, bei Constraint-Set 5

Apple-Silicon-Laptop, Release-Build. Die Aufteilung der Byte-Tabellen in M2.3 hat die Beweiszeit verändert; das 80-Query-Profil hat die Beweisgröße wieder nach oben gebracht. Der Verifier-Schlüssel ist unabhängig vom Programminhalt und wird durch die Stufe sowie die vom Beweis deklarierten Höhen von Programm, Eingabe und Keccak bestimmt, sodass ein Node einen Schlüssel aufwärmt und wiederverwendet.

Spätere Sets haben die Größen verschoben. Unter Constraint-Set 7 ist ein Tier-10-Beweis im Produktionsprofil 1.367.688 Bytes groß, ein Tier-10-Beweis mit Keccak 3.283.898 (gemessen am 2026-09-28). Seit Chain 17 trägt ein Transfer zwei Beweise: den Tier-14-Bundle-Beweis mit etwa 1,49 MB und den Tier-10-Auth-Beweis mit etwa 1,37 MB, dessen Beweiserstellung etwa 7 s dauert. Das Genesis von Chain 20 setzt einen Block von 20 MiB und eine Beweisobergrenze von 4 MiB; ein Aufruf darf Tier 14 nicht überschreiten.

Drei Ziele, ein Schaltkreis

Nur RISC-V wird nativ ausgeführt. Solidity- und Solana-Programme laufen entweder auf einem Interpreter-Guest innerhalb derselben Relation, mit ihrem Bytecode als Eingabe, oder sie werden off-chain in RISC-V-Programme übersetzt, deren Ausgaben Wort für Wort denen des Interpreters entsprechen. Die teuren Opcodes verlangen dedizierte Koprozessor-Tabellen statt einer bitweisen Simulation.

Meilensteine

Meilenstein 1 hat die Allzweckmaschine bewiesen. Meilenstein 3 machte daraus einen abgeschirmten Pool: Ein Transfer mit Mitgliedschaftsnachweis im Schaltkreis wird unter R_exec bewiesen, und der Verifier prüft hc, ohne je ein Programmwort zu sehen. Meilenstein 4 ist die Kompatibilität: Sein Loader, die Eingabe-Commitment und die Keccak-Tabelle wurden als Constraint-Sets 4 und 5 ausgeliefert, die SHA-256-Tabelle mit Set 6. Die Interpreter-Guests für EVM und sBPF, die rand-guest-Toolchain und die beiden Übersetzer sind gebaut. Der ERC-20-Transfer wurde auf einer Maschine mit 128 GB bewiesen; der SPL-Token-Beweis auf Tier 20 noch nicht. Meilenstein 5 ist die Rekursions-VM hinter der Blockaggregation, die gebaut und auf jeder Chain abgeschaltet ist. Die Constraint-Sets 7 und 8 folgten auf die Reviews vom September und auf das Gasmodell.

Phasen des abgeschirmten Pools

Das Ledger des Fullnodes entstand in drei Phasen, jede ein Hard Fork (docs/shielded.md §7). S1 ersetzte das Konten-Ledger durch einen Note-Pool; S3 brachte die Bridge als Notes zurück und landete zuerst; S2 setzte das Staking darauf. Alle drei sind auf main und auf der aktuellen Chain.

Jede Zeile unterhalb von S2 gehört zur Arbeit an v0.5. Jede Zeile ist ein Hard Fork. Alle wurden gemeinsam als eine neue Chain umgesetzt, Chain 14, am 2026-09-20 aus dem Build b3c594c geschnitten und am selben Tag als v0.5 getaggt, nach einem Live-zUSD-Roundtrip über die bereitgestellten Source-Endpunkte. Chain 15, live seit 2026-09-26 auf v0.5.8 und später, enthielt alles davon, mit den genesis-gesteuerten Korrekturen der Audits v4 und v5: ein Faucet mit Allowlist und Budget pro Epoche, verzögerte Bond-Aktivierung, eine Obergrenze für das Stake-Gewicht, an das Genesis gebundene Registrierungen, consensus_domain 1, Bridge-Regeln v2 sowie die Obergrenze des Token-Registers, verbrannte Registrierungsgebühr und die Notes-Schranke von 2⁶³. Chain 20, live seit 2026-10-01 06:17 UTC auf v0.6.8 (c9c9bd3c), ein Hard Fork von Chain 19, behält alles bei und ergänzt die Arbeit der v0.6-Versionen, unten aufgeführt.

Versionen seit v0.5

Jede Version ist ein Git-Tag mit einem Eintrag im CHANGELOG.md des Fullnodes. Eine Version, die den Konsens, das Wire-Format oder einen Verifier-Schlüssel ändert, erscheint mit einer neuen Chain; die anderen werden Node für Node auf die laufende Chain ausgerollt.

Wo es heute endet

Abweichungen vom Whitepaper, benannt statt geglättet. Jede wird in der eigenen Dokumentation des Crates mit dem Meilenstein verfolgt, der sie schließt.

• hc ist bindend, aber nicht verbergend: Es trägt kein Salt, sodass ein erratenes Programm bestätigt werden kann und zwei Deployments desselben Programms verknüpfbar sind. Was M3.4 beseitigt hat, ist, dass der Verifier das gesamte Programm im Klartext hält.
• Eine vor dem 2026-09-21 gebaute Wallet fragt ihren Node nach Witnesses, und eine Witness-Anfrage benennt das Blatt, das gleich ausgegeben wird. Ein aktuelles rand führt seine eigene Kopie des Baums und fragt nie nach; der Node bedient rand_getWitness weiterhin für ältere Wallets.
• Einzahlungen sind an der Grenze öffentlich: Ein Faucet-Mint, eine Genesis-Note und eine Bridge-Einzahlung tragen ihren Betrag im Klartext (seit Chain 14 tragen ein Mint und eine Genesis-Note auch ihre Öffnung, sodass auch der Besitzerschlüssel öffentlich ist), dieselbe Ein-Hop-Sichtbarkeit, die eine Einzahlung von transparent zu shielded überall hat.
• Zero Knowledge ist statistisch, nicht perfekt. Das ist die Eigenschaft, die das hiding FRI von Plonky3 0.7 tatsächlich bietet, und das Crate sagt das auch.
• Der Transkript-Hash ist Poseidon2 mit Entwicklungs-Rundenkonstanten, nicht SHA3-384 / BLAKE3-384 der Papiere. Ein Konfigurationstausch, kein Neuschreiben.
• Bei 80 FRI-Queries war ein Bundle-Beweis auf den Chains 14 und 15 etwa 1,42 MB groß (bis Chain 13 etwa 1,3 MB). Seit Chain 17 trägt eine Überweisung etwa 2,85 MB Beweis: den Bundle-Beweis mit etwa 1,49 MB und den Auth-Beweis mit etwa 1,37 MB. Auf einer Standard-Chain mit 4-MiB-Blöcken und einer Beweisobergrenze von 2 MiB überschreitet ein Beweis mit Keccak die Beweisobergrenze glatt; das Genesis von Chain 20 setzt 20-MiB-Blöcke und eine Beweisobergrenze von 4 MiB (die Chains 13 bis 16 setzen 8 MiB).
• Der Header eines Aufrufbeweises ist nicht verborgen. Er deklariert das Tier und die Höhen der Keccak- und SHA-256-Tabellen, zeigt also, ob ein Aufruf gehasht hat. Aufrufe, die auf Chain 15 vor der Untergrenze des v0.6-Provers committet wurden, legten mehr offen: Eine private Tabelle unter 2⁷ Zeilen konnte aus dem Beweis ausgelesen werden. Die Untergrenze des v0.6-Provers hat das für neue Aufrufe geschlossen, und Constraint-Satz 7 mit hardening_v6 machte sie ab Chain 16 zu einer Regel der Chain.
• Ein Aufruf ist auf Tier 14 begrenzt, mit höchstens 2¹² Keccak-Zeilen (128 Permutationen) und 2¹³ SHA-256-Zeilen (128 Kompressionen), und unter hardening_v6 kann ein Programm mit mehr als 8.180 Wörtern nicht deployt werden. Die Interpreter-Guests für EVM und sBPF sowie die übersetzten Images von ERC-20 und SPL Token liegen alle darüber.
• Wer den Witness hält, sieht alles. ZK schützt die Sicht des Verifiers, nicht die des Provers. Seit Chain 17 kann eine Wallet den Bundle-Beweis an einen gekoppelten rand-prover übergeben, ohne den Spend-Schlüssel herauszugeben, doch dieser Prover hält weiterhin den Viewing-Schlüssel und sieht die Notes. Das CUDA-Backend lief am 2026-09-28 erstmals auf Hardware und hat noch keine Produktionsmessung.

Repository-Struktur

Der Cargo-Workspace des Fullnode, wie in seiner README und seinem Verzeichnis crates/ angelegt.

Spezifiziert, noch nicht ausgeliefert

Diese Komponenten sind in den Papieren oder in der Dokumentation des Fullnode beschrieben, laufen aber nicht: Sie fehlen entweder in den Repositories, oder sie sind gebaut und für keine Chain eingeschaltet. Sie sind aufgeführt, damit die Lücke zwischen Spezifikation und Code ablesbar ist, statt erschlossen werden zu müssen.

Bauen und Testen

Standardmäßiger Rust-Workflow in jedem Repository. Das Fullnode-Repository ist ein einziger Cargo-Workspace mit festgelegter Toolchain und einer Cluster-Testsuite, die echte Nodes über TCP startet. Sein Build setzt voraus, dass das Repository circuits daneben ausgecheckt ist, in einem Verzeichnis namens circuits, und zwar auf dem Commit, aus dem die mitgelieferten Crates synchronisiert wurden (aeacf31 für v0.6.7 und v0.6.8). Die zkVM ist ein eigenständiges Crate in zkp-circuits mit eigener Toolchain-Festlegung und einer Demo, die erläutert, was ein vertraulicher Aufruf offenlegt und was nicht.

Der Fullnode:

git clone https://github.com/randprotocol/fullnode.git
git clone https://github.com/randprotocol/zkp-circuits.git circuits   # the sibling directory must be named circuits
git -C circuits checkout "$(sed -n 's/^circuits: //p' fullnode/crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"
cd fullnode

# Rust 1.98.1 is pinned by rust-toolchain.toml; first build pulls RocksDB and Plonky3, 10 to 20 minutes
cargo build --release        # target/release/rand-node, target/release/rand, target/release/rand-prover

# All crates; release because STARK proving is slow in debug. One to two hours, mostly proving
cargo test --release

# One machine, two validators
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status

Die Forschungs-zkVM in zkp-circuits/research:

# Toolchain is pinned by rust-toolchain.toml; the first build pulls Plonky3
cargo build --release

# Narrated demo: thirteen proofs, one at production FRI parameters (~6-7 min)
cargo run --release

# Emulator, per-table constraints, cheating provers, ZK, end-to-end, viewing keys, compiled guests (395 tests, ~17 min)
cargo test

Die Fullnode-Suite, gemessen bei v0.6.1 auf einer Maschine mit 16 vCPUs: core 521 Tests, node 373, client 117, die Cheating-Prover-Suite 116, die Hidden-Bundle-Cheats 21 (75 Min.), der Wallet-Ablauf 6 (53 Min.), der Cluster 26 (44 Min.) und das zUSD-End-to-End-Gate 2 (51 Min.). Die Produktionsbeweise der Recursion-VM sind darin nicht enthalten und benötigen den oben aufgeführten Arbeitsspeicher.

Running a node beschreibt, wie man dem öffentlichen testnet mit dem Build beitritt; das testnet-Genesis, die Bootstrap-Peers und die Startskripte liegen im Verzeichnis deploy/ des Fullnode, und die Download-Seite enthält die Kurzfassung.

Contribute

Der Fullnode steht unter der GNU General Public License v3.0 (GPL-3.0-only); zuvor stand er unter Apache-2.0. Eröffnen Sie Issues für Fehler und Designvorschläge im Repository, das von der Änderung betroffen ist. Pull Requests sind willkommen: Führen Sie vor dem Einreichen cargo fmt && cargo clippy aus und halten Sie Änderungen eng begrenzt. Die fullnode issues sind der beste Ausgangspunkt.

Die Architektur, die Privacy-Schaltung, der Fee-Token-Beweis und der Post-Quanten-Kompromiss sind im Whitepaper auf der Papers-Seite dokumentiert. Das Verzeichnis docs/ des Fullnode-Repositorys ist die Quelle, gegen die jede Seite dieser Dokumentation geprüft wird.