Im Lieferantenvergleich von Rayls gibt es neun Zeilen, und ich habe die Zeile „Datenschutz“ ausgewählt. Der Grund ist ganz einfach: Datenschutz ist wichtig, und Besu ist Open Source—seine Dokumentation und seinen Code kann ich nachschlagen.
Im Vergleichsblatt setzt Rayls in den beiden Zeilen „isolationsernder Datenschutz“ und „kryptografischer Datenschutz“ jeweils ein Häkchen, während Besu nur in der ersten Zeile ein Häkchen hat. Ich wollte das in der eigenen Dokumentation des jeweiligen Anbieters verifizieren, also habe ich die Dokumentation von Besu nachgeschlagen und dann seinen Code heruntergeladen und die Zahlen durchgezählt.
Die Schlussfolgerung lautet nicht „Besu geht nicht“. Der wirkliche Unterschied ist: Diese beiden Anbieter setzen den Datenschutz auf unterschiedliche Ebenen, und Besu hat den Zeitpunkt dafür viel früher verlagert, als viele Menschen denken.
Auf der Besu-Seite: von der Doku zum Code
In der offiziellen Besu-Dokumentation hängt oben auf den Seiten mit Privacy-Bezug jetzt dieselbe Banner-Notiz: Privacy-Funktionen basierend auf Tessera sind seit Version 24.12.0 obsolet bzw. werden abgekündigt.
Die echte Entfernung geschieht in 25.6.0. In den Release Notes dieses Releases wird das als „Breaking Change“ aufgeführt: das Entfernen der Tessera-Privacy-Funktionen, Eintrag #8369. In derselben Serie wurde außerdem das On-Chain-Rechte- und Berechtigungsmanagement entfernt.
Der Teil, den ich selbst verifiziert habe, sieht so aus: Ich habe zuerst mit drei Versionsnummern dieselbe Datei abgefragt: In 25.4.0 geben sowohl PrivateTransaction.java als auch Enclave.java 200 zurück; in 25.6.0 und 26.2.0 geben sie 404 zurück. Danach schaue ich auf die Schnittstellen: In 25.4.0 enthält das RpcMethod-Enum 23 Methoden, die mit priv_, eea_ oder privx_ beginnen; in 26.2.0 sind in derselben Datei keine davon. Auch in der Kommandozeile ist es genauso: In 25.4.0 gibt es 12 Startparameter, die mit --privacy beginnen; in BesuCommand.java von 26.2.0 kann man nicht einmal das Wort „privacy“ finden. Vom Maßstab her: In 25.4.0 gibt es 153 nicht-Test-Java-Dateien, die mit Privacy und enclave zusammenhängen – insgesamt 17.875 Zeilen.
Warum Besu das so machen will
Dieser Abschnitt muss geschrieben werden, sonst wird es nur Herumnörgeln.
In einer Bekanntmachung vom 24. September 2024 haben die Besu-Maintainer die Gründe genannt: Der Codebase wird zu einem überladenen Schweizer Taschenmesser; Tessera-ähnliche Funktionen reichen in genau den Szenarien, für die es ursprünglich gedacht war, von der Performance her nicht aus, und in der Anwendungsschicht gibt es bereits ausgereifte sowie neue Lösungen. In der Mitteilung wird außerdem erwähnt, dass ein quelloffenes, EVM-fokussiertes Projekt für programmierbare Privacy bald an das LF Decentralized Trust Lab übergeben werden soll.
Das Projekt ist Paladin. Es ist inzwischen vom Labor zu einem offiziellen Projekt von LF Decentralized Trust aufgestiegen; es hat die Apache-2.0-Lizenz und realisiert Privacy auf zwei Arten: mit Zero-Knowledge-Beweisen oder mit Vorabvalidierung durch die Emittenten. Es läuft auf jeder EVM-Chain.
Also ganz genau: Besu hat die Privacy nicht aufgegeben – es hat die Privacy vom Client in die Anwendungsschicht verschoben.
Zwei Möglichkeiten, mit jeweils eigenem Preis
Der Ansatz von Rayls besteht darin, Privacy in das Protokoll zu integrieren: Enygma verschlüsselt Transaktionsinhalte mit AES-256, protokolliert Salden über Pedersen-Commitments und weist mit Groth16 nach, dass diese Rechnung stimmt – und nutzt dafür den normalen Transaktionspfad.
Den Preis dieser Straße kann man beziffern. In der vorherigen Nachricht habe ich die Proof-Generierung gemessen: In einer Single-Core-Umgebung dauert ein Proof bei einem anonymen Set mit 6 Personen 1,96 Sekunden pro Transaktion. Heute habe ich noch etwas anderes gemessen: Der Proof selbst hat nur 164 Bytes, und er ist bei 2 Personen und 6 Personen genauso groß, weil die Groth16-Proofs eine feste Länge haben. Aber die gemeinsam mit dem Proof veröffentlichten öffentlichen Daten sind nicht konstant: Bei 2 Personen sind es 588 Bytes, bei 6 Personen 1.612 Bytes.
Diese Zahl korrigiert nebenbei ein verbreitetes Missverständnis. Nicht nur „ein Proof“ verlässt die private Umgebung, sondern auch der verschlüsselte Payload, der Proof und die dafür notwendigen öffentlichen Daten: Der Inhalt bleibt verborgen, während das System weiterhin verifizieren und abrechnen kann.
Nebenbei zu einer anderen Zeile der Vergleichstabelle: Rayls setzt ein Häkchen bei „isolierter Privacy“, basierend auf der Deployment-Struktur. Das Sovereign-Ledger jeder Institution liegt innerhalb der eigenen Begrenzung; laut Aussage auf der Website verlassen private Daten diese Instanz nicht – nur der minimale Payload, der für das Ausführen einer Transaktion zwingend erforderlich ist, wird ins externe Netzwerk gesendet. Deshalb sind es für Rayls zwei Schichten: zwischen Institutionen sorgt Deployment-Isolation, und institutsübergreifendes Settlement passiert über Kryptographie. Ich habe dazu nur Website und Dokumentation angesehen, aber kein reales Deployment durchgeführt.
Auch die Lizenzfrage muss man offenlegen: Rayls’ Open-Stack ist Apache 2.0, aber die beiden Module Enygma und Axyl sind BUSL 1.1; Tests sind kostenlos, für Produktion braucht es eine Lizenz. Nach vier Jahren ab Veröffentlichung jeder Version wird es automatisch zu Apache 2.0. Paladin ist Apache 2.0.
Was bedeutet das für eine Institution?
Wenn das private Netzwerk einer Institution auf Besu läuft und die Schnittstellen priv_ oder eea_ genutzt werden, dann ist der Schritt auf 25.6.0 keine Upgradeschritte, sondern eine Migration. 23 Schnittstellen und 12 Startparameter verschwinden gleichzeitig; die Privacy-Logik muss in die Anwendungsschicht verlagert und neu geschrieben werden. Wenn nicht, kannst du nur bei der 25.4er-Familie bleiben – und danach haben dich weder alle Performance-Verbesserungen noch alle Security-Fixes etwas zu berühren.
Wenn du Rayls wählst, dann gehören Privacy und Ledger zusammen: Versionierung, Audit und Support liegen auf einer Linie – du musst nichts selbst zusammenbauen. Der Preis ist: Jede geheime Transaktion muss erst den Proof berechnen; je größer der anonyme Set, desto mehr öffentliche Daten fallen an – und außerdem muss der Enygma-Teil nach BUSL lizenziert werden.
„Je mehr“ – wie viel genau? Das kann man ungefähr abschätzen; hier ist meine Rechnung: Ein geheimer Transfer mit einer 6-Personen-Confidential-Transaktion (6er-Set) – das Proof- plus öffentliches Datenmaterial beträgt insgesamt etwa 1.776 Bytes. Nimmt man die Größenordnung von 210.483 CHAPS-Transaktionen pro Tag im Jahr 2025 in England als Basis, ergibt das pro Tag rund 374 MB und pro Jahr rund 136 GB. Für den Speicher einer Institution ist das nicht besonders viel, aber es ist ein fixer Overhead, der linear mit der Anzahl der Transaktionen wächst, und der anonyme Set ist einstellbar: Bei 2 Personen pro Set sind es pro Transfer nur 752 Bytes. Dabei gehe ich davon aus, dass pro Transaktion nur ein Proof entsteht; ich habe das Ein-/Aus- und DvP-bezogene Schaltungszeugs nicht mitgerechnet.
Aus dieser Zeile lassen sich nur drei allgemeine Wörter herausziehen: In welcher Schicht. Frage an den Anbieter: In welcher Schicht sitzt die Privacy-Funktion, wer pflegt sie, wie ist ihre Lebensdauer, und sind die Ledger- und die Datenschutzlogik miteinander gekoppelt. Die Änderungen bei Besu in den letzten zwei Jahren zeigen: Die Antwort wird sich ändern – und die Änderungen sind zerstörerisch.
Was ich bestätigt habe, und was ich daraus abgeleitet habe
Bestätigte Teile: ob Dateien in unterschiedlichen Versionen existieren oder nicht; die Anzahl von Schnittstellen und Startparametern; der Inhalt von offiziellen Bekanntmachungen und Release Notes; die Byteanzahl von Proofs und öffentlichen Daten; die Dauer des Proofs aus der vorherigen Zeile. All das kann man anhand der Befehle in den Screenshots erneut ausführen.
Schlussfolgernder Teil: Ein Upgrade würde bestehende Privacy-Services unterbrechen – das habe ich daraus abgeleitet, dass die entsprechenden Schnittstellen verschwinden. Ich habe nicht wirklich ein privates Netzwerk von 25.4 auf 25.6 hochgezogen, um es zu testen. Ob Paladin konkrete Szenarien für eine bestimmte Institution abfangen kann, habe ich ebenfalls nicht evaluiert.
Vom Umfang her habe ich nur die Zeile zu Transferschaltungen und Privacy betrachtet. Besu-Nutzer können ihre eigenen Forks pflegen oder Plugins schreiben – das ist durch seine Lizenz erlaubt. Die anderen acht Zeilen der Vergleichstabelle habe ich nicht angefasst.
Meine Einschätzung
Die Vergleichstabelle ist eine statische Momentaufnahme, während sich die Fähigkeiten Open-Source-technisch bewegen. Innerhalb von zwei Jahren wurde aus „client-integriert“ eine „in die Anwendungsschicht verlagert und dort selbst zu betreiben“ – die Tabelle kann aber nur genau ein Häkchen anzeigen.
Deshalb ziehe ich es vor, solche Tabellen als Startpunkt für Checklisten zu sehen: Jede Zeile sollte man kurz in deren Repository des Gegenübers gegen die aktuelle Version prüfen. Die dafür aufgewendete Zeit liegt unter einer Stunde; die Befehle sind in den Screenshots enthalten. Beim nächsten Rayls-Update dieser Tabelle lohnt es sich besonders zu schauen, ob sie für die Besu-Zeile Versionshinweise ergänzt haben.
Referenzen: Rayls-Website, Sovereign-Produktseite und Vergleichstabelle der Anbieter; offizielles Besu-Dokument – Privacy-Kapitel mit dem Banner zur Abkündigung; Besu 25.6.0 Release Notes, Eintrag #8369; LF Decentralized Trust Bekanntmachung vom 24. September 2024 (Sunsetting Tessera and Simplifying Besu) sowie die Bekanntmachung zum Paladin-Projekt; hyperledger/besu-Repository mit den drei Tags 25.4.0, 25.6.0 und 26.2.0 (abgelesen am 24. September 2026); raylsnetwork/rayls-sovereign-gnark-api commit 67c4c26 (lokal getestet).