Befehlszeile

Drei Binärdateien entstehen mit cargo build --release: rand-node (der Node und die Operator-Befehle), rand (die abgeschirmte Wallet) und rand-prover (der delegierte Prover). Jeder Befehl akzeptiert -h/--help. Diese Seite beschreibt das Release v0.6.8 (c9c9bd3c), den Build, den chain 20 betreibt; wo sich v0.6.7 anders verhielt, wird das vermerkt. Eine rand-Wallet, die älter ist als v0.6.8, kann auf chain 20 nicht senden, deren Genesis jeden Beweis und jede signierte Nachricht an ihren Hash bindet. Die ersten beiden halten unterschiedliche Arten von Schlüsseln: Ein Node-Schlüssel ist ein Dilithium2-Schlüsselpaar, das Blöcke signiert; ein Wallet-Schlüssel ist ein abgeschirmter Spend-Schlüssel, der on-chain nichts signiert.

rand-node

rand-node <COMMAND>
  keygen      Generate a new Dilithium2 key file (refuses to overwrite an existing one)
  address     Print the address, public key, and libp2p peer id of a key file
  genesis     Write a genesis.json: every validator key is staked, each --alloc becomes a deposit note
  alloc-note  Print one genesis alloc note as JSON, RAND or a listed token, for splicing into a genesis
  init        Initialise a data directory from a genesis file
  run         Run the node
  verify      Verify the chain in a data directory without running the node
  db          Database maintenance on a stopped node's data directory
  safety      status | clear-halt | release-lock: a stopped validator's consensus safety state
  status      Show node status
  register    Print this node's Registration, for the wallet that bonds it in
  admit       sign | submit: the validator set's vote to admit a new key (admission by vote)
  unbond      Move bonded stake into unbonding
  withdraw    Pay released stake and rewards into a note at the payout address
  bridge-gov  rotate-pq | rotate-pause | cancel-rotation: the bridge's post-quantum rotations
  vesting     status | claim | revoke | bond | unbond: genesis vesting (chains with a vesting section)
  aggregator  register | unbond | withdraw — the aggregator role (aggregation chains only)
  aggregate   The aggregate daemon (aggregation chains only)

safety, admit und bridge-gov sind neu in v0.6.8. Es gibt weder balance noch transfer: Ein Transfer braucht einen abgeschirmten Spend-Schlüssel, und den hält nur die Wallet.

Ein globales Flag, --allow-test-fri-profile (oder RAND_ALLOW_TEST_FRI_PROFILE=1), lässt init, run und verify ein Genesis akzeptieren, dessen fri_profile test ist. Dieses Profil bietet etwa 17 Bit Soundness, und wer eine Genesis-Datei schreibt, kann es benennen; deshalb lehnt ein Node ein solches Genesis seit v0.6.8 ohne das Flag ab. Die Test-Suites setzen es; sonst sollte es nichts setzen.

keygen, address

keygen schreibt { "seed": <32-byte hex>, "address": <base58>, "public_key": <hex> } mit Modus 0600. Die Datei ist die einzige Kopie des Seeds. Seit v0.6.8 verweigert keygen ein --out, das bereits existiert (… already exists or cannot be created; refusing to overwrite a key file), und lässt es unverändert; es gibt kein --force, eine alte Datei muss also beiseitegelegt werden, um sie zu ersetzen. v0.6.7 und früher überschrieben sie ohne Nachfrage. address gibt address, public_key (1.312 Bytes hex) und peer_id aus.

genesis

Gibt eine alloc-Zeile pro --alloc aus, dann den Genesis-Hash, die Anzahl der Validatoren und Notes, die Epochenlänge, die fünf Limits, hc_bundle und hc_auth (none ohne --auth-guest), dann die Gas-Zeile: gas: price P/gas, B/KiB, bundle limit N, dynamic: target … B / … gas, adjust … bps, floor …/…, ceiling …/…, byte load all|paying, oder gas: none ohne --gas-price, und mit --program-state-cell-fee eine Zeile program_state: cell fee N RAND. init gibt dieselbe Gas-Zeile aus. Die fünf Limit-Flags verhalten sich gleich: Fehlen sie, hat die Datei kein solches Feld und die Chain läuft mit dem Standardwert; sind sie angegeben, ist das Feld Teil des Genesis-Hashes, auch bei seinem Standardwert. Chain 20 wurde mit diesen Flags erzeugt (deploy/cut-chain20-genesis.sh):

