Echte Anwendungen mit Zero-Knowledge-Proofs und FHE bauen 2026: Ein pragmatischer Guide

Zero-Knowledge-Proofs und Fully Homomorphic Encryption haben in den letzten zwei Jahren eine Linie überschritten. Apple lässt FHE auf Hunderten Millionen iPhones laufen. Google Wallet beweist dein Alter mit einem Zero-Knowledge-Proof. Einen ganzen Ethereum-Block zu beweisen dauert heute Sekunden, nicht Minuten. Und trotzdem scheitern die meisten Projekte, die mit "lass uns ZK nutzen" oder "lass uns FHE nutzen" starten, weil die Technologie nie die richtige Frage war. Dieser Guide ist das Entscheidungs-Framework, das wir anwenden, bevor wir einen einzigen Circuit schreiben: wann diese Tools Sinn ergeben, was sie 2026 kosten, und die fünf Arten, wie Teams damit Budget verbrennen.

Engineering-Perspektive, kein Vendor-Pitch. Jede Zahl unten ist belegt, und wo eine Zahl eine Hersteller-Projektion statt eines ausgelieferten Ergebnisses ist, sagen wir das. Die Referenzpunkte stammen aus Wavects Zero-Knowledge- und Frontier-Tech-Arbeit.

Was geben dir ZK und FHE, was normale Verschlüsselung nicht kann?

Standard-Verschlüsselung schützt Daten at rest und in transit. In dem Moment, in dem du mit den Daten etwas tun willst, entschlüsselst du sie, und wer die Berechnung ausführt, sieht alles. Privacy-Enhancing Technologies schließen diese Lücke, jede auf ihre Weise:

• Zero-Knowledge-Proofs (ZK) lassen eine Partei beweisen, dass eine Aussage wahr ist, ohne das Warum offenzulegen. "Ich bin über 18", ohne das Geburtsdatum zu zeigen. "Diese Berechnung lief korrekt", ohne sie erneut auszuführen. Bei ZK geht es um Verifizierbarkeit mit selektiver Offenlegung.
• Fully Homomorphic Encryption (FHE) lässt einen Server auf Daten rechnen, die er nicht lesen kann. Der Input kommt verschlüsselt an, die Berechnung läuft verschlüsselt, das Ergebnis geht verschlüsselt zurück. Bei FHE geht es um ausgelagerte Berechnung auf Daten, die der Betreiber niemals sehen darf. Die Grundlagen findest du in unserem Glossar-Eintrag.
• Secure Multi-Party Computation (MPC) lässt mehrere Parteien gemeinsam über Inputs rechnen, die keine von ihnen teilen wird, um den Preis von schwerem Netzwerk-Traffic zwischen ihnen.
• Trusted Execution Environments (TEE) führen Code in einer hardware-isolierten Enklave aus. Nahezu native Geschwindigkeit, aber du vertraust dem Chip-Hersteller und darauf, dass keine Side-Channel-Angriffe existieren.

Denk es als Vertrauensleiter. ZK verlangt, dass du nur der Mathematik des Proof-Systems vertraust. FHE verlangt, dass du der Kryptographie vertraust. MPC verlangt, dass du darauf vertraust, dass eine Mehrheit der Parteien ehrlich bleibt. TEE verlangt, dass du Intel, AMD oder NVIDIA vertraust. Eine gewöhnliche Datenbank verlangt, dass du dem Betreiber vertraust. Jede Sprosse nach unten ist schneller und günstiger. Die Engineering-Frage ist nie "was ist am sichersten", sondern "wie weit runter auf der Leiter lässt dich dein Threat Model gehen". Alle vier vergleichen wir ausführlich in ZK vs FHE vs MPC vs TEE.

Brauchst du das überhaupt? Erst den Entscheidungsbaum durchlaufen.

Der teuerste Fehler in diesem Feld ist kryptographischer Overkill. Bevor eine dieser Technologien in deine Architektur wandert, beantworte vier Fragen ehrlich:

