Der Quelltext endet mitten im Satz (”### 13. Why does one proof move any asset (RAND, zUSD, RPL tokens)?”), also übersetze ich ihn bis dorthin.
Diese Seite hält die Begründung für jede wesentliche Designentscheidung in Rand fest: die Eigenschaft, die eine Komponente liefern muss, die Annahme, unter der sie diese liefert, und die Kosten, die dafür in Kauf genommen werden. Sie wurde am 29. September 2026 aus dieser Website, der Zusammenfassung des Whitepapers und dem Referenz-Full-Node (github.com/randprotocol/fullnode: dessen README, docs/ und docs/superpowers/specs/) zusammengestellt. Jede Antwort nennt das Dokument, in dem die Begründung festgehalten ist; Pfade beziehen sich auf das fullnode-Repository, sofern sie nicht mit randprotocol.org beginnen.
Status. Rand läuft auf einem testnet, das vom Gründungsteam betrieben wird, und das Protokoll wurde nicht unabhängig geprüft. Mehrere der folgenden Entscheidungen werden schrittweise über mehrere Chain-Cuts hinweg umgesetzt. Alle Zahlen sind Messungen des laufenden Nodes zum Zeitpunkt der Zusammenstellung; sie werden sich voraussichtlich ändern und sollten vor einer Zitierung erneut gemessen werden.
Kryptografische Primitive
1. Warum ML-KEM-768 (Kyber) für die Verschlüsselung von Notes?
Der Klartext einer Note wird für den Empfänger in einem Umschlag verschlüsselt, der dauerhaft im öffentlichen Ledger verbleibt. Seine Vertraulichkeit ist daher eine unwiderrufliche Eigenschaft (Frage 8): Ein Angreifer, der zu einem beliebigen späteren Zeitpunkt über einen kryptografisch relevanten Quantencomputer verfügt, könnte jeden historischen Umschlag entschlüsseln, der unter einem KEM auf Basis elliptischer Kurven versiegelt wurde, da Shors Algorithmus den diskreten Logarithmus in polynomieller Zeit löst. ML-KEM ist in NIST FIPS 203 standardisiert, und seine Sicherheit lässt sich auf Module-LWE zurückführen, für das kein effizienter Quantenalgorithmus bekannt ist. Der Parametersatz 768 (NIST-Kategorie 3) wurde als Kompromiss zwischen Sicherheitsmarge und dem 1.184 Byte großen Kapselungsschlüssel gewählt, den jede Adresse enthalten muss. Der Umschlag besteht aus ML-KEM-768 in Kombination mit ChaCha20-Poly1305: 1.348 Byte, bzw. 1.860 Byte mit dem Memo-Feld fester Größe.
Quelle: randprotocol.org (Abschnitt Post-Quanten); fullnode README; docs/shielded.md §2
2. Warum Poseidon2-Commitments statt Pedersen?
Pedersen-Commitments sind perfekt verbergend, aber nur rechnerisch bindend, und ihre Bindung beruht auf der Annahme des diskreten Logarithmus, die ein Quantenangreifer bricht; ein Angreifer, der diskrete Logarithmen berechnen kann, kann ein Commitment zu einem anderen Wert öffnen. Da ein heute veröffentlichtes Commitment über die gesamte Lebensdauer des Ledgers korrekt und verbergend bleiben muss, muss das Verfahren auf Annahmen beruhen, von denen man glaubt, dass sie auch gegen Quantenangreifer gelten; in der Praxis bedeutet das eine Hashfunktion. Poseidon2 ist eine auf Arithmetisierung ausgelegte Hashfunktion über dem Goldilocks-Körper, sodass ihre Auswertung innerhalb des STARK nur wenige Constraints kostet. Dieselbe Hashfunktion instanziiert das Note-Commitment, den Merkle-Baum der Tiefe 32 und den Nullifier.
Quelle: randprotocol.org (Abschnitt Post-Quanten); docs/shielded.md §1–2
3. Warum zwei Hashfunktionen – BLAKE3 und Poseidon2?
Die beiden Funktionen sind für unterschiedliche Kostenmodelle optimiert. Poseidon2 wird überall dort verwendet, wo ein Hash innerhalb eines Beweises ausgewertet werden muss – Notes, Commitment-Baum, Nullifier und die internen Tabellen der zkVM –, weil seine Kosten in Constraints gemessen werden. BLAKE3 wird überall dort verwendet, wo kein Beweis beteiligt ist und der native Durchsatz überwiegt: Block-Hashes, die State Root über Baum, Nullifier-Menge, Validator-Register und Programmtabelle sowie Validator-Adressen (der BLAKE3-Digest des öffentlichen Schlüssels). Poseidon2 ist auf einer CPU vergleichsweise langsam; BLAKE3 ist vergleichsweise teuer zu arithmetisieren. Jede wird nur dort eingesetzt, wo ihr Kostenmodell greift.
Quelle: fullnode README (Zeile Signaturen / Hashes); docs/architecture.md
4. Warum Dilithium2 (ML-DSA) für Validator-Signaturen?
Konsenssignaturen liefern eine erneuerbare Eigenschaft (Frage 8): Ein späterer Bruch des Verfahrens erlaubt die Fälschung zukünftiger Nachrichten, macht aber bereits finalisierte Blöcke nicht rückwirkend ungültig, sodass das Verfahren grundsätzlich ersetzt werden könnte, bevor ein Quantenangreifer existiert. Dennoch wurde von Genesis an ein Gitterverfahren verwendet, damit Konsensstimmen, die Mitsignaturen der Bridge-Guardians und das Validator-Register einen einzigen Post-Quanten-Schlüsseltyp teilen. Der Node implementiert den Parametersatz Dilithium2 aus Runde 3 (das Crate crystals-dilithium), der sich vom finalen FIPS-204-ML-DSA-44 unterscheidet; öffentliche Schlüssel sind 1.312 Byte, Signaturen 2.420 Byte groß.
Quelle: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. Warum ein transparenter STARK (FRI über Goldilocks) statt eines SNARK?
Die Wahl folgt aus drei Anforderungen. Erstens: kein Trusted Setup. Die Soundness beruht allein auf der Kollisionsresistenz einer Hashfunktion, nicht auf einem strukturierten Referenzstring oder einer pairing-freundlichen Kurve. Zweitens: plausible Post-Quanten-Soundness. Das Argument trifft keine Annahme über diskrete Logarithmen oder Pairings. Drittens: Kompatibilität mit dem hashbasierten Commitment-Verfahren aus Frage 2. Die Kosten liegen in der Beweisgröße: Ein Bundle-Beweis umfasst etwa 1,3 MB, das 300- bis 600-Fache einer abgeschirmten Transaktion in Zcash oder Monero. Diese Kosten wurden in Kauf genommen und werden gesondert durch Aggregation auf Blockebene adressiert (Fragen 31 und 34).
Quelle: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. Warum das FRI-Profil mit 80 Queries statt 27?
Das Produktionsprofil (80 Queries, Blowup-Faktor 8, 20 Bit Proof-of-Work-Grinding) bietet etwa 86 Bit beweisbare Soundness, gegenüber etwa 42 Bit beim Profil mit 27 Queries, bei 2,75-facher Beweisgröße. Die Verifikationszeit bleibt nahezu unverändert: 809 ms, steigend auf 838 ms cold, und etwa 16 ms warm. Der beweisbaren Soundness wurde Vorrang vor der Beweisgröße eingeräumt, und die Kosten der Größe wurden auf das Block-Space- und Aggregationsdesign verlagert.
Quelle: docs/block-space.md §1, §3
7. Warum wird der Post-Quanten-Anspruch pro Primitiv angegeben statt als „protokollweit 128 Bit“?
Frühere Entwürfe behaupteten 128 Bit Post-Quanten-Sicherheit für das Protokoll als Ganzes. Diese Behauptung ist mit der Schranke von Brassard, Høyer und Tapp unvereinbar, nach der ein Quantenangreifer Kollisionen in einem 256-Bit-Hash mit etwa 2^85 Queries findet; sie wurde daher zurückgezogen, statt sie einzuschränken. Das Paper gibt die Sicherheit nun pro Primitiv und pro Rolle an – ein 384-Bit-Transkript-Hash, 256-Bit-Hashes nur dort, wo Preimage-Resistenz erforderlich ist, Dilithium2, ML-KEM-768 und FRI über einem Erweiterungskörper – unter den Annahmen Module-LWE und Module-SIS, wobei Hashfunktionen als Quanten-Random-Oracles modelliert werden. Der Transkript-Hash des Nodes ist derzeit Poseidon2; die Dokumentation führt dies als offene Konfigurationslücke auf.
Quelle: randprotocol.org (Abschnitt Post-Quanten)
8. Was ist die Klassifizierung „unwiderruflich vs. erneuerbar“, und warum bestimmt sie die Wahl?
Eine Sicherheitseigenschaft ist unwiderruflich, wenn ein Angreifer, der zu einem beliebigen künftigen Zeitpunkt eine neue Fähigkeit erlangt, sie für bereits veröffentlichte Daten rückwirkend verletzen kann; die Vertraulichkeit von Notes und das Verbergen von Commitments sind von dieser Art, sodass sie zum Zeitpunkt der Veröffentlichung quantenresistent sein müssen. Eine Eigenschaft ist erneuerbar, wenn sie bei jeder Verwendung neu hergestellt wird, sodass ein Verfahren ersetzt werden kann, bevor die Bedrohung eintritt; Signaturen und die Soundness von Beweisen sind von dieser Art. Jede Wahl eines Primitivs in diesem Abschnitt folgt aus der Klassifizierung der Eigenschaft, die es schützt.
Quelle: randprotocol.org (Abschnitt Post-Quanten)
Der Shielded Pool
9. Warum ein Note-/UTXO-Modell ohne Konten oder Kontostände?
Ein kontenbasiertes Ledger veröffentlicht Kontostände per Konstruktion; sie zu verbergen erfordert, den Zustand zu verschlüsseln und Aussagen über die Chiffrate zu beweisen, was erheblich aufwendiger ist. Ein Note-Pool speichert nur Commitments und Nullifier, von denen keiner einen Eigentümer oder einen Betrag offenlegt, sodass der öffentliche Zustand keine Informationen über Kontostände enthält. Die einzige Ausnahme ist das Validator-Register, dessen Stake-Gewichte öffentlich sein müssen, damit die Replikate sich über die Quorum-Mitgliedschaft einigen (Frage 29).
Quelle: docs/shielded.md §1–2; docs/staking.md §1
10. Warum ist die Adresse ~1,6 KB groß?
Eine Shielded-Adresse besteht aus dem 32 Byte großen Eigentümerfeld pk und dem 1.184 Byte großen ML-KEM-768-Kapselungsschlüssel, den ein Sender zum Versiegeln des Umschlags benötigt; base58-kodiert sind das etwa 1.667 Zeichen. Die Länge ist eine direkte Folge des Post-Quanten-KEM. Ein genehmigtes Design (kurze Shielded-Adressen, 2026-09-17) ersetzt die Adresse durch einen Empfängerbezeichner von etwa 256 Bit, der auf einen aktualisierbaren Eintrag verweist, mit dem Spend-Schlüssel signiert und vom Explorer bereitgestellt, sodass der Kapselungsschlüssel abgerufen statt abgeschrieben wird.
Quelle: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. Warum wird jeder Schlüssel aus einem einzigen 256-Bit-Spend-Schlüssel abgeleitet?
Sämtliches übrige Schlüsselmaterial ist eine deterministische Funktion eines einzigen Geheimnisses sk: der Viewing-Schlüssel nk = H(NK, sk), das Eigentümerfeld pk = H(PK, nk), der Nullifier H(NF, nk, cm), der ausgehende Viewing-Schlüssel und der ML-KEM-Dekapselungsschlüssel, jeweils unter einem eigenen Domain-Separator. Die Schlüsseldatei speichert daher nur sk, eine Sicherung besteht aus einem einzigen Wert, und ein erneutes Scannen des Baums ab Blatt 0 stellt jede Note wieder her. Weil es keine zweite Kopie gibt, aus der sich wiederherstellen ließe, weigert sich die Wallet, eine vorhandene Schlüsseldatei zu überschreiben.
Quelle: docs/shielded.md §1
12. Warum eine feste 4-in-4-out-Bundle-Form?
Eine feste Form sorgt dafür, dass jedes Bundle unabhängig davon, was es bewegt, dieselbe Größe und Struktur hat. Jedes Bundle veröffentlicht genau vier Nullifier und vier Commitments; ungenutzte Slots sind Dummy-Notes mit dem Wert null, und der Wechselgeld-Output wird auch dann veröffentlicht, wenn sein Wert null ist, da ein fehlender Wechselgeld-Output die Transaktion unterscheidbar machen würde. Die ursprüngliche Spezifikation sah 2-in-2-out vor, nach dem Vorbild von Sapling. Mit dem Hidden-Asset-Bundle wurde sie auf 4-in-4-out erweitert, sodass die Slots 0–1 ein privates Asset und die Slots 2–3 RAND für die Gebühr tragen; vier Slots statt drei erlauben es einem Token-Transfer, seine Gebühr aus bis zu zwei RAND-Notes zu finanzieren.
Quelle: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. Warum bewegt ein Beweis jedes Asset (RAND, zUSD, RPL-Token)?
Vor Chain 14 umfasste eine Token-Überweisung zwei Bundles, eines für die RAND-Gebühr und eines für den Vermögenswert. Das erforderte zwei Beweise und offenbarte jedem Beobachter, welcher Token bewegt wurde. Der Hidden-Asset-Guest nimmt die Asset-Kennung als privaten Input entgegen, sodass sich eine zUSD-Überweisung nicht von einer RAND-Zahlung unterscheiden lässt. Der Guest passt nur deshalb in Tier 14 (etwa 100 s und 5,7 GB Speicher), weil er seine Inputs in einer Schleife liest und die Merkle-Zugehörigkeitsprüfung fusioniert; eine vollständig ausgerollte Implementierung erfordert Tier 16 (etwa 400 s und 21 GB), was den Speicher eines Rechners mit 16 GB übersteigt.
Quelle: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. Warum ist die Gebühr öffentlich und wird an den Proposer gezahlt?
Eine öffentliche Gebühr ist mit dem öffentlichen Stake-Register vereinbar und macht die Zulassung kostengünstig: Ein Node kann die Gebührenuntergrenze prüfen, bevor er irgendeine Verifikation durchführt. Der Bundle-Beweis erzwingt die Bilanzgleichung Σ Inputs = Σ Outputs + Gebühr + Burn, sodass die Gebühr aus verborgenen Notes gezahlt wird, ohne offenzulegen, welche Notes. Der in Kauf genommene Preis ist, dass die Höhe der Gebühr die Klasse der Transaktion (Überweisung oder Programmaufruf) verraten kann.
Quelle: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (Tabelle der Entscheidungen); docs/fees.md §1
15. Warum haben Einzahlungen (Mint, Bridge-Attestierung) einen öffentlichen Betrag?
Wert, der in den Pool gelangt, muss öffentlich nachvollziehbar verbucht werden, und die Bridge-Attestierung ist der öffentliche Nachweis, dass auf der Quell-Chain eine entsprechende Sperrung stattgefunden hat. Die daraus folgende Sichtbarkeit beschränkt sich auf den Eintrittsschritt, analog zu einer Transaktion von transparent zu shielded (t-zu-z) in Zcash; spätere Ausgaben der eingezahlten Note sind verborgen.
Quelle: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (Tabelle: was öffentlich ist)
16. Warum ist das Memo ein Feld fester Länge von 512 Byte?
Ein Feld fester Länge stellt sicher, dass das Ledger nicht offenlegt, ob ein Memo vorhanden ist oder wie lang es ist: Auf einer Chain mit aktiviertem Memo ist jeder Note erzeugende Envelope, einschließlich Dummies und Wechselgeld, genau 1.860 Byte groß. Das Memo wird ausschließlich innerhalb des verschlüsselten Envelopes übertragen, niemals in der Note, im Commitment oder im Beweis, und ist für genau die Parteien lesbar, die die Note ohnehin entschlüsseln können. Ein fehlerhaftes Memo wird als leeres Memo dekodiert, damit es die Note selbst nicht unwiederherstellbar machen kann.
Quelle: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. Warum erfolgt das Proving lokal, und wie hebt der delegierte Prover dies nicht auf?
Der Beweis selbst ist die Ausgabeautorisierung: Ein Bundle enthält weder eine Signatur noch ein Absenderfeld, sodass der Spend-Schlüssel die Wallet nie verlassen muss. Ein Bundle-Beweis auf Tier 14 benötigt etwa 5,7 GB Speicher, mehr, als Smartphones und Browser bereitstellen können; daher der delegierte Prover. Die geteilte Autorisierung (Bundle-Guest v3, Genesis-Parameter hc_auth) trennt die beiden Rollen: Der Prover erhält nur den Viewing-Key nk und erzeugt den Bundle-Beweis, während die Wallet mit sk einen kleinen Autorisierungsbeweis auf Tier 10 erzeugt. Ein Prover kann somit einen Bundle-Beweis konstruieren, aber keine Ausgabe autorisieren (Frage 36).
Quelle: docs/prover.md §1; docs/shielded.md (geteilte Autorisierung); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. Warum ein Anchor-Fenster von 256 Blöcken?
Ein Beweis wird gegen eine bestimmte Wurzel des Commitment-Baums (seinen Anchor) konstruiert, und die Konstruktion eines Bundle-Beweises auf Tier 14 dauert etwa 100 s. Das Ledger muss daher Anchors akzeptieren, die zum Zeitpunkt der Einreichung mehrere Minuten alt sind. Das Fenster betrug in der ursprünglichen Spezifikation 64 Blöcke und wurde mit der Verkürzung des Blockintervalls auf 256 Blöcke erweitert, sodass seine Dauer in Echtzeit oberhalb der Proving-Zeit bleibt.
Quelle: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
Die zkVM und vertrauliche Berechnung
19. Warum RV32I als Guest-ISA (und nicht RV64)?
Ein 32-Bit-Wort zerfällt in genau vier Byte-Limbs, und die Goldilocks-Primzahl p = 2^64 − 2^32 + 1 ist groß genug, dass das Produkt zweier 32-Bit-Werte den Körper nie überläuft. RV64 würde die Zahl der Limb-Spalten in den ALU- und Speichertabellen verdoppeln. RISC-V ist zudem ein bestehendes Ziel gängiger Compiler, sodass Guest-Programme gewöhnliche kompilierte Binärdateien sind und keine Programme in einer eigens entworfenen Sprache.
Quelle: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. Warum Goldilocks und nicht ein 256-Bit-Körper?
Goldilocks ist eine 64-Bit-Primzahl, deren Arithmetik sich effizient auf native 64-Bit-CPU-Befehle abbilden lässt und deren multiplikative Gruppe eine große Untergruppe von Zweierpotenz-Ordnung besitzt, wie FRI sie verlangt. Zusammen mit 32-Bit-Wörtern hält sie jede Trace-Zeile schmal, was das Proving im Produktionsprofil auf einem Laptop praktikabel macht. Die Soundness, die durch das Arbeiten über einem kleinen Körper verloren geht, wird zurückgewonnen, indem die FRI-Challenges aus einem Erweiterungskörper gezogen werden.
Quelle: docs/zkvm.md §2; randprotocol.org (Abschnitt Performance)
21. Warum Gas-Tiers statt Gas-Metering pro Opcode?
Gas pro Opcode gibt es in Ethereum, weil jeder Node jede Transaktion erneut ausführt und die Ausführungslänge nicht im Voraus beschränkt ist. In Rand führt kein Node ein Programm aus: Der Absender führt es einmal off chain aus, und die Nodes verifizieren einen einzigen STARK, dessen Verifikationskosten nur vom Tier abhängen, nicht von der durchgeführten Berechnung. Die Terminierung wird durch das Tier erzwungen, da eine Ausführung, die nicht innerhalb von 2^t Zyklen hält, auf Tier t keinen Beweis zulässt. Die Preisgestaltung besteht aus einer pauschalen Untergrenze plus einer durch den Header begrenzten Gas-Schätzung, und die Blockkapazität ist ein Byte-Budget. Gas tritt nur innerhalb der Guests für den EVM- und den sBPF-Interpreter auf, als privater Zustand, wo es benötigt wird, um die Semantik der Quell-Chain nachzubilden.
Quelle: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. Warum ist der Trace in neun Tabellen aufgeteilt, die durch LogUp-Busse verbunden sind?
Eine einzige monolithische Tabelle würde jede Zeile auf die Breite der breitesten Operation auffüllen. Die Aufteilung des Trace in neun Tabellen — CPU, Speicher, ALU, Range, Nibble, Poseidon2, Programm, Input und Public —, von denen jede nur auf ihre eigene Höhe aufgefüllt wird, hält den Gesamt-Trace klein. LogUp-Argumente stellen die Multimengen-Relationen zwischen den Tabellen her. Keccak- und SHA-256-Tabellen sind optional und werden nur aufgenommen, wenn der Guest den entsprechenden Systemaufruf verwendet.
Quelle: docs/zkvm.md §5
23. Warum veröffentlicht ein Programmaufruf nur acht Output-Wörter?
Ein Programmaufruf ist ein Beweis, dass öffentlicher Code auf privaten Inputs korrekt ausgeführt wurde; das Ledger verzeichnet nur die Quittung. Acht 32-Bit-Wörter genügen, um ein Ergebnis, ein Commitment oder eine Entscheidung zu binden, und eine feste Output-Größe stellt sicher, dass die Form der Quittung nichts über das Programm verrät. Outputs sind derzeit ausschließlich Daten: Ein Programm kann selbst keinen Wert übertragen.
Quelle: randprotocol.org/usecases (Hinweis zur Plattform); docs/confidential.md
24. Warum gibt es einen Call-Input-Envelope?
Wer die privaten Inputs aufbewahrt, kann später nachweisen, worüber ein Aufruf berechnet wurde. Der Call-Input-Envelope macht dies dauerhaft, indem er die Inputs verschlüsselt zusammen mit dem Aufruf speichert, wo ein benannter Auditor sie mit einem Schlüssel entschlüsseln kann. Dies erweitert die selektive Offenlegung — vertraulich gegenüber dem Markt, offen gegenüber einem benannten Regulator — von Zahlungen auf die Programmausführung.
Quelle: docs/confidential.md (‘Call input envelopes’)
25. Warum ist eine Änderung des Constraint-Satzes ein Hard Fork?
Jeder Node verifiziert bei der Synchronisation jeden Beweis erneut, und ein Beweis ist nur bezüglich des Constraint-Satzes (AIR) gültig, unter dem er erzeugt wurde. Eine Änderung der AIR verändert daher die Menge der gültigen Chains und wird bei einem Genesis-Cut eingeführt, statt Node für Node übernommen zu werden.
Quelle: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. Warum ist der Emulator die Referenz und nicht die AIR?
Der Emulator ist die lesbare Spezifikation der Maschine, und die AIR ist eine Kodierung dieser Spezifikation als polynomielle Constraints. Wo beide voneinander abweichen, ist per Definition die AIR fehlerhaft. Dadurch liegt die normative Definition in dem Artefakt, das sich für Menschen am praktischsten prüfen lässt.
Quelle: docs/zkvm.md §5
Konsens und der Node
27. Warum Chained HotStuff BFT?
Chained HotStuff bietet deterministische Finalität: Bei stakegewichteten Quoren von mehr als zwei Dritteln ist ein Block final, sobald drei aufeinanderfolgende Quorum-Zertifikate auf ihm gebildet wurden, und ein finaler Block wird nie reorganisiert. Das gemessene Blockintervall beträgt 1,2 s und die Zeit bis zur Finalität etwa 3,6 s. Die vorgesehenen institutionellen Nutzer benötigen eine Abwicklungsfinalität, gegen die sie Buchungen erfassen können, was eine Chain mit probabilistischer Finalität nicht bietet.
Quelle: fullnode README; randprotocol.org (Abschnitt Performance); docs/architecture.md §6
28. Warum liegt die Beweisverifikation außerhalb der Konsensschleife?
Ein Node verifiziert jeden STARK, wenn er die Transaktion zulässt (etwa 32 ms im warmen Zustand), bevor er sie weiterleitet, sodass die Verifikation nie auf dem kritischen Pfad der Blockvorschläge liegt. Das Blockintervall wird daher durch die Konsenslatenz bestimmt und nicht durch die Beweisgröße. Die Prüfungen sind nach Kosten geordnet, wobei der STARK zuletzt verifiziert wird, damit eine fehlerhafte Transaktion vor dem aufwendigsten Schritt abgewiesen wird.
Quelle: randprotocol.org; docs/architecture.md (‘How it works’)
29. Warum ist das Validator-Register öffentlich, wenn alles andere shielded ist?
Alle Replikate müssen sich darüber einig sein, welche Validatoren Blöcke vorschlagen dürfen und welche Stimmen ein Quorum bilden, was öffentliche Stake-Gewichte voraussetzt. Das Register enthält die Stake-Beträge daher im Klartext. Die Verbindung zum Eigentümer bleibt verborgen: Ein Bond wird aus einer shielded Note finanziert und eine Auszahlung in eine solche geleistet, und keiner der beiden Vorgänge offenbart, wessen Note es ist.
Quelle: docs/staking.md §1
30. Warum führt ein synchronisierender Knoten jeden Block erneut aus, statt Zertifikaten zu vertrauen?
Ein Knoten, der verspätet beitritt, prüft jedes Quorum-Zertifikat, verifiziert jedes Bundle und jeden Aufrufbeweis erneut und vergleicht die resultierenden Receipts, bevor er die Chain akzeptiert. Da die Gültigkeit durch die Beweise und nicht allein durch Signaturen hergestellt wird, ist dieses Verfahren nicht den Long-Range-Angriffen ausgesetzt, die Chains betreffen, die nur durch Signaturen gesichert sind. Das Entfernen von Beweisen aus der Historie wurde verworfen, da es diese Garantie aufheben würde.
Quelle: docs/architecture.md; docs/aggregation.md (Einleitung)
31. Warum bleibt das Blocklimit bei 4 MiB, obwohl ein Beweis über 1 MB groß ist?
Bei einem festen Limit kann die Blockgröße nicht wachsen; übersteigt die Nachfrage die Kapazität, wird stattdessen der Durchsatz begrenzt (auf drei abgeschirmte Transfers pro Block beim 80-Query-Profil). Eine Durchsatzgrenze wurde als sicherer Fehlermodus eingestuft als unbegrenztes Blockwachstum. Als Abhilfe wurde die Aggregation auf Blockebene gewählt, ein rekursiver Beweis pro Block, statt das Limit anzuheben oder das Soundness-Niveau zu senken.
Quelle: docs/block-space.md §1, §6
32. Warum kürzt das testnet die Historie auf einen Tag?
Ein Quorum-Zertifikat mit 18 Dilithium2-Signaturen umfasst etwa 44 KB und wird pro Block zweimal gespeichert. Bei überwiegend leeren Blöcken alle 1,4 s ergab das etwa 6,6 GB pro Knoten und Tag; die Datenträger der Knoten füllten sich, und die Chain verlor bei Blockhöhe 248.953 das Quorum. Full Nodes im testnet behalten nun einen Tag an Historie, ein einzelner Archivknoten behält sie vollständig, und Knoten im mainnet werden sie vollständig behalten. Der Ledger-Zustand – der Baum, die Nullifier-Menge, das Register und die Programme – wird nie gekürzt.
Quelle: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. Warum libp2p?
Der Knoten verwendet TCP mit Noise und Yamux, Gossipsub für Transaktionen und Stimmen, Kademlia mit einer Bootstrap-Liste für die Peer-Erkennung, mDNS in lokalen Netzwerken sowie Request-Response für die Blocksynchronisation. Das sind standardisierte, weit verbreitete Komponenten, sodass der Knoten Peer-Scoring, Wiederverbindung und Transport-Upgrades erbt, statt eigene Implementierungen zu pflegen.
Quelle: README des Fullnode (Zeile „networking“)
Proving-Markt und Aggregation
34. Warum Beweisaggregation auf Blockebene?
Der Blockplatz wächst linear mit der Anzahl der Bundles, wenn jedes einen eigenen Beweis von etwa 1,3 MB mitführt. Ein einzelner rekursiver STARK pro Block, der alle N Bundle-Beweise verifiziert, hält die On-Chain-Beweiskosten konstant in N. Validatoren verifizieren dann einen einzigen aggregierten Beweis (etwa 16 ms im Warm-Zustand) auf einer CPU, sodass weiterhin Standardhardware für die Validierung genügt, während Aggregatoren mit GPUs in einem getrennten, erlaubnisfreien Markt um den Proving-Anteil an den Gebühren und eine Block-Subvention konkurrieren.
Quelle: docs/aggregation.md §1
35. Warum drei Rollen – Validator, Aggregator, delegierter Prover?
Die drei Rollen haben unterschiedliche Hardwareanforderungen und werden von unterschiedlichen Parteien bezahlt. Ein Validator ordnet und verifiziert Transaktionen auf einer CPU und wird aus dem Verifikationsanteil der Gebühren bezahlt. Ein Aggregator erzeugt den rekursiven Blockbeweis auf einer GPU und wird aus dem Proving-Anteil und der Subvention bezahlt. Ein delegierter Prover erzeugt einen einzelnen Bundle-Beweis für einen Absender, dessen Gerät dies nicht leisten kann (ein Telefon oder Browser), und wird von diesem Absender privat bezahlt. Die Trennung der Rollen hält die Validierung günstig und macht das Proving wettbewerblich.
Quelle: docs/prover.md §1
36. Warum kann ein delegierter Prover keine Gelder stehlen?
Bei geteilter Autorisierung erhält der Prover den Viewing Key nk, aber nicht den Spend Key sk. Der Bundle-Beweis legt sich auf c = H(AUTH, nk || salt) fest, und der separate Autorisierungsbeweis der Wallet weist die Kenntnis von sk für dasselbe c nach. Ohne sk kann der Prover zwar den Bundle-Beweis berechnen, aber keine gültige Autorisierung erzeugen, und die Wallet verifiziert den zurückgegebenen Beweis, bevor sie ihn einreicht.
Quelle: docs/shielded.md (geteilte Autorisierung); docs/prover.md §8
Die Bridge und zUSD
37. Warum USDT/USDC auf ihren Heimat-Chains sperren, statt einen neuen Stablecoin auszugeben?
Eine native Ausgabe auf Rand würde die Reservekapazität von den Bereitstellungsentscheidungen der Emittenten abhängig machen, die außerhalb der Kontrolle des Projekts liegen. Das Sperren von USDT und USDC auf Ethereum, BSC, Tron und Solana schöpft Reserven aus den Chains, auf denen diese Assets bereits zirkulieren, und führt keinen neuen Emittenten ein: Jede zUSD-Einheit ist ein Anspruch auf USDT oder USDC, das in einem öffentlich einsehbaren Verwahrungsvertrag gehalten wird.
Quelle: randprotocol.org (Abschnitt Reserve)
38. Warum eine t-aus-n-Guardian-Menge, und warum das offen aussprechen?
Die Attestierung ist der einzige Nachweis, über den Rand verfügt, dass auf einer anderen Chain eine Sperrung stattgefunden hat; sie muss daher von einer Schwellwertgruppe signiert sein, und eine gültige Attestierung erfordert Signaturen von mehr als zwei Dritteln der Guardians. Die daraus folgende Vertrauensannahme wird ausdrücklich benannt. Die tatsächliche Garantie ist die schwächere aus Reservesolvenz und Bridge-Integrität; eine Koalition aus t Guardians kann das Minten ohne entsprechende Sperrung autorisieren; und das Risiko ist durch die auf jeder Chain gehaltene Verwahrung begrenzt. Diese Annahme war ursprünglich das Argument gegen den Bau einer Bridge. Sie wird nicht zurückgenommen, sondern im Austausch gegen Reservekapazität akzeptiert.
Quelle: randprotocol.org (Abschnitt Reserve, „What this costs“)
39. Warum eine Dilithium2-Mitsignatur neben der ECDSA-Attestierung?
Die Quell-Chains bieten keinen Verifizierer für Gittersignaturen, daher bleiben Freigaben auf diesen Chains durch klassisches ECDSA gesichert, wobei das Risiko durch Verwahrung und Limits begrenzt ist. Jede Nachricht, die der Rand-Ledger von den Guardians akzeptiert – Einzahlungen und Rotationen der Guardian-Menge –, muss zusätzlich ein Quorum von Dilithium2-Signaturen derselben Guardians tragen. Der Mint-Pfad ist somit post-quantensicher, auch wenn die externen Endpunkte es nicht sind. Die Mitsignaturen werden zusammen mit der Attestierung übermittelt und erfordern keine Änderung an den bereitgestellten Verträgen.
Quelle: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. Warum wird der Blinding-Wert der Einzahlungs-Note abgeleitet statt gewählt?
Zuvor stand die Commitment der Einzahlungs-Note erst fest, wenn ein Relayer die Attestierung einreichte, sodass zwei Relayer dieselbe Attestierung mit unterschiedlichen Notes einreichen konnten. Die deterministische Ableitung des Blinding-Faktors r aus der Attestierung legt das Commitment fest, sodass konkurrierende Einreichungen auf ein einziges Commitment kollidieren und die Einzahlung nicht zweimal gemintet werden kann.
Quelle: docs/bridge.md (F1, chain 14)
41. Warum kann auf Tron gesperrtes USDT als USDT auf Ethereum ausgezahlt werden?
zUSD ist fungibel: Jede Einheit ist ein Anspruch auf die aggregierte Reserve, nicht auf die Chain, über die sie eingetreten ist. Die Entkopplung von Eintritt und Austritt erlaubt es der Liquidität, dorthin zu wandern, wo sie nachgefragt wird, sofern die Zielchain über ausreichende Reserven verfügt. Das Stablecoin-Paper beweist, dass die Invariante S ≤ Σ_c R_c, also Gesamtmenge begrenzt durch die Summe der Reserven je Chain, von jedem Zustandsübergang erhalten wird.
Quelle: randprotocol.org (Abschnitt Reserve)
42. Warum verbirgt Shielding die Verteilung, aber nicht die Menge?
Die Gesamtmenge an zUSD ist im Token-Register öffentlich, und die Reserve jeder Chain ist ein öffentlicher Kontostand, sodass die Solvenz von jedem überprüft werden kann; verborgen ist die Verteilung der Bestände auf die Eigentümer. Eine Einschränkung gilt: Die vier Reservestände lassen sich nicht atomar zu einem einzigen Zeitpunkt beobachten, sodass die Prüfung für diese Chains eine Insolvenz nachträglich feststellt, statt sie zu verhindern.
Quelle: randprotocol.org (Abschnitt Reserve)
43. Warum ist ein Burn die einzige Transaktion, die ihr Asset benennt?
Ein Burn gibt ein bestimmtes Asset auf einer bestimmten Chain frei, sodass der Verwahrungsvertrag erfahren muss, um welches Asset und welche Chain es sich handelt. Jede andere Transaktion überträgt ein nicht identifiziertes Asset. Der Burn trägt außerdem die Bridge-Gebühr, weil er die einzige Bridge-Transaktion ist, deren Absender der Begünstigte ist.
Quelle: docs/architecture.md; docs/shielded.md §2
Compliance und Offenlegung
44. Warum Viewing Keys statt „privat gegenüber allen“?
Regulierungsbehörden haben Privacy-Systeme nicht akzeptiert, bei denen die Offenlegung von der Kooperation der untersuchten Partei abhängt, wie der Fall Tornado Cash zeigt. Rand behandelt die Offenlegung daher als Protokollobjekt. Der Inhaber oder ein regulierter Intermediär behält einen Viewing Key; ein Prüfer kann die in einem rechtmäßigen Ersuchen benannten Transaktionen entschlüsseln; und das Designziel sind eingegrenzte Schlüssel, die Gegenpartei und Betrag offenlegen, ohne die Handelsstrategie preiszugeben. Für Anwendungen wie die Gehaltsabrechnung ist diese Prüfbarkeit eine Anforderung und keine Einschränkung.
Quelle: randprotocol.org/usecases (Abschnitt Regulierung; Fall Gehaltsabrechnung)
45. Warum ist der Outgoing Viewing Key vom Incoming Viewing Key getrennt?
Die Trennung erlaubt es einem Absender, nachzuweisen, was er gezahlt hat, ohne Zugang zur Historie des Empfängers zu erhalten, und umgekehrt. Der Outgoing Viewing Key ovk entschlüsselt Umschläge, die die Wallet gesendet hat; der ML-KEM-Dekapselungsschlüssel entschlüsselt an ihn gesendete Umschläge; und ein Schlüssel pro Transaktion legt genau eine Ausgabe gegenüber einem Dritten offen.
Quelle: docs/shielded.md §1–2
Bekannte Einschränkungen
46. Was verraten die Beweise heute, und warum ist das dokumentiert?
Die Überprüfung vom 2026-09-27 ergab, dass beim v1-Guest (Chains 14–15) jeder Bundle-Beweis offenbart, welche Eingabeplätze echte Notes enthalten und welches Hamming-Gewicht der Index jedes ausgegebenen Blatts hat. Die Ursache ist zweifach: Die LogUp-Summen je Tabelle werden ohne Blinding veröffentlicht, und der Kontrollfluss des Guests verzweigt danach, ob eine Eingabe ein Dummy ist. Die Abhilfe ist ein verzweigungsfreier Guest (v2), der beim nächsten Genesis ausgewählt wird. Der Befund wird veröffentlicht, weil das Netzwerk ein testnet ist und die Dokumentation als dessen Audit-Protokoll dient.
Quelle: docs/shielded.md („What the proofs leak today“)
47. Warum ist das Zustandswachstum zu niedrig bepreist?
Ethereum bewertet Schreibzugriffe auf den Speicher mit einem Preis, weil gespeicherter Zustand jedem Node dauerhafte Kosten auferlegt. Rand bepreist das Wachstum des Commitment-Baums, der Nullifier-Menge und des Programmspeichers derzeit nur über die Gebühr pro Wort bei der Bereitstellung und die pauschale Bundle-Gebühr. Für ein testnet ist das angemessen, es ist jedoch als offene Preisfrage vermerkt, die vor dem mainnet-beta geklärt werden muss; ihre Klärung erfordert keine Abrechnung pro Opcode.
Quelle: docs/fees.md §3 (caveats)
48. Warum wurde bislang kein unabhängiges Audit abgeschlossen?
Das Protokoll befindet sich in aktiver Entwicklung auf einem vom Team betriebenen testnet, und weitere Constraint-Sets und Chain-Cuts sind zu erwarten, bevor das Design stabil ist. Die Website weist auf jeder Seite darauf hin. Die internen Audit-Runden (v3–v5) sind in docs/consensus.md und in den Design-Spezifikationen veröffentlicht, damit dem späteren externen Audit eine vollständige Dokumentation als Arbeitsgrundlage vorliegt.
Quelle: randprotocol.org (footer); docs/consensus.md