--max-program-words 65535 --max-proof-bytes 4194304 --max-block-bytes 20971520 \
--max-call-envelope-bytes 65536 --max-program-public-words 32768 \
--tokens tokens.json \
--bundle-guest v3 --auth-guest --hardening-v6 \
--gas-price 100 --byte-price 800 --bundle-gas-limit 20479 --gas-dynamic 10485760,262144,1250 \
--max-gas-price 10000 --max-byte-price 80000 --gas-byte-load paying \
--envelope-bytes 1860 \
--testnet --binding-domain 1 --proof-window-blocks 1024 --program-state-cell-fee 10000000 \
--epoch-blocks 1000 --faucet --fri-profile production

Die Ketten 18 und 19 wurden mit denselben Flags geschnitten, bis auf --envelope-bytes 1860 und keines der Flags aus v0.6.8. Die Proof-Obergrenze beträgt 4 MiB, gegenüber 8 MiB bei den Ketten 13 bis 16: Eine Transaktion mit geteilter Autorisierung trägt bis zu drei Proofs, und 3 × 4 MiB + 1 MiB passen in den Block von 20 MiB. tokens.json enthält eine registration_fee von 1 RAND, ein mint_cap_per_day von 10000000000000, max_tokens 4096, burn_registration_fee und bound_note_value sowie zUSD, aufgeführt mit seinen sieben Deckungen. Es gibt kein Flag --bridge, und das Cut-Skript fügt die Abschnitte bridge, staking und consensus_domain anschließend weiterhin in die Datei ein (auf Chain 20: die Bridge mit Guardian-Set 1 und acht PQ-Guardian-Schlüsseln, der Pause-Schlüssel, rules_v2, rotation und fees; der Abschnitt staking mit der Faucet-Allowlist, admission_by_vote und einem Eintrittsbudget von 2.500 bps; consensus_domain: 1; sowie die Genesis-Notes von zUSD, erstellt mit alloc-note --asset 1 --envelope-bytes 1860). Maßgeblich ist der Genesis-Hash, den init für die fertige Datei ausgibt.

Jedes --alloc erzeugt eine Einzahlungs-Note mit frischer Commitment-Zufälligkeit, sodass zweimaliges Schneiden zwei verschiedene Hashes ergibt. Der Befehl schreibt die Öffnung der Note stets neben cm und amount, was eine Chain mit einem Abschnitt tokens voraussetzt:

"alloc": [
  { "cm": "<64 hex>",
    "envelope": { "kem_ct": "<hex>", "to_receiver": "<hex>", "to_sender": "<hex>", "body": "<hex>" },
    "amount": 1000000000000,
    "opening": { "pk": "<64 hex>", "time": 0, "r": "<64 hex>" } }
]

Eigentümer und Betrag einer Genesis-Note sind daher mit der Veröffentlichung der Datei bewusst öffentlich; privat bleibt nur, wann und wofür sie später ausgegeben wird. Schneiden Sie ein Genesis einmal und bewahren Sie die Datei auf.

alloc-note

--to <rand1…> (erforderlich), --amount <N> (erforderlich), --asset <INDEX> (Standard 0), --envelope-bytes <N> (Standard: das Legacy-Format). Gibt eine Alloc-Note als JSON aus, versiegelt an --to, wie genesis --alloc sie versiegelt. Ein Genesis, das envelope_bytes setzt, weist eine Note ab, die ohne das passende --envelope-bytes versiegelt wurde. --amount gilt in ganzen Einheiten des Assets: neun Dezimalstellen für RAND, acht für ein gebridgtes Token (10 bei Asset 1 sind 10 zUSD). Eine Note eines gelisteten Tokens setzt voraus, dass die Deckungen dieses Tokens locked-Beträge tragen, die sich genau zu seinen Notes summieren.

init

Gibt den Genesis-Hash und dieselbe gas:-Zeile wie genesis aus.

run

Umgebung: RUST_LOG (Standard info,libp2p=warn,libp2p_mdns=off). Strg+C oder SIGTERM fährt den Node sauber herunter.

Der öffentliche Endpunkt https://rpc.randprotocol.org ist ein Allowlist-Proxy vor einem Archiv-Node; seit 2026-10-01 ist seine Allowlist der Methodensatz des öffentlichen Listeners.

safety