1. Vertrauen dir deine User, dass du ihre Daten siehst? Wenn ja, und das Gesetz es erlaubt, nimm eine Datenbank, Access Control, TLS und Verschlüsselung at rest. Das ist kein Kompromiss, das ist die korrekte Architektur für die große Mehrheit aller Produkte. PETs lösen Vertrauensprobleme. Gibt es kein Vertrauensproblem, lösen sie nichts und kosten viel.
2. Muss eine dritte Partei etwas verifizieren, ohne die zugrundeliegenden Daten zu sehen? Alterschecks, Bonitätsnachweise, Credential-Prüfungen, "dieser Code lief korrekt". Das ist ZK-Territorium, und es ist die reifste der Optionen. Unser Deep Dive: was in ZK wirklich production-ready ist.
3. Muss eine nicht vertrauenswürdige Partei auf Daten rechnen, die sie niemals sehen darf? Ein Cloud-Service, der Gesundheitsdaten verarbeitet, ein Lookup gegen eine Server-Datenbank, der nichts über die Anfrage lernen soll. Das ist FHE- oder MPC-Territorium, und es funktioniert nur, wenn der Workload klein und klar definiert ist. Reality-Check: was in FHE shipped und was noch Hype ist.
4. Ist "wir können deine Daten nicht sehen" ein Kern-Produktversprechen oder eine regulatorische Anforderung, statt ein Nice-to-have? Ist es ein Nice-to-have, gibt dir ein TEE den Großteil der Story bei ungefähr nativer Geschwindigkeit. Ist es das Produkt, budgetiere für echte Kryptographie und das Engineering, das dazugehört.

Beachte das Muster: Die Technologiewahl fällt aus dem Trust Model heraus, nicht umgekehrt. Teams, die mit "wir wollen FHE nutzen" starten und danach ein Problem suchen, sind die, die in der Fehlerliste unten landen.

"Wenn deine User dir vertrauen, dass du ihre Daten siehst, schlägt eine Datenbank jedes Kryptosystem. Die interessanten Projekte sind die, bei denen dieses Vertrauen strukturell unmöglich ist."

Was läuft 2026 wirklich in Produktion?

Das ist kein Forschungsfeld mehr. Eine kurze Liste von Deployments, auf die du dein Board zeigen kannst, jedes mit einer Lektion dran:

Zwei Dinge stechen heraus. Erstens: Jedes erfolgreiche FHE-Deployment ist ein Private Lookup oder eine eng umrissene Berechnung, nie "unser ganzes Backend verschlüsselt laufen lassen". Zweitens: Die erfolgreichen ZK-Deployments verstecken einen einzigen sensiblen Fakt hinter einem Proof, sie versuchen nicht, eine ganze Anwendung zero-knowledge zu machen. Scope-Disziplin ist der gemeinsame Nenner.

Was kostet es? Die 2026er-Zahlen.

Daumenregeln, die wir in Architektur-Reviews nutzen. Das sind Größenordnungen zur Planung, die präzisen, belegten Zahlen stehen in den jeweiligen Deep-Dive-Posts:

Die Asymmetrie zählt mehr als die absoluten Zahlen. ZK ist einmal teuer für den Prover und danach für jeden Verifier fast gratis, weshalb es zu "einmal beweisen, überall verifizieren"-Produkten passt. FHE ist bei jeder einzelnen Operation teuer, weshalb es zu kleinen Berechnungen mit hohem Einsatz passt und noch zu nichts anderem. Wenn dir jemand FHE-Benchmarks zeigt, die zu gut aussehen, prüfe, ob da ein MPC-Paper zitiert wird. Diese beiden zu verwechseln ist der häufigste Fehler in Content über dieses Feld, und wir zerlegen ihn im FHE Deep Dive.

Auf welche fünf Arten scheitern diese Projekte?

Jede davon haben wir gesehen oder reviewt. Sie scheitern auf vorhersehbare Weise:

