Lesen Sie diese Seite, um zu entscheiden, worauf Sie aufbauen und wo Sie beginnen: das Modell der Chain in wenigen Absätzen, die Parameter des laufenden Testnets, wie Sie Test-RAND erhalten, und eine Übersicht über den Rest der Dokumentation.
Was Rand Protocol ist
Rand ist eine postquantensichere, abgeschirmte Chain. Ihre native Münze ist RAND, und RAND liegt in einem vollständig abgeschirmten Pool: Es gibt on-chain weder Konten noch Guthaben, nur Note-Commitments und Nullifier, und eine Überweisung ist ein Zero-Knowledge-Beweis dafür, dass vier Notes zu vier anderen Notes wurden (Dummys füllen die ungenutzten Plätze), ohne zu zeigen, welcher Vermögenswert bewegt wurde. RAND und jedes Token des chaineigenen Standards RPL teilen sich diesen einen Pool. Dieselbe Münze bezahlt vertrauliche Programme: RISC-V-Programme, die off-chain in einer Zero-Knowledge-Virtual-Machine laufen und on-chain mit einem Beweis statt mit ihren Eingaben abgerechnet werden.
Jede Primitive ist so gewählt, dass sie einem Quantenangreifer standhält:
| Schicht | Was läuft |
|---|---|
| Signaturen | Dilithium2 (gitterbasiert). Validatoren signieren damit Blöcke und Stimmen; der Faucet, die Staking-Aktionen und die Bridge-Registrierungen werden damit signiert. Ein Wallet signiert nie eine Transaktion: Ein Bundle autorisiert sich selbst durch seinen Beweis. |
| Note-Verschlüsselung | ML-KEM-768-Schlüsselkapselung plus ChaCha20-Poly1305. Jede Note on-chain wird von einem Umschlag begleitet, den nur ihr Eigentümer (und ihr Absender) öffnen kann. |
| Hashing | BLAKE3 mit Domänentrennung für Adressen, Transaktions-IDs, die State-Root und alles andere außerhalb des Beweissystems; Poseidon2 über dem Goldilocks-Körper für Notes, Nullifier, den Commitment-Baum und alles innerhalb eines Beweises. |
| Beweise | Ein Plonky3-Batch-STARK mit verbergendem FRI (80 Queries, Blowup 8, 20 Proof-of-Work-Bits). Transparent: kein Trusted Setup, keine Pairing-Kurve, und die Annahme ist eine kollisionsresistente Hashfunktion. |
| Vertrauliche Berechnung | Die Rand zkVM, eine RV32IM-Maschine, die unter diesem STARK bewiesen wird. Ein Programm wird durch einen In-Circuit-Digest identifiziert, und der Verifier sieht kein einziges Instruktionswort. |
| Konsens | Chained HotStuff BFT: stimmgewichtete Quoren von mehr als zwei Dritteln, Round-Robin-Leader, eine Commit-Regel mit drei aufeinanderfolgenden Views. |
| Speicherung und Netzwerk | Eine RocksDB pro Node mit fsync-gesicherten Commits und einer Integritätsprüfung beim Start; libp2p (TCP, Noise, Yamux, gossipsub, Kademlia, mDNS in LANs). |
Die Referenzimplementierung ist randprotocol/fullnode in Rust: Die Binärdatei rand-node ist der Node, die Binärdatei rand ist das Wallet, und die JSON-RPC-Methoden tragen das Präfix rand_. Der Explorer ist randscan.org.
Das Testnet: Chain 20
Die öffentliche Flotte betreibt Chain 20, live seit dem 2026-10-01 06:17 UTC auf fullnode v0.6.8. Die Chains 15 bis 19 sind außer Betrieb. Vier Chains wurden in vier Tagen geschnitten, jede wegen einer Änderung, die jeden Beweis oder das Transaktionsformat verändert:
- Chain 16 (2026-09-28, fullnode v0.6.1) hob die zkVM auf Constraint-Set 7, das verbirgt, was ein Beweis zuvor über kleine private Eingaben preisgab, und schaltete die Regeln
hardening_v6ein. - Chain 17 (2026-09-29, v0.6.3) trennte die Autorisierung einer Überweisung von ihrem Beweis: Jedes Bundle trägt einen zweiten, kleinen Beweis, der mit dem Spend-Schlüssel erstellt wird, sodass der große von einer Maschine erstellt werden kann, die nur einen Viewing-Schlüssel besitzt.
- Chain 18 (2026-09-29, v0.6.7) misst vertrauliche Aufrufe in Gas (Constraint-Set 8) und schaltet das verschlüsselte Memo in jedem Note-Umschlag ein.
- Chain 20 (2026-10-01, v0.6.8) bindet jeden Beweis und jede signierte Nachricht an den Genesis-Hash, fügt Programmzustand hinzu (RPL-2), erhebt eine Gebühr auf zUSD-Bridge-Mints und -Burns und schaltet die Regeln von audit-v6 ein, die in der folgenden Tabelle aufgeführt sind.
Chain 19 (2026-10-01 03:43 UTC, v0.6.7) war ein Re-Genesis von Chain 18 auf demselben Build und änderte keine Regel. Chain 18 wurde bei Höhe 143,776 gestoppt, und Chain 19 wurde aus einem Snapshot bei Höhe 141,935 geschnitten. Ihr Genesis unterschied sich von dem der Chain 18 nur in der Chain-ID, im Zeitstempel, in den übernommenen Notes und im Bridge-Abschnitt: neue Emitter für die Endpunkte von Ethereum, Binance Smart Chain und Tron, wobei die Sequenzzähler übernommen wurden.
Chain 20 ist ein Hard Fork von Chain 19: Ihr Genesis wurde aus einem Snapshot von Chain 19 bei Höhe 7,258 geschnitten, Chain 19 wurde bei Höhe 7,700 gestoppt, und alle 26 Validatoren wurden gemeinsam auf Chain 20 neu gestartet, mit denselben Schlüsseln, Peer-IDs und Bootstrap-Nodes. Chain 19 und Chain 18 sind außer Betrieb. Ein Wallet benötigt v0.6.8, um auf Chain 20 zu senden: Die Beweise und Signaturen eines älteren Wallets tragen die Genesis-Bindung nicht, und die Chain weist sie zurück.
Jede ist eine frische Chain. RAND-Guthaben in den Wallets des Betreibers und das im Umlauf befindliche zUSD wurden in das nächste Genesis übernommen, und sonst nichts: Ein Programm, das auf einer Chain deployt wurde, existiert auf der nächsten nicht. Es ist experimentelle Software: nicht auditiert, und RAND darauf hat keinen Wert.
Programme auf Chain 20 können Zustand halten: Die Programmzellen, Programm-Vaults und die Aktion Invoke von RPL-2 sind live.
| Chain-ID | 20 (rand_chainId) |
| Genesis-Hash | 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 |
| Genesis-Datei | deploy/genesis-chain20.json im Fullnode-Repository |
| Build | Fullnode v0.6.8 (Tag c9c9bd3c); ein Node meldet seinen eigenen Build in rand_getVersion. Dieser Build lehnt die Chains 14 bis 17 ab, und eine Wallet, die älter als v0.6.8 ist, kann auf Chain 20 nicht senden |
| Genesis-Bindung | binding_domain 1: Die Proof-Bindung jedes Bundles und jede signierte Aktionsnachricht enthalten den Genesis-Hash, sodass nichts, was für eine Chain bewiesen oder signiert wurde, auf einer anderen verifiziert wird |
| testnet-Markierung | testnet true: Das Genesis erklärt sich selbst zum Testnetz, und genau das erlaubt es, neben der Bridge einen Faucet zu betreiben |
| Validatoren | 26, jeder mit 1.000 RAND gestakt, dem Staking-Minimum |
| Quorum | 18 von 26: strikt mehr als zwei Drittel des Stakes |
| Blockintervall | der Standardwert --block-interval-ms 1000; etwa ein Block pro Sekunde |
| Blockzeit | Ein Zeitstempel, der mehr als 60 s nach dem seines Vorgängers liegt, ist ungültig, und ein Validator stimmt nicht für einen Block, der der eigenen Uhr um mehr als 15 s voraus ist; deshalb betreiben Validatoren NTP |
| Proof-Fenster | proof_window_blocks 1.024: Der Anker eines Bundles muss eine der letzten 1.024 Block-End-Roots sein, und sein time darf nicht älter sein (256 Blöcke auf den Chains 18 und 19) |
| Epochen | 1.000 Blöcke; ein neuer Bond wartet zwei zusätzliche Epochen, bevor er zählt (bond_activation_epochs 2, Aktivierung in Epoche e + 3), und entbundener Stake wird zwei Epochen später freigegeben |
| Staking | Registrierungen sind v2 (rand-node register --v2), und ein neuer Schlüssel wird erst registriert, nachdem Validatoren mit mehr als zwei Dritteln des Gewichts ihn aufgenommen haben (admission_by_vote); das Gewicht eines einzelnen Validators ist auf 33,33 % begrenzt; neuer Stake, der an einer Epochengrenze hinzukommt, ist auf 25 % des aktiven Gewichts begrenzt (max_stake_entry_bps_per_epoch 2.500); kein Slashing |
| zkVM | Constraint-Set 8, produktives FRI-Profil (80 Queries) |
| Bundle-Guest | hc_bundle 60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce: das Hidden-Asset-Bundle mit 4 Eingängen und 4 Ausgängen, Version 3, Tier 14 |
| Auth-Guest | hc_auth 1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1: die Ausgabeautorisierung, die jedes Bundle mitführt, Tier 10 |
| Gas | Ein Aufruf deklariert ein Gas-Limit, das der Circuit durchsetzt, und zahlt dafür gas_price: am Minimum 100 Einheiten pro Gas und 800 Einheiten pro KiB, beide pro Block in Richtung eines Ziels von 262.144 Gas und 10.485.760 Bytes verschoben und nie über den Obergrenzen von 10.000 pro Gas und 80.000 pro KiB. Nur die Bytes, auf die der Byte-Preis erhoben wird (der Proof und der Input-Envelope eines Aufrufs), zählen zur Byte-Last (byte_load: "paying"), sodass ein Block voller Überweisungen sie nicht erhöht. Jedes Bundle deklariert das festgelegte Limit 20.479 und zahlt pauschal 0,001 RAND |
| Programmzustand | RPL-2 aktiviert: Programm-Zellen, Programm-Vaults und Invoke (Action 33); eine erzeugte Zelle kostet 0,01 RAND (cell_fee 10.000.000 Einheiten); ein Invoke liest höchstens 8 Zellen, schreibt höchstens 8 und führt höchstens 4 Auszahlungen aus (rand_getLimits.program_state) |
| Note-Envelope | envelope_bytes 1860: Der Envelope jeder Note umfasst 1.860 Bytes und enthält ein verschlüsseltes Memo |
| Programmgrenze | max_program_words 65.535, aber unter hardening_v6 wird ein Deploy abgelehnt, den kein Tier-14-Aufruf halten könnte (ProgramUncallable): 8.180 Wörter für ein Programm ohne öffentliches Segment |
| Proof-Grenze | max_proof_bytes 4.194.304 (4 MiB); auf den Chains 13 bis 16 waren es 8 MiB |
| Blockgrenze | max_block_bytes 20.971.520 (20 MiB) |
| Grenze des Aufruf-Envelopes | max_call_envelope_bytes 65.536 |
| Öffentliche Eingabe pro Programm | max_program_public_words 32.768, beim Deploy festgelegt |
| Faucet | aktiviert, aber nur für die 16 Wallets auf der Genesis-Allowlist (staking.faucet_recipients) und nur von den 18 Validatoren, die das Genesis als Minter benennt (staking.faucet_minters): bis zu 100 RAND pro Aufruf, insgesamt 10.000 RAND pro Epoche |
| Vertrauliche Berechnung | aktiviert; ein Aufruf-Proof ist auf Tier 14 begrenzt. Programme werden über einen Cut nicht übernommen; die Beispielprogramme geben an, auf welcher Chain jedes deployt ist |
| Tokens | Die RPL-Registry ist aktiviert: Registrierungsgebühr 1 RAND, verbrannt; höchstens 4.096 Tokens; jeder Note-Wert liegt unter 2⁶³. zUSD ist im Genesis auf Index 1 geführt |
| Bridge | aktiviert: Guardian-Set 1 mit acht Guardians, acht Dilithium2-PQ-Guardians, ein Pause-Schlüssel, Emitter für vier Quell-Chains, ein tägliches Mint-Limit von 100.000 zUSD pro Backing und ein globales Limit von 4.000 zUSD pro rollierenden 24 Stunden über alle Backings hinweg. zUSD hat sieben Backings; sein Supply ist das, was gesperrt ist, live gelesen aus rand_getTokenSupply. Seit Chain 20 wird auf jeden Mint und jeden Burn eine Gebühr von 10 bps erhoben, in zUSD, als Note an eine Treasury-Adresse (bridge.fees): Eine Einzahlung schreibt den Bruttobetrag abzüglich der Gebühr gut, und ein Burn gibt amount − fee auf der Quell-Chain frei. Eine Rotation der PQ-Guardians oder des Pause-Schlüssels trägt die eigene Signatur jedes neuen Schlüssels und wird 86.400 s nach ihrer Annahme wirksam (bridge.rotation) |
| Historie | 24 Validatoren halten 24 Stunden an Blöcken vor (--prune-history 24h) und antworten darunter mit -32010; zwei Archiv-Nodes halten jeden Block vor, und der öffentliche RPC https://rpc.randprotocol.org leitet an ein Archiv weiter |
| Block-Aggregation | aus (kein Abschnitt aggregation im Genesis; der Build verweigert den Start mit einem Genesis, das einen enthält) |
| Genesis-Wert | 26.000 RAND, gestakt im Validator-Register, plus sieben Einzahlungs-Notes mit insgesamt 5.184,243719258 RAND, übernommen aus den Wallets des Betreibers auf Chain 19: 31.184,243719258 RAND, vor Faucet-Mints (rand_getSupply meldet genesis_staked und genesis_deposited); dazu zwei Genesis-Notes mit insgesamt 99 zUSD, die den 99 zUSD entsprechen, die auf ihren Backings gesperrt sind |
Die Bootstrap-Nodes (deploy/nodes.env):
/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/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQChain 20 läuft auf den Validator-Schlüsseln, die die Chains 14 bis 19 verwendet haben; diese Peer-IDs haben sich daher seit der Schlüsselrotation von Chain 14 nicht geändert.
Der Explorer unter randscan.org indiziert Chain 20 und stellt eine REST-API unter https://randscan.org/api/v1 bereit (Explorer-API). Das JSON-RPC des Fullnodes bindet standardmäßig an 127.0.0.1:8545; betreiben Sie einen Node (Einen Node betreiben), nutzen Sie einen, dem Sie vertrauen, oder verwenden Sie den öffentlichen Endpunkt https://rpc.randprotocol.org (rand --rpc https://rpc.randprotocol.org …). Der öffentliche Endpunkt bedient alles, was eine Wallet braucht, einschließlich ihrer ersten Synchronisierung und des Sendens von Transaktionen, unter einem Limit von 1.200 Lesezugriffen und 6 Sendevorgängen pro Minute und Adresse. Den Faucet bedient er nicht.
RAND vom Faucet beziehen
Der Faucet ist ein Transaktionstyp: Ein Validator prägt eine Note mit öffentlichem Betrag an eine abgeschirmte Adresse, und die Note kann nur vom Inhaber der Adresse geöffnet werden. Auf Chain 20 zahlt er nur an die 16 Adressen auf der Genesis-Allowlist: Ein Mint an jede andere Adresse wird mit the faucet may not mint to this recipient (not in staking.faucet_recipients) abgelehnt; eine Wallet, die nicht darauf steht, erhält Test-RAND also, indem ihr welche gesendet werden. Jeder der drei folgenden Wege bittet einen Validator-Node um einen Mint; Observer antworten mit faucet mints are signed by validators; ask a validator node, und der öffentliche RPC-Endpunkt leitet rand_mint überhaupt nicht weiter.
Mit der rand-Wallet, ausgerichtet auf den RPC eines Validators:
rand keygen # writes wallet.key.json; refuses to overwrite
rand address # the rand1… address on stdout (about 1,665 characters), its fingerprint on stderr
rand faucet # an allowlisted wallet: 100 RAND into a note only it can open
rand balance # scans the tree with this key; prints 100 RANDrand faucet [ADDRESS] --amount <RAND> prägt an eine andere Adresse oder einen kleineren Betrag; 100 RAND sind zugleich der Standardwert und die Obergrenze pro Aufruf. Über JSON-RPC lautet dieselbe Anfrage rand_mint:
curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"rand_mint","params":["rand1…", "100000000000"]}'Das Ergebnis ist der Hash der Mint-Transaktion; fragen Sie rand_getTransaction so lange ab, bis es einen Block zurückgibt. Beträge sind Strings in Einheiten, und 1 RAND entspricht 10⁹ Einheiten. Die Wallet-Apps haben denselben Faucet als einen Fingertipp; senden Sie aus ihnen mit Rand Wallet v0.6.8 oder neuer, dem ersten Release für Chain 20. Die Faucet-Seite dieser Website nimmt Wartelisten-Anfragen für Devnet-Zuteilungen entgegen.
Der Betrag eines Mints ist on-chain öffentlich: die Ein-Schritt-Sichtbarkeit, die jede Einzahlung von transparent zu abgeschirmt hat. Was die Note danach für wen wert ist, bleibt verborgen wie bei jeder anderen Note.
Wie es weitergeht
- Konten und Adressen: die zwei Arten von Schlüsseln, was eine
rand1…-Adresse ist und warum die 54 Zeichen lange Adresse von Chain 11 zurückgenommen wurde. - Notes und der Commitment-Baum, Transaktionen und Actions, Gebühren, Konsens und Finalität, Supply: das Modell.
- Kryptografie und Beweise: die Primitive, die STARK-Parameter, wie ein Bundle bewiesen und verifiziert wird.
- Token und Einen RPL-Token deployen: der RPL-Standard, ein Token als Registry-Eintrag mit einer
rpl1…-ID und seine Erstellung aus dem Wallet. - Programme: ein vertrauliches Programm deployen und aufrufen, und was noch nicht möglich ist.
- Bridge, Mint und Burn, Staking, Einen Node betreiben.
- Ein Programm in Rust oder C schreiben: der vollständige Leitfaden, vom Entwurf der Ein- und Ausgaben eines Programms bis zu einer Auktion mit verdeckten Geboten, in beiden Sprachen geschrieben, dem Proving-Budget, dem Deployen und der Prüfung eines Aufrufs.
- Vier Beispielprogramme: vollständige Anwendungen, jede auf dem testnet ausgeführt: eine anonyme Abstimmung über eine Keccak-Allowlist, ein Nachweis der Verbindlichkeiten über einen SHA-256-Summenbaum, ein Off-Chain-Ledger, dessen Zustand von Aufruf zu Aufruf weitergereicht wird, und eine private Kreditentscheidung auf Grundlage eines veröffentlichten Modells.
- Die RISC-V ISA, Ein Rust-Programm deployen, Ein RISC-V-Programm deployen: eigene Programme mit der
rand-guest-Toolchain erstellen und deployen. - Der Solana-Transpiler und Der Ethereum-Transpiler: SPL Token und ein ERC-20, nach RISC-V übersetzt und Wort für Wort mit den Interpretern abgeglichen.
- Einen Validator und einen Aggregator betreiben: RAM, CPU und Datenträger für jede Rolle sowie die gemessenen Obergrenzen des Proving-Speichers.
- Entwickler: die Repositories, der Stack, die Meilensteine der zkVM, was spezifiziert, aber nicht ausgeliefert ist, und wie man baut, testet und beiträgt.
- JSON-RPC, Kommandozeile, Explorer API: die Referenzen.
Das eigene Verzeichnis docs/ des Fullnode-Repositorys ist die Quelle, gegen die diese Seiten geprüft werden, und die Papers liefern den kryptografischen Hintergrund.