Ganz ehrlich: Als ich diese drei Abkürzungen zum ersten Mal nebeneinander gesehen habe, dachte ich, sie wären drei Antworten auf dieselbe Aufgabe – wer ist am schnellsten, wer am sichersten, man wählt einfach eine aus und fertig. Später habe ich verstanden, dass es, sie zusammen zu bewerten, ist wie die Frage: „Welches Werkzeug ist am besten – Hammer, Schraubendreher oder Schraubenschlüssel?“ Die Antwort hängt davon ab, ob du einen Nagel, eine Schraube oder eine Bolzenverbindung hast.
Die jeweils gelösten Probleme sind eigentlich drei, die man fälschlicherweise miteinander vermengt hat.
Das erste Problem lautet: Ich möchte beweisen, dass etwas wahr ist, aber die Daten, die man dafür braucht, sind sehr sensibel, und ich will sie dir nicht zeigen. Die Bank möchte gegenüber der Aufsicht darlegen: „Diese Transaktion ist rechtmäßig, die Genehmigungen sind korrekt und es gibt keine doppelten Posten“, aber sie möchte weder den Betrag noch die Zahlungsparteien in die Buchführung aufnehmen. Dieses Bedürfnis, dass das Ergebnis wahr ist, ohne die Daten offenzulegen, ist das Spielfeld von ZK. Der Clou daran ist, dass die Gewähr aus der Mathematik kommt und nicht aus „Ich verspreche dir, dass ich es dir zeige, aber du darfst es nicht sehen“; die Aufsicht oder ein Audit, das den Verifikationsschlüssel erhält, kann das Ergebnis prüfen, aber es kommt nicht an die zugrunde liegenden Daten. Der Preis ist ebenso real: ZK ist stark darin, Eigenschaften von Daten zu beweisen, aber es ist nicht gut darin, dass mehrere Parteien gemeinsam rechnen, obwohl jede Partei keine vollständigen Daten hat, und es ist rechenintensiver als Klartext.
Zweitens ist das ein anderes Problem: Ich kann die Daten grundsätzlich nicht entschlüsseln, aber ich muss trotzdem darauf rechnen. Zwei Institutionen machen „Wert gegen Zahlung“ (DvP), jede verschlüsselt ihre Vertragsbedingungen und reicht sie verschlüsselt ein. Das Abwicklungssystem muss dann beurteilen, ob die beiden Aussagen dieselbe Transaktion betreffen, ohne dabei irgend eine Seite zu entschlüsseln—und erst dann liefern. Das ist der Bereich von FHE: Man kann direkt auf dem Chiffretext rechnen und erhält ein Ergebnis als Chiffretext. Klingt nach Magie, aber es ist im Moment langsam—im Vergleich zu Klartext-Rechnung um mehrere Größenordnungen. Damit geht kein echtes Echtzeit-High-Frequency-Settlement. (Zama hat Ende 2025 gezeigt, dass das in bestimmten Szenarien funktioniert, aber „in spezifischen Szenarien einsetzbar“ ist noch weit entfernt von „im Größenmaßstab institutioneller Abwicklung einsetzbar“.) Es gibt auch noch ein noch komplizierteres Detail: In klassischem FHE verwaltet ein Schlüssel zugleich „wer sehen darf“ und „wer ausführen darf“. Man kann dem Audit nicht einfach nur Lesezugriff geben—das ist in einer regulierten Welt ziemlich unpassend.
Drittens ist es wieder ein anderes Problem: Ich will eine Logik ausführen—schnell muss sie sein—und ich darf dabei nicht zulassen, dass derjenige, der die Maschinen bereitstellt, sieht, was gerade berechnet wird. Eine Bank möchte auf gemeinsam genutzter Infrastruktur ihren eigenen privaten Matching-Engine-Logik laufen lassen und will nicht, dass sowohl die Gegenparteien als auch der Infrastrukturbetreiber die Logik selbst sehen. In so einem Fall nutzt man TEE: Man steckt den Code in eine Hardware-Blackbox im Prozessor—außen kommt niemand mehr ran und kann ihn auslesen. Der größte Vorteil ist die Geschwindigkeit: nahe an nativer Performance, komplexe Logik und große Datenmengen hält es aus. Aber es verlagert das Vertrauen: Man muss dem Chip-Hersteller vertrauen. Wenn Hardware-Schwachstellen auftauchen oder die Lieferkette passiv manipuliert wird, ist die Vertraulichkeit dahin (bei Intels SGX gab es dokumentierte Probleme). Außerdem ist es eine Blackbox: Man bekommt nur die Bestätigung „diese Code-Strecke ist wirklich gelaufen“, kann aber nicht unabhängig verifizieren, was sie konkret getan hat. Für Institutionen, die auf „nachweisbare Compliance“ Wert legen, ist diese Abhängigkeit ziemlich kritisch.
Sieht man das? Die Verben in den drei Problemen sind unterschiedlich: Eines ist Beweisen, eines ist Berechnen, eines ist Ausführen. Das als dasselbe in drei Begriffe aufteilen zu wollen, ist die häufigste Verwechslung.
Das wirklich Spannende ist also nicht „Welche Technik gewinnt“, sondern: „Hat ein konkretes Projekt, konfrontiert mit seinem eigenen Problem, die richtigen Werkzeuge gewählt?“ Enygma—also Rays' Privacy-Architektur—ist ein gutes Beispiel dafür, wie man ein Problem sinnvoll angeht.
Seine Handelsschicht baut auf ZK auf, mit quantenresistenzfähigem Schlüsselaustausch; homomorphe Operationen werden nur in den wenigen Fällen nach Bedarf verwendet, in denen wirklich „Berechnungen an vertraulichen Zahlen“ nötig sind; TEE geht nicht in die Handelsschicht. Das ist kein beiläufiger Standardwert, sondern eine wohlüberlegte Entscheidung. Es geht um verifizierbare selektive Offenlegung: Man kann gegenüber Aufsichtsbehörden nachweisen, dass ein Handel stattgefunden hat, dass er autorisiert war und dass die Abwicklung korrekt ist, ohne dabei Details unbeteiligten Dritten offenzulegen. Genau das löst ZK von Geburt an. Noch wichtiger: Seine Audits sind mathematisch erzwungen: Ein Schlüssel kann so begrenzt werden, dass er nur für eine bestimmte Aufsichtsbehörde oder einen bestimmten Gegenpartei einsehbar ist—man sieht nur den Teil, der autorisiert ist. Das ist keine Regel, die ein Administrator ändern kann, sondern eine kryptografische Einschränkung. Organisationen müssen sich nicht darauf verlassen, dass ein bestimmter Chip-Hersteller oder eine Plattform die Grenze durch Vertrauen „hält“.
Warum also kein FHE als Handelsschicht? Weil es derzeit die Performance nicht hergibt, die Institutionen für die Abwicklung brauchen; Enygma ist modular—wenn es reif ist, kann man es einbinden. Jetzt „hart draufsetzen“, um Abwicklungs-Performance gegen alles andere einzutauschen, führt eher zum Scheitern. Warum kein TEE? Für Institutionen dieser Art ist mathematische Gewissheit härter als Hardware-Vertrauen; das vertrauenswürdige Fundament kann man nicht an die Zertifizierung eines einzigen Chip-Herstellers auslagern.
Bezug auf den offiziellen Rayls-Blog: https://www.rayls.com/blog/the-privacy-stack-decoded-why-zk-fhe-and-encrypted-black-boxes-are-not-solving-the-same-problem
Danke für den Austausch von Rayls. Meine Erkenntnis ist: Wenn man das nächste Mal sieht, dass jemand ZK, FHE und TEE in eine Rangliste packt, kann man zuerst fragen: „Welches Problem willst du eigentlich lösen?“ Klarheit darüber, ob man beweisen, berechnen oder ausführen will—dann liegt die Antwort quasi schon auf der Hand. Und welche Bausteine eine Architektur auswählt (und bewusst weglässt), sagt oft mehr darüber aus, was sie wirklich erreichen will, als ihre Behauptung, sie „stapelt“ nur so viele fortschrittliche Technologien.
