Ich habe mit dem Staken von RLS bereits in der Phase der zugesicherten Vorbereitungen begonnen; offizielle Blogs zu lesen ist für mich mittlerweile Gewohnheit. Am 12. September gab es in diesem Beitrag über Nachprüfbarkeit einen Teil, in dem sechs Kriterien aufgelistet wurden—dort heißt es, dass die Mathematik alles durch Konstruktion vollständig erzwingt. Ich stimme dem zu, aber „vollständig durch Konstruktion erfüllt“ ist eine überprüfbare Aussage, kein nur zu glaubendes Argument. Deshalb habe ich eine Woche lang jede der sechs Punkte einzeln in öffentlich verfügbaren Quellcodes, technischen Dokumentationen und On-Chain-Schnittstellen nach den entsprechenden Belegen gesucht. Jetzt teile ich das mit euch.
Zuerst zu seiner Einordnung: Ich finde, das ist hilfreicher als die meisten Diskussionen darüber, ob Privatsphäre „entweder vorhanden oder transparent“ sein soll. Für Nachprüfbarkeit gibt es drei Wege: mathematisches Erzwingen—die Bedingungen sind in kryptografischen Konstruktionen enthalten; Hardware-Vertrauen—dabei geht es um die Integrität vertrauenswürdiger Ausführungsumgebungen; und Richtlinien-Zugriffskontrolle—wer was sehen kann, wird von den Konfigurationen des Betreibers bestimmt.
Daraus leitet es sechs standardspezifische Kriterien für institutsebene prüfbarkeit ab und sagt dann, Mathematik erzwinge die Erfüllung all dieser sechs Kriterien durch Konstruktion.
Damit ich nicht immer nur wage rede, setze ich unten ein festes Szenario: Eine Bank nimmt an einem Pilotprojekt für die CBDC teil, und der Zentralbank-Prüfer soll die Transaktionen dieser Bank im Netzwerk einsehen. DREX aus Brasilien ist genau dieses Szenario, Rayls pilotiert gerade dort. Zu beantworten gibt es nur eine Frage: Warum sind die Dinge, die der Prüfer sieht, vertrauenswürdig?
Erste und zweite Regel: selektive Offenlegung und Reichweitenbegrenzung
Der Zielpunkt dieser beiden Punkte ist derselbe: der Beobachtungsschlüssel.
Rayls’ GitHub ist öffentlich; im cryptography-Verzeichnis des relayer-Repository gibt es eine Datei mlkem.go. Darin verwendet GenerateSalt die Beobachtungsschlüssel-Encapsulation des Empfängers (ML-KEM-768), um ein Shared Key zu teilen; RecoverSalt entkapselt lokal mit dem Beobachtungsschlüssel-Private-Key (ML-KEM-768). Genutzt werden die Go-Standardbibliotheksfunktionen NewEncapsulationKey768 und NewDecapsulationKey768. Die Variablennamen sind genau view public key und view secret key.
Damit ist das kryptografische Fundament für den Beobachtungsschlüssel ML-KEM-768—und diese Aussage ist belegbar.
Noch eine Sache zur Bedeutung: In dem Artikel vom 30. August über Quanten-Vorbereitung hat Rayls ausdrücklich betont: Wenn eine „quanten-sichere“-Behauptung nicht auf Parameter-Ebene formuliert ist, ist es keine Aussage, sondern nur ein Etikett—und die Beispiele, die genannt werden, sind genau nicht dasselbe: ML-KEM-512 und ML-KEM-1024. In dem Artikel über sein eigenes Upgrade steht nur: „ersetzt durch ML-KEM“. Im Code steht es: 768. Das ist kein Mangel—768 ist ein offizieller NIST-Parameterwert und auch die empfohlene Default-Einstellung für Unternehmens-Deployments. Es ist lediglich eine Tatsache, die man zuvor nur durch Lesen des Codes wusste, jetzt aber direkt zitieren kann.
Da die Stufen feststehen, lässt sich die Umstellungs-Kostenrechnung machen. FIPS 203 legt die Größen fest: Ein 768-Encapsulation-Public-Key hat 1184 Bytes, der Ciphertext 1088 Bytes; 1024 für beides ergibt 1568 Bytes.
Der entscheidende Punkt ist die Frequenz, und das steht auch im Key-Management-Dokument: Die Encapsulation wird für jedes Paar von Teilnehmern beim Aufbau des Netzes genau einmal durchgeführt; der Chiffretext wird im privaten Netzwerk-Hub gespeichert. Danach trägt jede Nachricht nur noch ein kleines Tag. Daher wächst es nicht mit der Transaktionsmenge. Ein Netzwerk mit 30 Institutionen hat 435 Paare; zwischen zwei Stufen (zwei Klassen) beträgt die Differenz etwa 215 KB; selbst bei 60 Institutionen und 1770 Paaren liegt die Differenz unter 1 MB und ist einmalig.
Diese Menge ist so klein, dass sie bedeutungslos ist—und genau das ist die Schlussfolgerung: Wenn ein Deployment eine höhere Stufe benötigt, kommt der Widerstand nicht von Bandbreite oder Speicher; dann ist es schlicht ein Code-Change. In allgemeinen Debatten zur Post-Quantum-Migration sind die Parameterentscheidungen oft Performance-Trades—aber hier geht es auf dieser Ebene nicht darum.
Auf diese eine Einschränkung beschränkt: Die technische Dokumentation ergänzt die andere Hälfte: Beobachtungsfähigkeit kann zeitfenster- und kontoabhängig eingeschränkt werden.
Dritte Regel: Trennung von Sichtbarkeit und Berechtigungen
Die Formulierung der technischen Dokumentation ist härter als die im Blog: Ausgabeschlüssel und Beobachtungsschlüssel sind mathematisch unabhängig, man kann nicht aus dem einen auf den anderen schließen. In der Sicherheitsüberprüfung steht es noch direkter: Beobachtungsrechte und Ausgaberechte werden durch Kryptografie getrennt, nicht durch Konfiguration. Daher kann ein Konfigurationsfehler einmalig keine Lese- zu Schreibrechte machen.
Das Key-Management-Dokument korrigiert außerdem eine Annahme von mir. Auf Institutionsebene werden alle Schlüsselmaterialien von einer Komponente namens Cryptographic Trust Suite zentral verarbeitet—sie läuft innerhalb der eigenen Grenzen der Institution. Ein Relayer besitzt nie irgendein Schlüsselmaterial; er wird nur darum gebeten, die Verschlüsselung und Entschlüsselung stellvertretend vorzunehmen. Die Leseberechtigung der Prüfer kommt daher: Jede Institution verschlüsselt ihre eigenen Beobachtungsschlüssel mit dem öffentlichen Schlüssel des Betreibers und speichert zusammen mit einem Authentifizierungscode im privaten Netzwerk-Hub; das ist Teil der Aufzeichnungen der teilnehmenden Partei. Der Prüfdienst holt diese Daten beim Start zurück.
Hier gibt es einen Nebeneffekt, den ein Dokument selbst hervorhebt: Institutionen können auf dem Hub sehen, welche Teilnehmerdatensätze es gibt—also wissen sie auch, welche ihrer eigenen Dinge als lesbar gesetzt wurden. Dass Sichtbarkeit gewährt wird, ist an sich sichtbar.
Nebenbei: Diese Seite mit den drei Kategorien von Key-Tabellen bestätigt auch, was ich im Code gesehen habe: Signatur-Schlüssel auf secp256k1 mittels ECDSA, Beobachtungsschlüssel ML-KEM und Ausgabeschlüssel für Ausgaben auf BN254 über Baby JubJub. Dokument und Quellcode passen exakt zusammen.
Vierte Regel: verifizierbare Korrektheit
Dieser Blogbeitrag stützt sich auf Zero-Knowledge-Proofs; Rayls hat einen speziellen gnark-api-Dienst zur Generierung und Verifikation von Groth16-Beweisen.
Das Dokument zur Enygma-Transaktion lieferte einige konkrete Parameter, die sonst kaum jemand zitiert. Die Größe der Anonymitätsmenge (Anonym set) ist entweder 2 oder 6: Das heißt, jede Überweisung wird mit einer anderen Überweisung oder fünf Überweisungen zusammen verpackt, sodass Beobachter nicht unterscheiden können, wer der Initiator ist. Eine crossTransfer zeigt maximal auf 5 Ziel-Chains und transportiert 5 aufrufbare Aktionen. Die Atomizität eines Batches wird durch den Enygma-Vertrag im privaten Netzwerk-Hub garantiert: Er verifiziert erst den Beweis für den gesamten Batch; erst wenn irgendein Ziel „passt“, wird geprägtes Geld erstellt. (Im Sinne: Jeder Zielort wird nur dann minten, wenn der Batch insgesamt verifiziert ist.)
Noch ein operativer Preis: Die Dokumentation formuliert es ganz klar: Batchverarbeitung, Beweisgenerierung und Hub-Verifikation zusammen liegen im Bereich von Dutzenden von Sekunden, also muss man das so planen—nicht wie bei einer Untersekunden-Endgültigkeit innerhalb einer Institution. Verifizierbare Korrektheit ist nicht gratis; ihr Preis sind genau diese Sekunden.
Aber an dieser Stelle lohnt es sich, eine Formulierung gesondert hervorzuheben, weil sie vier Materialien betrifft.
Die technische Dokumentation sagt: Der Pedersen-Commitment „versteckt einen Wert und bindet außerdem den Committer an diesen Wert, sodass er ihn später nicht mehr ändern kann“, und betrachtet die Bindungsfähigkeit als Eigenschaft, die vorausgesetzt (als Grundlage) gilt. Der Quantenartikel aus dem August markiert diese Punkte als „keine Behandlung erforderlich“—also ist es von Haus aus quantenresistent. Im Code zeigt enygma_math.go, dass dafür zwei unabhängige Generatoren auf der BabyJubJub-Kurve genutzt werden: es berechnet v·G + r·H—das ist ein standardmäßiger und korrekter Pedersen-Konstruktion. Und die zwei wissenschaftlichen Papers von Rayls, IACR-Nummern 2025/1639 und 2025/1638, beschreiben das Wort, mit dem das ganze Design erklärt wird: „quantum-private“, also Quanten-Privatsphäre. Die Erklärung lautet: Ein Quantengegner kann nicht auf den Zahler, den Empfänger und den Betrag der Transaktion schließen. Das ist eine reine Behauptung über Vertraulichkeit.
Meine Lesart: In den vier Materialien ist nur die Wortwahl des Papers präzise. BabyJubJub ist auf dem BN254-Skalarmodul gebaut—damit gilt die Vertraulichkeit auch für Quantengegner; genau das ist der Teil, den das Paper behauptet. Die Bindungsfähigkeit hängt von diskretem Logarithmus ab—und genau dieser Teil ist nicht die behauptete Aussage des Papers.
Für eine Organisation, die einen nachweislich regelkonformen „Gegenangriff“ aushält, sind „Ein Quantengegner sieht meinen Kontostand nicht“ und „Ein Quantengegner kann keinen falschen Kontostand fälschen“ zwei unterschiedliche Dinge—und genau so werden sie in Dokument und Blog als ein und dasselbe behandelt. Das Paper begeht dieses Zusammenlegen nicht.
Fünfte Regel: widerrufbar
Diese eine Stelle habe ich sehr lange gesucht: In den Rayls-Dokumenten gibt es eine Seite namens Dokument zu den Optionen für das private Netzwerk. Dort findet man die Antwort. Aber es ist nicht dasselbe wie das, was im Blog steht—und ich finde, es ist sogar spannender.
Der Prüfer ist eine vom Betreiber zugewiesene Rolle; parallel dazu gibt es auch Teilnehmer (Participating party) und Emittent. Entscheidend ist: Die Sichtbarkeit des Prüfers ist kein Schalter, sondern hängt an der Stufe. Dieses Dokument zeichnet die Stufe mit drei Beispielen nach.
In der Stufe für das Netzwerk der Zentralbank-Digitalwährung können Prüfer Transaktionen zwischen den Knoten entschlüsseln. In der Stufe für tokenisierte Vermögenshandelsplattformen überwachen Prüfer, indem sie die Pedersen-Zusagen verifizieren, die von den einzelnen Knoten an das Hub veröffentlicht werden; die Dokumentation sagt explizit, dass Prüfer keine direkten Zugriffsrechte auf die Daten verschlüsselter Transaktionen haben, sondern nur Beweise sehen, nicht den Inhalt. In der stufe des DAO-betriebenen NFT-Marktplatzes ist es am extremsten: Die Prüferrolle wird von einem Blockchain-Beweisprüfer (Proof Verifier) übernommen, standardmäßig ohne Zugriff; erst wenn die Beweisprüfung bei genau dieser Transaktion Betrug anzeigt, wird das Entschlüsseln für diese Transaktion aktiviert.
Drei Stufen werden nebeneinander gelegt; der Satz im Browser des Prüfers („Entschlüsselungsgrad ist in der Aufbauphase konfigurierbar“) ist genau dort umgesetzt.
Zurück zum Blog-Satz: Das Blog sagt, dass Sichtbarkeit zurückgenommen werden kann und dass der Rückzug durch Kryptografie erzwungen wird. Die Dokumentation liefert ein anderes Design: Sichtbarkeit wird beim Aufbau des Netzes nach Stufe festgelegt, nicht erst nachträglich zurückgezogen. Beides kann Prüfer einschränken—das eine ist eine Vorab-Bindung, das andere eine nachträgliche Streichung.
Es gibt tatsächlich Widerrufsmöglichkeiten auf der Governance-Ebene: Rollen können aktualisiert werden, der Status von Mitgliedern kann aktiv, eingefroren oder deaktiviert werden; das Einfrieren wird vom Betreiber über den ParticipantStorage-Governance-Vertrag ausgeführt. Aber den Widerruf der Sichtbarkeit, die ein Prüfer bereits erhalten hat, habe ich keine Umsetzungsbeschreibung finden können. Ein Detail macht dieses Problem sehr konkret: Die Dokumentation sagt, dass Prüfer bei jedem Hinzufügen eines neuen Knotens einmal einen Diffie-Hellman-Schlüsselaustausch erhalten; ihre Zugriffsrechte werden in Form von Schlüsselmaterial übergeben. Dass das Entziehen der Rolle zukünftige Zuweisungen blockieren kann, ist klar—aber ob man auch bereits übergebenes Schlüsselmaterial ungültig machen kann, untersuche ich noch.
Sechste Regel: Persistenz
Diese eine Stelle steht im Gegensatz zur fünften: Das Blog hat sich selbst zu leicht dargestellt.
Es sagt, Persistenz gehöre zum Key-Management und sei lösbar; beim Lesen wirkt es wie eine Lücke. Aber das Key-Management-Dokument hat dieses „lösbar“ in konkrete Lösungen übersetzt: Key Storage ist austauschbar in das, was eine Institution bereits nutzt: AWS KMS, Google Cloud KMS, Azure Key Vault, ein lokales HSM—im Entwicklungsumfeld nur lokale Dateien. Statisch läuft Envelope Encryption; was persistiert, sind Chiffretexte, nicht Schlüsselmaterial.
Das Wichtigste ist genau dieser Satz. Weil bei jeder Ver- und Entschlüsselung die Key-Management-Services der jeweiligen Institution durchlaufen werden, entstehen diese Audit-Spuren ohnehin. Das Überdecken der Rayls-Schlüsseloperationen ist damit wie das Überdecken irgendeines anderen Codes, den die Institution selbst ausführt. Die Schlussfolgerung der Dokumentation für die Compliance-Abteilung lautet: Dafür muss man keine neue Audit-Fläche aufbauen. Genau das ist es, was Persistenz erreichen will: Audit-Spuren hängen im eigenen System der Institution, nicht in den proprietären Logs eines Lieferanten.
Auch die Rotation ist sehr detailliert beschrieben: Jede Chain kann mehrere Signatur-Schlüssel haben; sie werden je nach Nutzung rotiert, jeder Schlüssel wird separat über einen Nonce nachverfolgt. Schlüssel, die für einen signierten, aber noch nicht abgeschlossenen (ausstehenden) Transaction bereits zum Signieren verwendet wurden, bleiben bis zur Abrechnung dieser Transaktionen gültig. Genau das schließt die Lücke, die bei Rotationen am leichtesten schiefgeht.
Aber es gibt eine Grenze: In der Sektion zur Rotation geht es um Signatur-Schlüssel; die Rotation der Beobachtungsschlüssel habe ich auf diesen Seiten nicht gesehen. Bei der Persistenz ist aber genau die Frage entscheidend, ob Jahre später noch Audit-Spuren lesbar sind—und das hängt stärker von der Beobachtungsseite ab.
Das Tool, das der Prüfer tatsächlich nutzt
Bisher ging es überall um Kryptografie, aber der Prüfer setzt sich am Ende mit einem Tool hin. Das Dokument sagt ausdrücklich, dass der private-netzwerk-Prüferbrowser nur vom Prüfer zugänglich ist, nicht vom Betreiber und auch nicht von anderen Teilnehmern; er liefert eine entschlüsselte Rückansicht (post view) für Cross-Chain-Transaktionen.
Eingeschränkter Umfang: Es deckt nur Cross-Chain-Transaktionen ab, deren Aufzeichnungen in das private Netzwerk-Hub gehen; Transaktionen innerhalb des eigenen Sovereign-Ledgers einer Institution können von den Prüfern nicht eingesehen werden. Daher ist die Sichtbarkeit für Prüfungen zwischen Institutionen, nicht innerhalb einer Institution.
Gibt es also ein Beispiel, das man vollständig verifizieren kann
Ja, und es gibt nur eine, weil die Architektur selbst bestimmt, dass die meisten Dinge nicht sichtbar sind.
Die offiziellen Dokumente erklären den Grund: Enygma-Transaktionen werden aus den Sovereign-Ledgern der jeweiligen Institutionen heraus versandt; jede Institution deployt selbst den Browser, der genau dieses Ledger überwacht. Der Cross-Chain-Teil liegt im privaten Netzwerk-Hub und wird dort vom Prüferbrowser eingesehen. Die Aktivitäten einer Institution liegen gemäß Design nicht auf der öffentlichen Chain; daher findet man Enygma-Transaktionen im öffentlichen Chain-Browser nicht. Das ist kein Defekt, sondern eine zwangsläufige Folge der Drei-Schichten-Architektur.
Aber der Parfin-Sperrvertrag liegt auf der öffentlichen Chain, und er ist genau ein vollständiges Beispiel für „Mathematik erzwingt“.
Das mit dem Anfang „0x1463889D“, der Contract-Name ist RlsTokenLock, der Quellcode ist verifiziert und es ist kein Proxy-Contract. Das bedeutet, dass es sich um eines der wenigen Objekte handelt, die man sowohl durch Code lesen als auch den aktuellen Status nachschlagen kann. Ich habe beide Seiten abgeglichen.
Der constructor deklariert totalAmount als 1.070.493.535 RLS. Der aktuell tatsächlich gehaltene RLS-Bestand im Contract ist 1.070.493.535. Absolut keine Abweichung—voll und ganz ausreichend.
Das Entsperr-Zeitdiagramm ist es, was man besonders erwähnen sollte. Im Konstruktor gibt es 48 Zeitstempel—ich habe alle decodiert: Die erste Stufe ist am 1. Dezember 2027; danach gibt es jeden Monat am 1. eine Stufe, die letzte am 1. November 2031. Die Spanne beträgt etwa 3,92 Jahre; pro Stufe etwa 22,3 Mio. RLS. Zuvor betonten öffentliche Materialien das Locking bis Dezember 2027—das ist die erste Stufe, korrekt; der komplette Zeitplan im Konstruktor zeigt jedoch, dass es nach der ersten Stufe fast vier weitere Jahre monatlicher Freigaben gibt.
Die eigenen Contract-Kommentare schreiben die Designabsicht ganz offen: nicht upgradebar; die Bedingungen bei Deployment sind für immer gültig—ohne vorzeitiges Entsperren kann kein Schlüssel eine Stufe vor dem Ablaufdatum verlassen. Diese beiden Punkte habe ich im Code einzeln gegencheckt: Der Zeitplan steht im constructor ohne Setter, und der Contract ist tatsächlich kein Proxy.
So sieht „Mathematik erzwingt“ in einem vollständigen, von mir verifizierbaren Beispiel aus: Die Aussagen stimmen mit dem Code überein, und der Code ist konkreter als die Aussagen. Von den sechs Standards gibt es Dinge, die ich nur als Spuren in Source und Dokument finde—hier kann man sie von Anfang bis Ende sehen.
Zwei weitere Stellen für externe Verweise
Als der Blog von TEE spricht, sagt er, dass es dokumentierte Schwachstellen gibt, bei denen Intel SGX die Garantie für geschützte Isolation gebrochen wurde. Dieser Punkt stimmt—aber er stellt sein eigenes Argument zu leicht dar. Zu den Isolations-Klassen gehören Foreshadow, Plundervolt, EPIC Leak, SmashEx mit den jeweiligen Nummern CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186 und CVE-2021-33767. Wirklich am schlimmsten ist jedoch SGAxe aus dem Jahr 2020: Es nutzte CVE-2020-0549, um aus einer Zertifikations-Enklave der Intel-Produktionsumgebung den Zertifizierungsschlüssel selbst herauszuziehen. Danach kann man beliebige Behauptungen signieren, die dann von Intels eigenem Attestierungsdienst als legitim eingestuft werden.
Die Argumentation im Blog lautet, dass die TEE-Garantie durch hardwareseitig ausgestellte Beweise bereitgestellt wird—und SGAxe knackt genau den Teil, der die Beweise ausstellt. Der schlimmste Fall eines Scheiterns war nicht, dass Daten gestohlen wurden, sondern dass die Garantie selbst gefälscht werden konnte. Um es fair zu formulieren: Das wurde durch Microcode-Updates und TCB-recovery behoben; heute ist SGX nicht mehr das SGX von 2018. Genau gesagt hat die Hardware-Trust-Ankerung eine Angriffsfläche, die sich im Laufe der Zeit „rollierend“ zeigt.
Eine weitere Stelle sagt, BIS’ Project Agora laufe auf dieselbe Architektur hinaus. Ich habe den BIS-Prototypbericht vom 27. Mai gelesen—topologisch sieht es tatsächlich ähnlich aus: eine Zwei-Ebenen-Struktur, ein gemeinsam genutztes Ledger plus jeweils unabhängige Ledger in jeder Zuständigkeits-/Jurisdiktionszone. Aber die Grenze bei Agora wird über Zuständigkeit (Jurisdiktion) gezogen; der Bericht erklärt nicht, wie Zugriffssteuerung innerhalb der Jurisdiktions-Ledger umgesetzt wird. Daher lässt sich aus den bestehenden öffentlichen Materialien nicht erkennen, ob die Konvergenz bis in die Trust-Model-Ebene reicht.
Was ist bestätigt, was ist meine Vermutung
Bestätigt: ML-KEM-768 wird für Beobachtungsschlüssel verwendet, siehe relayer/cryptography/mlkem.go; Pedersen konstruiert BabyJubJub mit zwei Generatoren, siehe enygma_math.go; der Prüf-Private-Key wird verschlüsselt durch den relayer ausgeteilt, siehe governance service/cryptography/service.go; Ausgabeschlüssel und Beobachtungsschlüssel sind mathematisch unabhängig; der Beobachtungsbereich kann nach Zeit und Konto eingeschränkt werden; der Browser des Prüfers deckt nur Cross-Chain-Transaktionen ab und der Entschlüsselungsgrad ist in der Aufbauphase konfigurierbar—alles siehe offizielle technische Dokumentation. Cryptographic Trust Suite hält die Schlüssel einheitlich und Relayer hält nie Schlüssel; Key Storage lässt sich austauschbar an KMS oder HSM anbinden; Envelope Encryption im statischen Modus; die Audit-Logs des Institution-eigenen Key-Management-Services sind die Audit-Spuren für Schlüsseloperationen; Signatur-Schlüssel werden nach Nutzung rotiert und Schlüssel, die für ausstehende, noch nicht abgerechnete Transaktionen signiert wurden, bleiben bis zur Abrechnung gültig; Encapsulation wird einmalig beim Aufbau des Netzes pro Teilnehmer durchgeführt; die Größe der Anonymitätsmenge beträgt 2 oder 6; eine crossTransfer zeigt maximal auf 5 Ziel-Chains; Finalität liegt im Bereich von mehreren Dutzend Sekunden; Einfrieren von Teilnehmern erfolgt per Governance-Vertrag ParticipantStorage durch den Betreiber—alles siehe offizielle technische Dokumentation. Der Verifikationsstatus von RlsTokenLock, die Nicht-Proxy-Eigenschaft, der 48er-Zeitplan, die deklarierte Menge und der tatsächliche Kontostand werden alle über den öffentlichen Browser-Interface am 12. September 2026 ausgelesen. Die SGX-Schwachstellennummern stammen aus CVE-Records und dem SGAxe-Paper. Die Struktur und Daten von Agorá stammen aus den öffentlichen BIS-Unterlagen.
Meine Vermutung: In den vier Unterlagen ist nur die Paper-Formulierung zu Pedersen präzise. „Grenzen werden durch Mathematik erzwungen“ beschreibt Ausführung und nicht Verteilung. SGAxe stützt stärker als Isolationslücken das Blog-Argument. In diesen drei Materialien steht das so nicht.
Nicht verifiziert: Das Post-Revocation-/Widerrufsmechanismus für die fünfte Regel. Ich habe in fünf Dokumenten nachgesehen—Key-Management, Browser der Prüfer, Enygma-Kryptografie-Grundlagen, Einfrieren von Teilnehmern, private Netzwerk-Designoptionen, private Netzwerk-Hub—und zusätzlich in zwei Code-Repositories für Relayer und Governance. Ich habe zwar die drei Stufenkonfigurationen der Sichtbarkeit sowie den Vergabemechanismus und Einfrieren/Deaktivieren der Teilnehmer gefunden, aber keinen Nachweis einer Umsetzung für den Widerruf bereits gewährter Sichtbarkeit „durch Kryptografie erzwungen“. Auch bei der langfristigen Rotation des Beobachtungsschlüssels habe ich nichts finden können; die Sektion zur Rotation in den Dokumenten beschreibt die Signatur-Schlüssel.
Zum Schluss noch eine Sache, die nichts mit der Technik zu tun hat
In derselben Woche, in der der Beitrag geschrieben wurde, gab das Offizielle bekannt, dass 55 % der Stufen der Token-Versperrung bis zum 15. September verlängert werden. Außerdem wurde gesagt, dass man während der Anpassung des Staking-Mechanismus frühe Unterstützer diesen Anteil an Erträgen weiter erhalten lässt; spätere Updates zu Staking und zur breiteren Token-Ökonomie inklusive Burn werden gesondert veröffentlicht.
Ich habe ab der Phase des Pre-Commitment hinterlegt und vollständig drei Monate lang mitgemacht. Ursprünglich endete die jeweilige Stufe am 9. September; in diesen Tagen sah ich in der Oberfläche, dass das Kontingent aufgebraucht war und ich nicht nachlegen konnte. Ich dachte zunächst, es sei ein Problem im Frontend. Jetzt zeigt sich: Das System wird gerade angepasst.
Das ist meine persönliche Einschätzung, keine Tatsachenbehauptung: In der Phase, in der das System umgestellt wird, wird man eher eine Verlängerung wählen als eine direkte Abschaltung, und man schreibt die Daten auch klar aus. Ich halte das für ein ehrliches Vorgehen. In der Übergangsphase ist das häufigste Risiko mehrdeutige Formulierungen; ein konkretes Datum bedeutet, dass die Laufzeit entweder eingelöst oder noch einmal neu erklärt werden muss.
Dies ist nur ein konkretes Ereignis; es ist keine Beurteilung über längerfristige Planungen. Ich prognostiziere keine Erträge und empfehle niemandem, auf dieser Grundlage Entscheidungen zu treffen.
Referenzquellen: Rayls offizieller Blog „Auditability without surveillance: why mathematical enforcement beats trusting the code“, 12. September 2026; Rayls offizielle technische Dokumentation: zwei Seiten zu Enygma-Kryptografiegrundlagen und Browser der privaten Netzwerk-Prüfer; GitHub-Organisation raylsnetwork: Repositories „rayls-sovereign-relayer“ und „rayls-sovereign-pnh-governance“; Rayls öffentliche Chain Browser explorer.rayls.com: Adressen und Smart-Contract-Schnittstellen, Datenabfragezeit 12. September 2026; NIST FIPS 203; CVE-Records 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 und SGAxe-Paper; BIS Project Agorá Prototypbericht othp110; IACR-Kryptografie-E-Prints 2025/1638 und 2025/1639; Rayls offizieller X-Account: 12. September 2026 Bekanntgabe.