Der Konsens-Sicherheitszustand eines gestoppten Validators (v0.6.8). Jeder Befehl öffnet das Datenverzeichnis selbst, daher läuft keiner neben einem aktiven Node.

rand-node safety status       --datadir <dir>
rand-node safety clear-halt   --datadir <dir> --i-have-compared-this-node-with-the-fleet
rand-node safety release-lock --datadir <dir> --i-give-up-this-validators-lock

status gibt den committeten Head, den View und den zuletzt gewählten View, den High QC, ob der Validator oberhalb seines Heads gesperrt ist, und einen etwaigen aufgezeichneten Safety-Halt aus. Ein Node, der sieht, dass eine zertifizierte Three-Chain versucht, einen Block zu committen, der nicht von seinem eigenen committeten Head abstammt, hält an und zeichnet das auf (Audit v6, CON-5); run endet dann mit diesem Eintrag, bis clear-halt ausgeführt wird. Vergleichen Sie den Head dieses Nodes mit dem zweier anderer Validatoren und synchronisieren Sie von einem Archiv neu, falls er abweicht, bevor Sie den Halt löschen. Seit v0.6.8 (CON-4) löst kein Quorum von „nicht gehalten“-Antworten eine Sperre mehr: Ein Validator, der auf einen Block gesperrt ist, den er nicht beschaffen kann, bleibt stumm, bis ein Vorschlag eintrifft, dessen Justify die Sperre übertrifft, oder der Block abgerufen wird. release-lock senkt die gespeicherte Sperre auf das Zertifikat des committeten Heads; verwenden Sie es jeweils bei einem Validator und nur, wenn der Block endgültig verloren ist. Ohne sein Bestätigungs-Flag gibt jeder schreibende Befehl aus, was er tun würde, und ändert nichts.

verify

Exitcode 0, wenn konsistent, 2, wenn ohne --repair ein Problem gefunden wurde.

db

db drop-receipts-index --datadir <DATADIR>, bei gestopptem Node: den Index receipts_by_program löschen, bevor auf einen Build vor v0.3 zurückgegangen wird, der eine Datenbank mit diesem Index nicht öffnen kann. Ein späterer Start baut den Index aus den Receipts neu auf.

status

