Fortschritt
Fortschritt
Jede Version des Rand Full Node, vom ersten Tag bis zu lesbaren Adressen. Veröffentlichte Versionen zeigen das Datum, an dem sie getaggt wurden. Spätere Versionen zeigen eine Schätzung, bei einer Version pro Woche. Schätzungen verschieben sich, wenn sich die Arbeit verschiebt.
- Veröffentlicht
- 18
- In Arbeit
- 0
- Geplant
- 1
- v0.1Veröffentlicht v0.1 · 16 Sept 2026
Korrekturen aus dem Security Review und die RAND-Coin
- Der erste getaggte Full Node: HotStuff BFT, der Shielded Pool, Staking, vertrauliche Programme auf der zkVM.
- Korrekturen der Befunde aus dem Security Review vor dem Release.
- Die native Coin ist RAND, und Gebühren werden in RAND bezahlt.
- v0.2Veröffentlicht v0.2 · 17 Sept 2026
Forschung zu lesbaren Adressen
- Forschung zu Adressen, die Menschen lesen können.
- Die Ergebnisse führten zur Adressfreigabe in v0.5.10: Die Adresse bleibt bei etwa 1.667 Zeichen und erhält einen Fingerabdruck, Zahlungslinks und QR-Codes.
- v0.3Veröffentlicht v0.3 · 18 Sept 2026
Das RPC-Release
- Elf neue JSON-RPC-Methoden und zwei WebSocket-Topics, abgestimmt auf die RPC von Ethereum und Solana.
- Die Wallet-Befehle rand viewing-key und rand tx-key.
- Das Programmlimit als Genesis-Parameter, wirkungslos, bis eine Chain es setzt.
- v0.4Veröffentlicht v0.4 · 19 Sept 2026
Die RISC-V-Toolchain und die Transpiler für Solana und Ethereum
- rand-guest: RV32IM-Programme aus Rust oder C bauen, prüfen, packen, ausführen und untersuchen.
- sbpf2rv und evm2rv: Solana- und EVM-Programme, übersetzt nach RISC-V, mit Ausgaben, die den Interpretern Wort für Wort entsprechen.
- Chain 13, deren Genesis das Programmlimit und die Aufruflimits anhebt; das übersetzte ERC-20 und SPL Token wurden darauf bereitgestellt.
- v0.5Veröffentlicht v0.5 · 20 Sept 2026
RPL-Token, zUSD und die gehärtete Bridge
- Chain 14, am selben Tag erstellt und getaggt. Ein USDT durchlief auf Ethereum, Binance Smart Chain, Tron und Solana jeweils den vollständigen Rundweg: gesperrt, als zUSD geprägt, verbrannt, freigegeben. Eine zweite Runde ließ 36 zUSD zurück, geprägt gegen 36 USDT in Verwahrung.
- RPL, der Token-Standard: Ein Token ist ein Eintrag im Register des Ledgers, von jedem gegen eine Gebühr in RAND erstellbar, und bewegt sich im selben Proof wie RAND, sodass verborgen bleibt, welcher Vermögenswert bewegt wurde.
- zUSD ist auf Chain 14 als ein gebridgter Token mit sieben Deckungen registriert: USDT und USDC auf Ethereum, Binance Smart Chain und Solana sowie USDT auf Tron.
- Härtung der Bridge: ein tägliches Mint-Limit pro Deckung, ein Pause-Schlüssel, eine Post-Quanten-Mitsignatur bei jedem Mint und begrenzte Block-Zeitstempel.
- Jeder Proof ist an seine gesamte Transaktion gebunden. Aus dem Security Audit: Die achtzehn Validator-Schlüssel wurden rotiert, und ein Faucet-Mint öffnet nun seine Commitment.
- v0.5.9Veröffentlicht v0.5.9 · 27 Sept 2026
Chain 15 und die Audit-Korrekturen
- Chain 15, am 26. September von der Bridge-Position der Chain 14 erstellt: Die 10 noch ausstehenden zUSD wurden in der Genesis übernommen, gedeckt durch 9 USDT auf Tron und 1 USDT auf Solana, sodass das Angebot ab Block 0 der Verwahrung entspricht. Die Flotte wurde danach auf v0.5.9 umgestellt.
- Die Patch-Releases v0.5.x bis v0.5.9 behoben die Befunde aus drei internen Audit-Runden unter Leitung eines Mitgründers und drei internen Scans (ein unabhängiges Audit wurde noch nicht durchgeführt): eine Konsens-Sperre, die Neustarts übersteht, ein pro Block gespeichertes Quorum Certificate, auf Tier 14 begrenzte Call-Proofs sowie Validatoren, die neben einem vollständigen Archiv einen Tag an Blöcken vorhalten.
- Die Genesis von Chain 15 aktiviert die per Gate geschützten Korrekturen: einen Faucet, beschränkt auf 16 benannte Wallets und ein Budget pro Epoche, eine Bond-Verzögerung von zwei Epochen, jede Konsenssignatur an die Genesis gebunden sowie die Regeln v2 der Bridge mit globalem Mint-Limit und rotierbaren Post-Quanten-Schlüsseln. 26 Validatoren signieren sie nun.
- v0.5.10 · v0.5.11Veröffentlicht v0.5.10 · v0.5.11 · 28 Sept 2026
Adressfreigabe, das verschlüsselte Memo und das Vesting-Register
- v0.5.10: ein Adress-Fingerabdruck mit 16 Zeichen, randpay:-Zahlungslinks und QR-Codes sowie ein verschlüsseltes Memo, versiegelt im Note-Umschlag.
- v0.5.11: ein öffentliches Vesting-Register für gesperrte Zuteilungen (Team, Investoren, Partner), außerhalb des Shielded Pool und per Genesis freigeschaltet; Betrag, Zeitplan, Claims und gebondeter Validator jedes Eintrags sind unter dem Schlüssel des Inhabers öffentlich. Auf noch keiner Chain aktiv.
- v0.6Veröffentlicht v0.6 · 28 Sept 2026
Korrekturen an zkVM, Recursion-VM und Aggregation
- Die meisten Befunde der zkVM-, ISA- und Recursion-VM-Reviews vom 27.–28. September im Code behoben: vier Soundness-Brüche der Recursion-VM (inaktiv, da die Aggregation überall abgeschaltet ist), das Leck der Call-Eingaben bei kleinen Tabellen für neue Proofs geschlossen, das Slashing von Aggregatoren abgeschafft und der Verifier-Schlüssel des Bundles abseits der Konsensschleife vorgehalten.
- Der verzweigungsfreie Bundle-Guest und der Genesis-Schalter hardening_v6 (Untergrenze der Programmtabelle, Call-Bindung, Ablehnung nicht aufrufbarer Deploys), gebaut für den nächsten Chain-Schnitt. Am 28. September auf alle 26 Validatoren ausgerollt.
- Nach v0.6 noch offen: das Gegenbeispiel zur Freigabe der Konsens-Sperre CON-4 (Korrektur entworfen, nicht ausgeliefert), die Schlüsselverwahrung der Bridge, die Witness-Anfragen der GUI-Wallets an die öffentliche RPC und der Test für gefälschte Aggregate (#45), bevor die Aggregation aktiviert werden kann.
- v0.6.1 · Chain 16Veröffentlicht v0.6.1 · Chain 16 · 28 Sept 2026
Constraint Set 7 und eine neue Genesis
- Constraint Set 7, ein Hard Fork: jeder LogUp-Terminal geblendet und jede Tabelle auf 128 Zeilen aufgefüllt, sodass ein Proof seine 34 öffentlichen Werte offenlegt und nichts darüber hinaus; 32-Bit-Bereichsprüfungen auf Eingabewörtern; gesalzene Verifier-Schlüssel; der In-Circuit-Verifier der Recursion-VM.
- Chain 16, live am 28. September 16:39 UTC mit dem verzweigungsfreien Bundle-Guest und hardening_v6: 26 Validatoren mit je 1.000 RAND, alle vom Gründungsteam betrieben, ein Quorum von 18; die 10 zUSD übernommen, gedeckt durch 9 USDT auf Tron und 1 auf Solana; ohne Aggregationsabschnitt.
- Auf den Chains 14 und 15 verriet ein Transfer-Proof, ob RAND oder ein Token bewegt wurde, sowie einen Fingerabdruck der ausgegebenen Notes, und ein Call-Proof ließ das Erraten von Eingaben mit niedriger Entropie zu; Chain 16 schließt beides.
- v0.6.2Veröffentlicht v0.6.2 · 29 Sept 2026
Delegiertes Proving, Phase 1
- rand-prover und rand-node run --prover: ein abgeschotteter Proving-Dienst, den der Besitzer einer Wallet betreibt, damit eine Browser-Erweiterung oder ein Telefon ohne 8 GB Speicher senden kann. Jobs werden mit ML-KEM-768 und ChaCha20-Poly1305 versiegelt, der Witness wird genullt, und die Wallet prüft den zurückgegebenen Proof selbst.
- Phase 1 übergibt dem Prover den Spend-Schlüssel, daher bedeutet das Delegieren eines Proofs die Übergabe der Verwahrung: Koppeln Sie nur eine Maschine, die Sie selbst betreiben. Am 29. September auf alle 26 Nodes ausgerollt; auf Chain 17 durch geteilte Autorisierung (v0.6.3) abgelöst.
- Das Clients-Release v0.6.5 koppelt einen Prover aus den Einstellungen, und die Desktop-App kann selbst einer sein.
- v0.6.3 · v0.6.4 · Chain 17Veröffentlicht v0.6.3 · v0.6.4 · Chain 17 · 29 Sept 2026
Delegiertes Proving, Phase 2: geteilte Autorisierung und eine neue Genesis
- Der Bundle-Proof benötigt den Spend-Schlüssel nicht mehr. Die Wallet erstellt selbst einen kleinen Autorisierungs-Proof (Tier 10, etwa 7 s, 1,36 MB), und jeder gekoppelte Prover darf den aufwendigen Bundle-Proof aus dem Viewing Key erstellen: Er kann den Verlauf dieser Wallet lesen, aber nicht ausgeben. Ein Prover darf eine Gebühr in RAND nennen, bezahlt als ein Shielded Output innerhalb derselben Transaktion; die Wallet begrenzt sie (standardmäßig 1 RAND).
- Ein Hard Fork, also eine neue Genesis: Chain 17 live am 2026-09-29 03:03 UTC, erstellt aus einem Snapshot von Chain 16 mit denselben 26 Validatoren, die 10 zUSD und ihre Deckung übernommen; das Proof-Limit beträgt 4 MiB, sodass ein Block Platz für drei Proofs hat. Ein Transfer trägt nun etwa 2,85 MB an Proofs, sieben pro 20-MiB-Block. v0.6.4 ist der Launch-Datensatz.
- Gemessen am 29. September: ein v3-Bundle-Beweis in 102 s lokal, in 108–111 s über einen gekoppelten Prover; ein fremder Prover hat einen Versand von 5 RAND Ende zu Ende bewiesen.
- v0.6.6Veröffentlicht v0.6.6 · 29 Sept 2026
Gas: Bezahlung pro Instruktion in RAND (Constraint-Set 8), gebaut für Chain 18
- Die zkVM misst jeden Lauf im Schaltkreis (eine Gas-Spalte, ein öffentlicher Wert); ein Aufruf deklariert ein Gaslimit und bezahlt es zu den Gas- und Byte-Preisen der Chain, und im dynamischen Abschnitt bewegen sich die Preise einmal pro Block mit der Auslastung. Jedes Bundle deklariert das festgelegte Limit von 20.479.
- Constraint-Set 8 ändert jeden Verifier-Schlüssel und konnte deshalb nur auf einer neuen Chain laufen. v0.6.6 wurde getaggt und nie als getaggt ausgeliefert: Sein Inhalt erreichte am selben Tag eine Chain, zusammen mit v0.6.7-rc1, aufgesetzt auf die geteilte Autorisierung.
- v0.6.7 · Chain 18Veröffentlicht v0.6.7 · Chain 18 · 29 Sept 2026
Chain 18: Gas-Messung und das verschlüsselte Memo, live
- Chain 18, am 29. September um 04:56 UTC auf v0.6.7-rc1 geschnitten und Knoten für Knoten auf v0.6.7 ausgerollt: die erste Chain mit Gas-Messung (Constraint-Set 8), mit geteilter Autorisierung seit Chain 17 und dem 1.860 Byte großen Note-Umschlag, der ein verschlüsseltes Memo trägt. 26 Validatoren mit je 1.000 RAND, ein Quorum von 18, Beweise bis 4 MiB. RAND-Guthaben und die 10 ausstehenden zUSD wurden im Genesis übernommen.
- Ein vertraulicher Aufruf deklariert jetzt ein Gaslimit, das der Schaltkreis durchsetzt, und bezahlt dafür und für seine Bytes zu Preisen, die sich mit jedem Block bewegen. Vier am 30. September gemessene Aufrufe kosteten zwischen 0,0057 und 0,0075 RAND.
- Vier Beispielprogramme wurden am 30. September auf Chain 18 bereitgestellt und aufgerufen: eine anonyme Abstimmung über eine Keccak-Allowlist, ein Nachweis der Verbindlichkeiten über einen SHA-256-Summenbaum, ein zwischen Aufrufen weitergereichtes Off-Chain-Hauptbuch und eine private Kreditentscheidung aus einem veröffentlichten Modell.
- v0.6.7 · Chain 19Veröffentlicht v0.6.7 · Chain 19 · 1 Oct 2026
Chain 19: noch einmal Chain 18, mit den neu bereitgestellten Bridge-Endpunkten
- Chain 19 ging am 1. Oktober um 03:43 UTC live, von Chain 18 bei einem Snapshot der Höhe 141.935 abgeleitet und auf demselben v0.6.7-Build von denselben 26 Validatoren betrieben. Jede Regel und jedes Limit entspricht Chain 18; das Genesis nennt die am 30. September neu bereitgestellten Bridge-Endpunkte für Ethereum, BNB Chain und Tron.
- Betreiber-Wallets und das überbrückte zUSD wurden übernommen. Programme werden bei einem Schnitt nicht übernommen, daher wurden die vier Beispielprogramme auf Chain 19 erneut bereitgestellt. Der Prover-Pool der Validatoren unter prover.randprotocol.org beweist für Chain 19.
- Rand Wallet v0.6.7 wurde am selben Tag für Chain 19 veröffentlicht: Der Kern jedes Clients bindet fullnode v0.6.7 ein und lehnt jede andere Chain ab, und die Version der Wallet entspricht nun der des Knotens.
- v0.6.8 · Chain 20Veröffentlicht v0.6.8 · Chain 20 · 1 Oct 2026
Chain 20: Programmzustand, Bridge-Gebühren und die letzten Korrekturen aus Audit v6
- Chain 20 ging am 1. Oktober um 06:17 UTC auf v0.6.8 live, ein Hard Fork vom Zustand von Chain 19 bei Höhe 7.258, von denselben 26 Validatoren in einem Gesamtstopp ausgerollt. Jeder Beweis und jede signierte Nachricht ist nun an das Genesis der Chain gebunden, sodass nichts, was für eine Chain erstellt wurde, auf einer anderen verifiziert wird, und eine Wallet zum Senden v0.6.8 benötigt.
- RPL-2: Ein Programm kann Zustand in Zellen halten und einen Tresor führen, und ein Invoke liest und schreibt sie in einem bewiesenen Schritt, zu 0,01 RAND pro neuer Zelle. zUSD zahlt in jede Richtung eine Bridge-Gebühr von 0,1 %, in zUSD, an eine Treasury-Note, und die Verwahrung entspricht weiterhin dem Angebot.
- Der Rest von Audit v6: Die Konsens-Sperre wird nicht mehr automatisch aufgehoben (CON-4), und Views schreiten über Timeout-Zertifikate voran (CH-1); ein öffentlicher RPC-Listener mit festem Methodensatz; Obergrenzen für Gaspreise; Validatoren, die per Abstimmung zugelassen werden; Guardian-Rotationen, die Besitz und einen Tag Verzögerung erfordern.
- Wallet v0.6.8 · Chain 20Veröffentlicht Wallet v0.6.8 · Chain 20 · 1 Oct 2026
Rand Wallet v0.6.8: Die Apps senden auf Chain 20
- Der Kern jeder App bindet nun fullnode v0.6.8 ein und bindet, was er beweist und signiert, an das Genesis von Chain 20, sodass die Wallets für Smartphone, Desktop und Browser wieder auf Chain 20 senden. Eine Wallet nutzt für den Bundle-Beweis standardmäßig den Prover von RandProtocol; ein eigener Prover bleibt die private Wahl.
- v0.8.0 · Chain 21Veröffentlicht v0.8.0 · Chain 21 · 12 Oct 2026
Chain 21: Constraint Set 9, verbrannte Gebühren, Perps und Multisig
- Chain 21 ging am 12. Oktober um 10:31 UTC auf der Fullnode v0.8.0 live, als Hard Fork von Chain 20 (mit ihrem Bridge-Zustand aus dem Snapshot bei Höhe 814,702 und den Guthaben der Operator-Wallets), von denselben 26 Validatoren gemeinsam angehalten und neu gestartet. Die zkVM nutzt Constraint Set 9, Merkle-Spans im Recursion-Verifier und einen Chip für die Dilithium2-Arithmetik; daher haben sich alle Verifier-Schlüssel und die Proof-Kodierung geändert: v0.8.0 lehnt die Chains 18 bis 20 ab, und eine Wallet benötigt v0.8.0, um zu senden.
- Der Gebührensockel jeder Transaktion wird jetzt verbrannt, statt an den Proposer gezahlt zu werden, der nur das Trinkgeld behält. RPL-3 Perpetual Futures: ein Markt, BTC-PERP, in zUSD abgerechnet bei 20× Hebel, mit einem Prover außerhalb der Chain. Multisig-Konten: M-of-N-Dilithium2-Schlüssel über einem öffentlichen Guthaben, 1 RAND zur Erstellung; die Treasury der Stiftung, 100,000 RAND hinter 2 von 3 Schlüsseln, ist das Genesis-Konto. Privates Multisig: eine M-of-N-Richtlinie, die als Autorisierung eines Bundles auf Tier 18 bewiesen wird, sodass die Chain nur erfährt, dass ein Multisig signiert hat. Proofs dürfen 6 MiB groß sein.
- Änderungen nur am Node seit v0.6.8: signierte, per CI gebaute Releases ab v0.7.0; Beweiserzeugung auf jedem Kern oder der GPU ab v0.7.1; Compact Blocks, ein Start-Checkpoint, ein Verify-Cache und das Anwenden von Blöcken außerhalb der Hauptschleife in v0.8.0; Scan-Heads senken die Sync-Bytes einer Wallet um das 2,26-Fache. Die rand-Kommandozeile aus dem Release v0.8.0 sendet auf chain 21, ebenso Rand Wallet v0.8.0, siehe unten.
- Wallet v0.8.0 · chain 21Veröffentlicht Wallet v0.8.0 · chain 21 · 12 Oct 2026
Rand Wallet v0.8.0: Die Apps senden auf chain 21 und signieren für eine private Multisig
- Der Kern jeder App bindet nun fullnode v0.8.0 ein, sodass die Wallets für Smartphone, Desktop, Erweiterung und Web auf chain 21 senden; die 0.7.x-Apps lehnen sie ab, und v0.8.0 lehnt chain 20 ab. Schlüssel, Adressen und Viewing Keys bleiben erhalten, und eine Wallet, die chain 20 gescannt hat, scannt nach einem Hinweisbanner erneut ab dem Genesis von chain 21. Jede App kann einen privaten Multisig-Vorschlag mit ihrem eigenen Dilithium2-Schlüssel signieren und prüft vor dem Signieren den Zahlungsempfänger.
- als Nächstes SchätzungGeplant als Nächstes · 19 Oct 2026 (Schätzung)
Die Beispielprogramme auf chain 21 und der letzte Test der Aggregation
- Schätzung. Die vier Beispielprogramme, erneut auf chain 21 bereitgestellt; der Test mit einem gefälschten Aggregat, auf den die Blockaggregation noch wartet.
Mit „Schätzung“ markierte Termine sind Pläne, keine Zusagen. Die Dokumentation beschreibt, was heute im testnet läuft.