• 1. Kryptographie, wo ein Login gereicht hätte. Das Team shipped ZK-Proofs zwischen Services, die alle derselben Firma gehören. Es gibt keinen Gegner im Threat Model. Das Ergebnis ist ein langsameres, teureres System mit einem beeindruckenden Architektur-Diagramm. Wenn du dem Betreiber vertraust, nimm Access Control.
• 2. Under-constrained Circuits. Die dominante ZK-Schwachstellenklasse ist ein Circuit, der Proofs akzeptiert, die er ablehnen sollte, weil ein Constraint fehlt. Forschungs-Tooling wie zkFuzz fand 2025 Dutzende solcher Bugs, darunter elf in der weit verbreiteten zk-regex-Komponente von zkEmail (zkFuzz, arXiv 2025). Ein ZK-System ohne Circuit-Audits und Fuzzing ist kein Security-Produkt, es ist eine Haftung.
• 3. Trusted-Setup-Abkürzungen. Die ersten echten ZK-Exploits in freier Wildbahn waren keine exotische Mathematik, sondern schlecht gehandhabte Groth16 Trusted Setups (zkSecurity). 2026 brauchst du selten ein Trusted Setup pro Anwendung: Transparente Proof-Systeme (STARK-Familie) vermeiden die Zeremonie komplett. Nimm sie als Default.
• 4. Privacy-Tech, Consent-Versagen. Apple shipped Enhanced Visual Search mit wirklich starker Kryptographie (FHE plus Differential Privacy), schaltete es dann per Default ein, ohne die User zu fragen, und kassierte im Januar 2025 einen öffentlichen Backlash (The Register). Perfekte Mathematik ersetzt keinen Opt-in-Dialog. Regulierer und User beurteilen den Consent-Flow, nicht die Lattice-Parameter.
• 5. FHE für interaktive Workloads. Ein Overhead von 1.000x und mehr bedeutet: Alles, worauf ein User in Echtzeit wartet, ist außerhalb des Scopes, und verschlüsselter LLM-Chat ist Jahre von praktikabel entfernt. Teams, die das im Pitch Deck versprechen, tauschen später still ein TEE ein. Scope FHE auf Lookups, Matching, Scoring und Small-Model-Inferenz, wo es wirklich funktioniert.

Wie scopest du ein erstes Projekt, das den Kontakt mit der Realität überlebt?

Das Muster, das funktioniert, destilliert aus den Deployments oben:

1. Isoliere das eine Geheimnis, das zählt. Nicht "die App privat machen", sondern "der Server darf nie die Telefonnummer erfahren, die nachgeschlagen wird" oder "der Veranstaltungsort darf nie das Geburtsdatum erfahren". Ein Satz, ein Geheimnis, ein Verifier.
2. Leg nur das auf den teuren Pfad. Das Apple-Muster: 99 Prozent des Systems sind eine normale App, der Private Lookup ist der eine FHE-Call. Das Google-Muster: Das Wallet ist ein normales Wallet, der Alterscheck ist der eine ZK-Proof.
3. Nimm langweiliges, gewartetes Tooling. Für ZK heißt das 2026 eine Rust-zkVM (SP1, RISC Zero) oder Noir statt handgeschriebener Circuits. Für FHE heißt es Zamas TFHE-rs und Concrete ML, OpenFHE oder Apples Swift-Library. Der ZK-Post und der FHE-Post enthalten die vollständigen Tooling-Tabellen.
4. Budgetiere fürs Audit, nicht nur für den Build. Ein Circuit-Audit plus Fuzzing ist ein Fixkostenpunkt beim Shippen von ZK. Ihn zu überspringen ist die Art, wie Bounty-Writeups über dich geschrieben werden. RISC Zero zahlte eine 50.000-Dollar-Bounty für einen Bug, der nach vorherigen Audits gefunden wurde, was dir sagt, wie schwer das selbst für die besten Teams ist.
5. Führe das Fallback-Gespräch früh. Wenn die Latenz- oder Kostenzahlen nicht aufgehen, ist ein TEE der ehrliche Fallback, und für viele EU-Compliance-Fälle reicht er. Das in Woche zwei zu entscheiden ist billig. Es in Monat acht zu entscheiden ist ein Rewrite.

Ein weiterer Treiber, der genannt gehört: Regulierung zieht dieses Feld schneller nach vorn als die Produktnachfrage. Jeder EU-Mitgliedstaat muss bis Ende 2026 unter eIDAS 2.0 ein digitales Identitäts-Wallet anbieten, und das Framework ermutigt explizit zu Zero-Knowledge-artiger selektiver Offenlegung. Der European Health Data Space verweist für die Sekundärnutzung von Gesundheitsdaten auf Privacy-Enhancing Technologies. Wenn du in die EU verkaufst, verschiebt sich die Frage von "warum sollten wir das nutzen" zu "welche Teile erwarten die Regulierer". Der Decision-Framework-Post mappt Regulierungen auf konkrete Technologie-Entscheidungen.