Verwenden Sie diese Seite, um den passenden Schlüssel für die jeweilige Aufgabe zu erzeugen, eine Adresse zu parsen oder zu validieren und zu wissen, was die Weitergabe eines Schlüssels offenlegt. Auf dieser Chain gibt es keine Konten: Ein Guthaben ist eine Tatsache über eine Schlüsseldatei, niemals über die Chain.
Zwei Schlüssel, zwei Adressarten
| Node-Schlüssel | Wallet-Schlüssel | |
|---|---|---|
| geschrieben von | rand-node keygen | rand keygen |
| Geheimnis | ein 32-Byte-Seed | ein 256-Bit-Spend-Key |
| öffentliche Identität | eine 32-Byte-Adresse, base58, 32 bis 44 Zeichen | eine shielded Adresse, rand1…, 1.665 oder 1.666 Zeichen |
| signiert | Blöcke, Stimmen, Faucet-Mints, Unbond, Withdraw, eine Registration und auf Chain 20 eine AdmitValidator-Stimme; als Key-Mint-Autorität eines Tokens TokenMint und SetAuthority. Auf Chain 20 deckt jede dieser Nachrichten zusätzlich den Genesis-Hash ab (Transactions) | nichts: Ein Transfer wird durch seine Beweise autorisiert |
| erscheint on-chain als | Block-Proposer, Zeile im Validator-Register, Minter eines Faucet-Mints, key-Autorität eines Tokens | nie in einem Transfer, wo sie in Envelopes versiegelt ist. Sie wird dort veröffentlicht, wo Wert mit öffentlichem Betrag in den Pool gelangt: Eine Bridge-Einzahlung, ein Token-Mint und auf Chain 20 die Auszahlung eines Invoke nennen die Adresse des Empfängers; die Auszahlungsadresse eines Validators steht im Register, das Genesis von Chain 20 nennt die Gebührenkasse der Bridge, und seit Chain 14 veröffentlichen ein Faucet-Mint und eine Genesis-alloc-Note den pk des Eigentümers, die ersten 32 Bytes der Adresse |
| Datei | { "seed", "address", "public_key" }, Modus 0600 | { "version": 2, "spend_key": "<64 hex>" }, Modus 0600 |
Die beiden vermischen sich nie. Validatoren werden durch die erste Art identifiziert, und dieselbe Dilithium2-Schlüsselform dient als Key-Mint-Autorität eines Tokens (rand token create --authority-key-out schreibt eine Datei in der Form von rand-node keygen), als Pause-Schlüssel der Bridge und als ihre sechs post-quantensicheren Guardian-Schlüssel. Die Attestierungsschlüssel der Guardians sind secp256k1 mit Ethereum-artigen 20-Byte-Adressen (Bridge). Wert wird unter der zweiten Art gehalten.
Die transparente Adresse
Ein Node-Schlüssel ist ein 32-Byte-Seed, aus dem deterministisch ein Dilithium2-Schlüsselpaar abgeleitet wird: ein 1.312 Byte großer öffentlicher Schlüssel und 2.420 Byte große Signaturen. Die Adresse ist ein domänengetrennter BLAKE3-Hash des öffentlichen Schlüssels, dargestellt in base58:
address = blake3("rand-address" || public_key) // 32 bytes, shown as base58Signierte Objekte (Stimmen, Blöcke, Mints, Staking-Aktionen) tragen den vollständigen öffentlichen Schlüssel, sodass ein Verifier blake3("rand-address" || public_key) == address prüft, statt einer bloßen Adresse zu vertrauen. Derselbe Seed liefert auch die libp2p-Identität des Nodes, einen ed25519-Schlüssel aus blake3("rand-p2p-identity" || seed), der die Peer-ID nach /p2p/ in einer Bootstrap-Multiaddr ist.
rand-node keygen --out node.key.json # prints the address
rand-node address --key node.key.json # address, public key (hex), libp2p peer idBeispiel: EdrEC2QRQrQF64iRXxF9927jNj6RidiHHByzx5xD6F1e ist einer der Validatoren von Chain 20. Die Chains 15 bis 20 verwenden die achtzehn für Chain 14 rotierten Schlüssel weiter, ihre Adressen und Peer-IDs sind also unverändert, und keine Validator-Adresse und keine Peer-ID von Chain 13 ist mehr in Gebrauch; auf Chain 15 sind acht weitere Validatoren hinzugekommen, und ab Chain 16 stehen alle 26 in der Genesis-Datei.
Die shielded Adresse
Ein Wallet besteht aus einem einzigen Geheimnis, dem 256-Bit-Spend-Key sk, und alles andere ist eine Ableitung davon. Die Ableitung ist Poseidon2 mit einem Domain-Tag als erstem absorbierten Wort (H(domain, msg)), dieselbe Funktion, die die zkVM im Circuit berechnet:
spend key sk 256 bits, in wallet.key.json
│
├─ viewing key nk = H(NK, sk) sees the whole history; cannot spend
│ ├─ pk = H(PK, nk) the field a note names its owner by
│ ├─ nullifier(cm) = H(NF, nk, cm) what a spend publishes
│ ├─ ovk opens envelopes this wallet sent
│ └─ ML-KEM-768 decapsulation key opens envelopes sent to this wallet
└─ address rand1 + base58(pk || kem_ek)Die Adresse besteht aus den 32 Bytes von pk, gefolgt vom 1.184 Byte großen ML-KEM-768-Encapsulation-Key, in base58 nach dem Präfix rand1: 1.665 oder 1.666 Zeichen (die base58-Länge hängt von den führenden Bytes ab; etwa jede vierzehnte Adresse ist die kürzere), rund 1,6 KB, und keine Prüfsumme. Ein Sender benötigt den Encapsulation-Key, um den Note-Envelope zu versiegeln, weshalb er in der Adresse steht. Er ist bewusst öffentlich: Jeder darf an sie zahlen, und ihr Besitz sagt nichts darüber aus, was sie hält.
rand keygen # wallet.key.json; refuses to overwrite an existing file
rand address # rand1… on stdout, its fingerprint XXXX-XXXX-XXXX-XXXX on stderrSeit v0.5.10 gibt rand address auf stdout genau die Adresse und einen Zeilenumbruch aus, sodass $(rand address) in einem Skript funktioniert. Der Fingerprint geht an stderr.
Geparst wird genau so, wie ShieldedAddress::parse es tut: rand1 entfernen, base58 dekodieren und genau 32 + 1.184 = 1.216 Bytes verlangen; die ersten 32 sind pk als acht Little-Endian-u32-Wörter, der Rest ist der Encapsulation-Key. Der RPC weist jeden Parameter mit mehr als 2.000 Zeichen ab, bevor er ihn parst.
Neben der Schlüsseldatei führt das Wallet <key>.key.json.notes.json, einen Cache der Notes, die dieser Schlüssel geöffnet hat. Er enthält Note-Klartexte und wird daher wie der Schlüssel mit Modus 0600 geschrieben; jede Zeile darin lässt sich durch erneutes Scannen ab Leaf 0 wiederherstellen.
Eine Adresse teilen: der Fingerprint und randpay:-Links
Eine Adresse ist zu lang, um sie vorzulesen oder mit bloßem Auge zu vergleichen, und trägt keine Prüfsumme; deshalb zeigt seit v0.5.10 jedes Wallet neben ihr einen Fingerprint an. Der Fingerprint dient nur der Anzeige: Nichts on-chain und nichts auf der Leitung trägt einen.
fingerprint = first 80 bits of blake3("rand-address-fingerprint-1" || pk_bytes || kem_ek)
= 16 Crockford base32 characters, shown as XXXX-XXXX-XXXX-XXXXDer Hash läuft über die 1.216 Rohbytes, die die Adresse kodiert. Das Alphabet ist 0123456789ABCDEFGHJKMNPQRSTVWXYZ; beim Parsen werden Groß- und Kleinschreibung sowie Bindestriche ignoriert, O wird als 0 und I oder L als 1 gelesen.
Ein randpay:-Link trägt eine Adresse und optional, was an sie zu zahlen ist:
randpay:<rand1…>[?amount=<decimal>][&asset=<index | 64 hex | rpl1…>][&memo=<percent-encoded UTF-8>]amount steht in den Anzeigeeinheiten des Assets (dezimales RAND mit neun Nachkommastellen, ein Token mit den eigenen decimals seiner Registerzeile) und darf nicht null sein. memo umfasst höchstens 510 Bytes UTF-8. Das Schema wird ohne Rücksicht auf Groß- und Kleinschreibung erkannt; ein unbekannter Parameter, ein wiederholter oder eine fehlerhafte Prozentkodierung wird abgewiesen.
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" # to a contact, with a memorand send <TO> akzeptiert eine rand1…-Adresse, einen randpay:-Link oder den Namen eines gespeicherten Kontakts, in dieser Reihenfolge geprüft. amount, asset und memo eines Links ergänzen, was die Befehlszeile offenlässt; ein auf beiden Wegen angegebener, aber abweichender Wert wird abgewiesen. Vor dem Beweisen gibt send to <contact, if any> · fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <asset> aus und fragt nach; ein Skript übergibt --yes. Kontakte werden neben dem Schlüssel unter <key>.contacts.json mit Modus 0600 gespeichert. Das Memo reist im Note-Envelope mit (Notes).
Es gibt kein rand balance <address> und keinen Balance-RPC: Die Chain kann das für niemanden beantworten. Ein Wallet berechnet sein Guthaben, indem es mit seinem Viewing-Key jeden Envelope der Chain scannt (Notes).
Schlüssel, die Sie an andere weitergeben können
Offenlegung ist eine Eigenschaft von Schlüsseln, und die Chain kann nichts davon erzwingen.
| Schlüssel | öffnet | Granularität |
|---|---|---|
der Viewing-Key nk (64 hex) | jede Note, die das Wallet je empfangen hat, und über ovk jede Note, die es je gesendet hat, mit dem Nullifier jeder Ausgabe | alles oder nichts, rückwirkend und zukunftsgerichtet |
ein Transaktionsschlüssel TxKey (32 Bytes) | genau den einen Envelope, den er versiegelt hat: die Note und seit Chain 18 ihr Memo | eine Zahlung |
ein Call-Key K_call | das Transkript der privaten Eingaben eines vertraulichen Calls | ein Call |
Ein Viewing-Key kann nichts ausgeben. Seit Chain 17 (geteilte Autorisierung) wird der Bundle-Beweis selbst aus nk erzeugt, und jedes Bundle trägt außerdem einen zweiten, kleinen Auth-Beweis, den nur der Spend-Key erzeugen kann und der an die eine Transaktion gebunden ist (Notes). Dadurch kann einem delegierten Prover nk und damit die gesamte Historie des Wallets übergeben werden, ohne dass er ausgeben kann; das Wallet erzeugt den Auth-Beweis stets auf der eigenen Maschine. Adressen, Schlüssel und bestehende Notes bleiben von der Teilung unberührt. Das Wallet leitet nk bei jedem Lauf neu ab und speichert es nie; jeder TxKey wird pro Envelope frisch gezogen und nach dem Versiegeln verworfen. Einem Node kann mit rand_importViewingKey ein Viewing-Key übergeben werden (im Speicher, höchstens 64 pro Node, nach einem Neustart verschwunden), damit er im Auftrag des Inhabers scannt, so arbeitet der Explorer, und rand_checkTransaction(hash, key) prüft in einem zustandslosen Aufruf eine Zahlung gegen einen TxKey. rand viewing-key gibt nk aus, und rand tx-key <hash> gibt den Schlüssel jeder Ausgabe einer Transaktion aus, die dieses Wallet öffnen kann.
Token-IDs sind keine Adressen
Ein RPL-Token hat eine dritte Art von Text-Identifier, und sie benennt einen Token, niemals einen Inhaber. Die 32-Byte-Asset-ID des Tokens wird als 64 Hex-Zeichen und als rpl1… angezeigt: bech32m (BIP-350) mit dem Human-Readable-Part rpl über die 32 ID-Bytes, 52 Datenzeichen plus eine 6 Zeichen lange Prüfsumme, 62 Zeichen. Das Parsen ist streng: Eine falsche Prüfsumme, ein anderer Human-Readable-Part, eine Nutzlast, die nicht genau 32 Bytes umfasst, oder gemischte Groß- und Kleinschreibung wird abgewiesen, sodass ein Tippfehler nie zu einem anderen Token aufgelöst wird. Eine Note trägt die ID nicht; ihr asset-Wort ist der dichte Registerindex des Tokens (RPL tokens).
Der Bridge-Empfänger
Das Wire-Format der Bridge hat einen 32-Byte-Empfängerslot, und eine shielded Adresse passt nicht hinein. Heute trägt der Slot einen Hash der Adresse:
recipient_hash = blake3("rand-shielded-recipient" || pk_bytes || kem_ek)Der Einzahler auf der Quell-Chain nennt den Hash, die Guardians signieren ihn, und die BridgeAttest-Transaktion trägt die vollständige Adresse, damit das Ledger sie dagegen prüfen kann (Bridge).
Die kurze shielded Adresse: auf Chain 11 erprobt, zurückgenommen
Chain 11 (Fullnode-Tag v0.2, 2026-09-17) ersetzte die lange Adresse durch eine 53 bis 55 Zeichen lange Receiver-ID, rand1 + base58(blake3(receiver signing key) ‖ checksum), und verlagerte den ML-KEM-Encapsulation-Key in einen signierten Receiver-Record, den ein Sender aus dem Registry des Explorers abrief oder inline in einer Zahlungsanforderung erhielt. Sie lief einen Tag lang und wurde am selben Tag zurückgenommen (Fullnode 17db41d); Chain 12 kehrte zur langen Adresse zurück, genau wie oben beschrieben, und jede Chain seitdem, Chain 20 eingeschlossen, behält sie bei.
Warum sie wieder entfernt wurde. Eine Receiver-ID ist ein Hash, und ein Sender kann keine Note an einen Hash versiegeln. Die erste Zahlung an ein Wallet, das sich nie registriert hatte, setzte voraus, dass der Empfänger eine Zahlungsanforderung oder eine Record-Datei übergibt, und die Registrierung selbst wurde mit einer Selbstüberweisung bezahlt, die ein neues, leeres Wallet nicht ausführen kann. Beide Übermittlungswege teilten dem Registry zudem mit, wer demnächst bezahlt werden würde. Das Design, das eine kurze Adresse, bedingungslose Sendefähigkeit und kryptografische Privatsphäre vereint, ist eine Hybridadresse: ein 32-Byte-X25519-Schlüssel inline (etwa 93 Zeichen), der Post-Quanten-Schlüssel per Abruf, wobei die erste Zahlung an ein nicht registriertes Wallet gegenüber klassischen Angreifern vertraulich ist und jede spätere vollständig post-quantensicher. Das wird als Nächstes spezifiziert; bis es erscheint, ist die lange Adresse die Adresse.
Die Spezifikation von Chain 11 und ihre Implementierung bleiben in der Fullnode-Historie (docs/superpowers/specs/2026-09-17-short-shielded-address.md, Tag v0.2), für die Teile, die das Hybriddesign wiederverwendet: den abgeleiteten Receiver-Signing-Key, den signierten Record samt seinem Verifier und das Registry als Chain-Zustand.