Verwenden Sie diese Seite, um nachzuvollziehen, wer was tut, wenn eine Überweisung durch Rand läuft. Das Beweisen ist aufwendig und das Verifizieren günstig, deshalb ist die Arbeit entlang dieser Linie aufgeteilt. Die Seite des Senders erstellt die Beweise. Validatoren prüfen sie nur, ordnen sie und stimmen darüber ab. Ein Aggregator würde, sobald er aktiviert ist, viele Beweise zu einem einzigen zusammenfassen. Die Abbildung folgt einer Überweisung von der Wallet bis zu einem finalen Block; die Abschnitte danach behandeln jede Rolle der Reihe nach.
Der Weg einer Überweisung
- Die Wallet erstellt die Überweisung. Sie wählt ihre Input-Notes aus, holt deren Merkle-Witnesses, erstellt vier Outputs und versiegelt jeden in einem ML-KEM-768-Umschlag. Anschließend berechnet sie das Binding der Transaktion, einen Hash über alles außer den Beweisen (Transactions).
- Die Wallet beweist die Autorisierung selbst. Das ist ein tier-10-Beweis über den Spend-Key und ein frisches Salt, eine Sache von Sekunden. Es ist der einzige Beweis, der den Spend-Key berührt, und er wird immer auf dem eigenen Rechner der Wallet erstellt.
- Der Bundle-Beweis wird dort erstellt, wo genug Speicher dafür vorhanden ist. Dieser tier-14-Beweis zeigt Eigentum, Mitgliedschaft, die Nullifier und die Bilanz und benötigt Spitzenwerte von etwa 6 GB. Die Desktop-App und ein Smartphone mit etwa 8 GB erstellen ihn selbst. Alles, was kleiner ist, übergibt die Aufgabe an einen gekoppelten Prover: einen, den Sie selbst betreiben, oder den Prover-Pool der Validatoren unter
prover.randprotocol.org. Beiden werden der Viewing-Key und das Salt gesendet, nie der Spend-Key (Proofs). - Ein RPC-Knoten prüft ihn. Jeder Knoten, bei dem die Wallet einreicht, berechnet den Bundle-Digest neu, verifiziert beide Beweise gegen das Binding, prüft die Gebühr und verbreitet die Transaktion erst dann per Gossip an seine Peers (Proofs, Mempool).
- Validatoren ordnen und finalisieren sie. Der Leader der View nimmt die Transaktionen, die noch gültig sind, zuerst mit der besten Gebühr pro KiB, und schlägt einen Block vor. Jeder Validator verifiziert jeden Beweis darin erneut und stimmt ab. Der Block wird festgeschrieben, sobald drei Quorum-Zertifikate in aufeinanderfolgenden Views darauf aufbauen; dafür müssen 18 der 26 Validatoren von chain 20 online sein (Consensus).
- Der Block ist final, und jeder kann ihn prüfen. Eine Transaktion ist final, wenn
rand_getTransactioneinen Block zurückgibt. Ein Knoten, der später synchronisiert, verifiziert jedes Zertifikat und jeden Beweis erneut, statt den Signaturen zu vertrauen.
Die Rollen
| Rolle | Aufgabe | Beweist? | Was sie sieht | Läuft als |
|---|---|---|---|---|
| Wallet | erstellt, autorisiert und reicht Überweisungen und Aufrufe ein; durchsucht die Chain mit den eigenen Schlüsseln | immer den Autorisierungsbeweis; den Bundle-Beweis, wenn das Gerät genug Speicher hat | alles über die eigenen Notes | die Apps auf der Seite Clients oder rand; auf chain 20 Rand Wallet oder rand ab v0.6.8 |
| delegierter Prover | erstellt den Bundle-Beweis für eine mit ihm gekoppelte Wallet; jede Antwort wird von der Wallet geprüft, bevor etwas eingereicht wird | nur Bundle-Beweise | der Viewing-Key der gekoppelten Wallet: ihre gesamte Historie, vergangen und zukünftig; er kann nichts ausgeben | rand-prover run oder rand-node run --prover |
| Prover-Pool der Validatoren | ein delegierter Prover, der von vier Hosts betrieben wird, zwei Validatoren und zwei Maschinen, die nur beweisen, unter einem Namen und einem Schlüssel, für Wallets ohne eigenen Prover; keine Gebühr | nur Bundle-Beweise | dasselbe wie bei jedem delegierten Prover, für jede Wallet, die ihn koppelt | prover.randprotocol.org, Fingerabdruck RGTF-7HKJ-XZFV-GQ1J |
| RPC-Knoten (Observer) | synchronisiert, verifiziert jeden Beweis erneut, stellt JSON-RPC bereit, verbreitet verifizierte Transaktionen per Gossip; keine Stimme | nein | nur öffentliche Felder: Commitments, Nullifier, versiegelte Umschläge, Beweise | rand-node run |
| Validator | alles, was ein Observer tut, dazu das Vorschlagen in seinen Views und das Abstimmen in HotStuff | nein | nur öffentliche Felder | rand-node run --validator |
| Aggregator | erstellt einen rekursiven Beweis über ein Fenster finalisierter Bundle-Beweise und reicht ihn für einen versiegelnden Block ein | ja, die größten Beweise im Netzwerk | nur öffentliche Felder und Beweise | rand-node aggregate --watch, auf einer Chain mit einem Abschnitt aggregation |
Beweisen und Validieren sind getrennte Aufgaben, und ein Validator braucht keine Prover-Hardware. Zwei der vier Mitglieder des Pools sind Validatoren, die zusätzlich als Dienst einen Prover betreiben; die anderen beiden sind dedizierte Prover-Maschinen ohne Validator-Schlüssel. Den Pool zu betreiben ist nicht Teil des Validierens. Die Dimensionierung für jede Rolle und der gemessene Beweisspeicher je Tier stehen unter Validator and aggregator hardware.
Was jede Rolle erfahren kann
Die Privatsphäre einer Überweisung hängt davon ab, wer welchen Schlüssel besitzt, nicht davon, dem Netzwerk zu vertrauen:
- Validatoren, RPC-Knoten und der Explorer sehen, was jeder Knoten sieht: Commitments, Nullifier, versiegelte Umschläge, die Gebühr und die Beweise. Nicht den Betrag, den Asset, den Sender oder den Empfänger.
- Einem delegierten Prover, einschließlich des Pools, wird der Viewing-Key gesendet. Damit kann er die gesamte Historie der gekoppelten Wallet lesen. Er kann nie etwas ausgeben, weil der Autorisierungsbeweis über den Spend-Key auf dem Rechner der Wallet erstellt wird. Den Pool zu koppeln heißt, sich dafür zu entscheiden, seinen Betreibern diese Historie zu zeigen. Wenn sie privat bleiben soll, beweisen Sie auf Ihrem eigenen Gerät oder betreiben Sie Ihren eigenen Prover.
- Ein delegierter Prover kann die Wallet nicht täuschen. Die Wallet liest den Digest aus jedem ihr übergebenen Beweis, prüft die Größe und verifiziert ihn lokal, sodass ein falscher Beweis nie einen Knoten erreicht.
Aggregation: gebaut, nicht aktiv
Heute trägt jeder Block jeden Rohbeweis, etwa 2,85 MB für eine Überweisung, sodass ein Block von 20 MiB etwa sieben Überweisungen fasst. Die Blockaggregation ist die Antwort des Fullnodes darauf. Ein Aggregator nimmt die Bundle-Beweise eines Fensters finalisierter Blöcke (rand_getUnsealed), erstellt einen rekursiven Beweis, der sie alle verifiziert, und reicht ihn ein. Der Block, der ihn enthält, versiegelt das Fenster. Validatoren verifizieren dann einen Aggregat-Beweis statt N Beweisen, und Knoten können die abgedeckten Rohbeweise verwerfen. Aggregatoren hinterlegen eine Kaution (Bond), sind permissionless, laufen auf Maschinen der GPU-Klasse und erhalten den Beweisanteil der abgedeckten Bundles sowie eine Blocksubvention in neuen RAND.
Sie ist gebaut und gemergt, aber nicht aktiv. Sie benötigt einen Abschnitt aggregation im Genesis, und chain 20 hat keinen, weshalb rand_status jeden Aggregationszähler als null meldet. Bevor sie aktiviert werden kann, muss ihre Bundle-Form unter dem aktuellen Constraint-Set neu vermessen und eine Übung mit gefälschten Aggregaten gegen den Rekursions-Verifier durchgeführt werden. Auf einer Chain mit getrennter Autorisierung würde sie zudem nur die Bundle-Beweise versiegeln, nicht die Autorisierungsbeweise (Proofs).