--rpc <URL> (Standard http://127.0.0.1:8545). Gibt rand_status unverändert aus.

register, unbond, withdraw

admit sign|submit

Zulassung per Abstimmung (v0.6.8). Auf einer Chain, deren Genesis staking.admission_by_vote setzt, wie bei Chain 20, wird ein neuer Validator-Schlüssel erst registriert, nachdem Validatoren, die strikt mehr als zwei Drittel des Stimmgewichts halten, ihn per Signatur zugelassen haben.

Der Kandidat ist der Schlüssel, den die Registrierung tragen wird; rand-node address --key gibt ihn aus, und das von register ausgegebene Hex enthält ihn. Nachdem die Zulassung bestätigt ist, verläuft das Bonding wie bisher (rand bond … --registration) und verbraucht sie. rand_getAdmitted listet auf, was zugelassen ist und wartet.

bridge-gov

Die postquantensicheren Rotationen der Bridge (v0.6.8), für Guardians und den Inhaber des Pause-Schlüssels. Jeder Schritt liest die Chain-ID, ihre Bindungsdomäne und rand_getBridgeState.rotation_nonce von --rpc (Standard http://127.0.0.1:8545).

--new-key ist ein hexadezimaler öffentlicher Dilithium2-Schlüssel, @file mit einem solchen Schlüssel oder @key-file (dessen öffentlicher Schlüssel). Signaturzeilen haben die Form index:hex, getrennt durch Leerraum oder Zeilenumbrüche; #-Kommentare sind erlaubt.

vesting status|claim|revoke|bond|unbond

Die Seite des Inhabers und des Widerrufenden bei einer zeitgesperrten Genesis-Zuteilung, auf einer Chain, deren Genesis einen vesting-Abschnitt enthält. Der von Chain 20 hat keinen. Der Schlüssel ist eine rand-node keygen-Datei.

aggregator register|unbond|withdraw, aggregate

Die Befehle der Aggregator-Rolle für eine Chain mit einem aggregation-Abschnitt: aggregator register --key --bond <RAND> --payout <rand1…> --rpc gibt eine signierte AggregatorRegistration aus; aggregator unbond und aggregator withdraw entsprechen dem Validator-Paar. aggregate --key <KEY> [--rpc <URL>] [--watch] [--interval-secs 15] [--no-wait] ist der Daemon, der rand_getUnsealed abfragt, ein Aggregat beweist und einreicht. Wirkungslos auf Chain 20, deren Genesis keinen aggregation-Abschnitt hat.

rand (Wallet)

Globale Optionen, vor oder nach dem Unterbefehl:

Beträge sind dezimale RAND mit bis zu neun Nachkommastellen (1, 1.5, .25, 0.000000001). Ein Token-Betrag bei send, token mint und token burn sowie in einem randpay:-Link steht in den Anzeigeeinheiten des Tokens, mit den eigenen decimals seiner Registerzeile (10 zUSD sind 10 zUSD). bridge-burn, token create --fixed-supply und --initial nehmen einfache Ganzzahlen in der kleinsten Einheit des Tokens, und asset-balance gibt sie so aus. Wo immer ein Befehl einen Token entgegennimmt, akzeptiert er den Registerindex, die rpl1…-ID oder die 64-stellige Hex-ID; eine ID wird anhand der gesamten Registerliste des Knotens (rand_getTokens, jede Seite) in ihren Index aufgelöst, nie durch eine Abfrage pro Token, die dem Knoten verraten würde, welcher Token gleich bewegt wird. Ein numerischer Index erreicht den Knoten überhaupt nicht.

--cuda setzt einen Build mit --features cuda voraus und hat keinen Fallback; bisher wurde kein PTX gebaut. Es kann keinen Call-Input-Envelope versiegeln: rand call --cuda braucht --no-envelope. Es deklariert nur die Gas-Obergrenze und lehnt --gas-limit N ab.

Jedes Memo und jeder Kontaktname, den die CLI ausgibt (die Bestätigung von send, notes, history, tx-key), durchläuft zuerst eine Anzeigeregel: Steuerzeichen, Unicode-Formatzeichen (Bidi-Steuerzeichen, Zeichen der Breite null, das weiche Trennzeichen) und U+2028/U+2029 werden als U+FFFD angezeigt, und eine Folge von Leerzeichen-Trennzeichen als ein einzelnes Leerzeichen.

Ein erster abgeschirmter Transfer

rand keygen                                   # wallet.key.json
rand address                                  # rand1… on stdout, its fingerprint XXXX-XXXX-XXXX-XXXX on stderr
rand faucet                                   # testnet, allowlisted wallets only: 100 RAND into a note only you can open
rand balance                                  # balance: 100 RAND
rand send rand1q9f… 1.5                       # asks to confirm, then a minute and a half to two minutes of local proving, then the commit
rand notes                                    # the spent note, and the change note

Eine Adresse teilen, und ein Memo

rand address --uri --amount 1.5 --memo "invoice #42" --qr   # a randpay: link, as a terminal QR
rand contacts add alice rand1q9f…                           # shows the fingerprint, asks add? [y/N]
rand send alice 1.5 --memo "coffee"                         # the memo is sealed into the payment output
rand history --memo                                         # alice's row shows the whole memo
rand tx-key <hash>                                          # hand the sent row's key to alice or an auditor

Das Memo liegt im selben versiegelten Body wie die Note; wer das eine öffnen kann, kann auch das andere öffnen: der Zahlungsempfänger über notes, und jeder, der den Per-Transaction-Schlüssel dieses Outputs besitzt, über rand_checkTransaction <hash> <key>. Chain 18 ist die erste Chain, deren Genesis envelope_bytes setzt; auf den Chains 14 bis 17 wurde --memo abgelehnt, bevor irgendetwas bewiesen wurde.

Ein vertraulicher Call, den Sie später wieder öffnen können

rand program build --guest balance_check --arg 1000 --out bc.json
rand program deploy bc.json                   # prints the program id
rand call <id> --input 100 --input 200 --input 300 --input 400
rand open-call <txhash>                       # inputs: [100, 200, 300, 400] — verdict: faithful (exit 0)

Ein zustandsbehaftetes Programm: der RPL-2-Zähler

Auf einer Chain mit einem Abschnitt program_state, wie es Chain 20 ist. Der Zähler akzeptiert genau die Übergänge, die eine Zelle lesen und sie mit ihrem ersten Wort plus eins zurückschreiben; alles Übrige am Übergang (was das Bundle einzahlt, was der Vault auszahlt, was das Programm mintet) läuft ungeprüft mit. Damit ist er eine Demonstration und kein Programm, hinter das man Werte legen sollte.

rand program build --guest rpl2_counter --out counter.json
rand program deploy counter.json                          # prints the program id
rand token create --name "Counter Share" --symbol CTR --decimals 0 --program <id>   # say index 2
rand program state <id> --cell 0100000000000000000000000000000000000000000000000000000000000000   # 64 zeros: absent
cat > step.json <<'JSON'
{ "reads":  [{ "key": "0100…00", "value": "0000…00" }],
  "writes": [{ "key": "0100…00", "value": "0100…00" }],
  "deposit": { "rand": "500000000", "kind": "none" },
  "pays":   [{ "asset": 0, "amount": "200000000", "to": "rand1…" }],
  "mints":  [{ "asset": 2, "amount": "1" }] }
JSON
rand program invoke <id> --transition step.json           # exit 3 if the cell moved since; re-read and retry
rand program vault <id>                                   # asset 0: 300000000 units (0.5 RAND in, 0.2 out)

Die … in der Datei stehen für die vollständigen 64 Hex-Zeichen, die das Wallet verlangt.

Was ein Deploy und ein Call ausgeben

Auf einer Chain mit getrennter Autorisierung besteht jedes Bundle aus zwei Proofs, die auf diesem Rechner erzeugt werden: die Tier-10-Spend-Autorisierung und das Tier-14-Bundle. Ein program deploy mit rand v0.6.7 auf Chain 18, 2026-09-30:

proving the spend authorisation on this machine (tier 10; seconds)…
authorisation proved in 6.8s: tier 10, 1368908 bytes
proving the bundle (tier 14; about a minute and a half on a laptop)…
proved in 116.7s: tier 14, 1500710 bytes
submitted deploy <hash>
  0 RAND out, 59.8545 RAND change, fee 0.1007 RAND, anchored at height 97831, proved in 116.7s (bundle) + 6.8s (auth)

Ein call gibt sein Gas und seine Gebühr vor dem Call-Proof aus und beweist dann das zahlende Bundle auf dieselbe Weise:

proving the call locally (90 inputs stay private, over the program's 11-word public input)…
gas: 5636 (declaring 6144, tier 12)
fee 0.006191437 RAND (incl. two price steps of headroom)
proved in 29.2s: tier 12, 3346865 bytes, outputs [...]

Hier ist 6,144 gleich 5,636, aufgerundet auf ein Vielfaches von 2^10, und rand fee call 12 --gas 6144 --bytes <B> bewertet dieses Limit zu den Preisen der Chain-Spitze ohne Spielraum.

rand-prover

Der delegierte Prover als eigenes Binary: Er erzeugt den Tier-14-Bundle-Proof eines Wallets auf einem anderen Rechner. rand-node run --prover betreibt denselben Dienst innerhalb eines Nodes. Jeder Unterbefehl akzeptiert --home <DIR> (env RAND_PROVER_HOME, Standard ~/.rand-prover), das Verzeichnis, das prover.key.json und pairings.json enthält.

Ein Prover auf Chain 20 erhält den Viewing Key nk des Wallets und ein frisches Salt. Er kann nichts ausgeben, aber er kann alles lesen, was dieses Wallet je empfangen oder gesendet hat: Koppeln Sie nur mit einem Prover, dem Sie Ihren Verlauf zeigen würden. Das Wallet prüft jeden Proof, den es zurückerhält.

Formate der Schlüsseldateien

Node-Schlüssel:

{ "seed": "hex of 32 bytes", "address": "base58 of blake3(\"rand-address\" || public key)", "public_key": "hex of 1312-byte Dilithium2 public key" }

Wallet-Schlüssel, Version 2:

{ "version": 2, "spend_key": "hex of 8 little-endian u32 words (64 characters)" }

rand keygen schreibt ihn mit Modus 0600, und seit v0.6.8 verweigert jeder rand-Befehl eine Wallet-Schlüsseldatei, die Gruppe oder andere lesen können: Ein von Hand kopierter oder wiederhergestellter Schlüssel muss auf 0600 zurückgesetzt werden (chmod 600 <key>). Geht ein Wallet-Schlüssel verloren, gehen alle Notes verloren, die er öffnen konnte; in diesem Release gibt es keine Wiederherstellungsphrase.