Die wichtigsten Blockchain-Datenschutztechnologien: Zero-Knowledge-Proofs, FHE, MPC, TEEs und Ringsignaturen

Jede Transaktion auf einer öffentlichen Blockchain ist standardmäßig für jeden sichtbar, der hinsieht. Guthaben, Transferbeträge und Gegenparteien stehen dauerhaft im offenen Ledger. Diese Transparenz ist die Quelle der Vertrauensgarantien einer Blockchain, aber auch eine Belastung: Keine Bank veröffentlicht Kundenguthaben, und kein Unternehmen möchte, dass Wettbewerber seine Lieferantenzahlungen oder Gehaltsläufe lesen können.

Blockchain-Datenschutztechnologien sollen diese Lücke schließen, ohne die Eigenschaften aufzugeben, die Chains überhaupt nützlich machen: Überprüfbarkeit, Dezentralisierung und die Fähigkeit Fremder, ohne vertrauenswürdigen Mittelsmann miteinander zu handeln. Fünf Techniken prägen die heutige Landschaft: Zero-Knowledge-Proofs, vollständig homomorphe Verschlüsselung (FHE), sichere Mehrparteienberechnung (MPC), vertrauenswürdige Ausführungsumgebungen (TEEs) sowie Ringsignaturen mit Stealth-Adressen. Jede verbirgt einen anderen Teil des Puzzles, beruht auf einer anderen Vertrauensannahme und erfordert unterschiedlich viel Rechenleistung. Dieser Leitfaden erklärt alle fünf, vergleicht sie direkt und zeigt, warum die Wahl für jeden wichtig ist, der auf Web3 baut oder es einfach verstehen möchte.

Zero-Knowledge-Proofs

Ein Zero-Knowledge-Proof (ZKP) ermöglicht einer Partei — dem Prover —, eine andere — den Verifier — davon zu überzeugen, dass eine öffentliche Aussage wahr ist, ohne den zu ihrem Beweis verwendeten privaten Witness offenzulegen oder mehr zu verraten, als ohnehin aus der Aussage und ihrer Gültigkeit folgt. Bei einer Behauptung wie „Ich kenne ein x mit H(x) = y“ sieht der Verifier normalerweise die Aussage und den öffentlichen Wert y; Zero Knowledge schützt x. Anwendungen können Teile ihrer öffentlichen Eingabe separat verbergen oder durch ein Commitment binden, doch die Aussage selbst zu verbergen gehört nicht zur allgemeinen Definition eines ZKP (Thaler, Proofs, Arguments, and Zero-Knowledge).

Damit ein Beweissystem ein echtes Zero-Knowledge-Protokoll ist, muss es drei Eigenschaften erfüllen: Vollständigkeit (ein ehrlicher Verifier akzeptiert eine wahre Behauptung), Korrektheit (ein unehrlicher Prover kann einen ehrlichen Verifier nur mit der begrenzten Fehlerwahrscheinlichkeit des Beweissystems dazu bringen, eine falsche Behauptung zu akzeptieren) und Zero Knowledge selbst (der Beweis offenbart über das aus der öffentlichen Aussage Folgende hinaus kein zusätzliches Wissen über den privaten Witness). Klassische interaktive Protokolle verwenden häufig ein Commitment, eine Challenge des Verifiers und eine Antwort des Provers. Moderne nicht-interaktive SNARKs und STARKs bündeln die erforderlichen Beweisdaten ohne eine live gestellte Challenge des Verifiers und bewahren dabei dieselben übergeordneten Ziele von Vollständigkeit, Korrektheit und Zero Knowledge.

Was verborgen wird: der private Witness, etwa geheime Daten oder private Berechnungseingaben. Die öffentliche Aussage und öffentliche Eingaben bleiben sichtbar, sofern die Anwendung sie nicht separat durch ein Commitment bindet oder verschlüsselt.

Heutige Nutzung: ZK-Rollups sind der größte Produktionseinsatz von ZKPs bei der Skalierung von Blockchains. Sie „bundle (or 'roll up') transactions into batches that are executed offchain“ und erzeugen dann einen einzelnen Gültigkeitsbeweis, den Ethereum vor der Finalisierung der Zustandsänderungen des Batches prüft (ethereum.org). zkSync Era von Matter Labs ist ein „EVM-compatible ZK Rollup...powered by its own zkEVM“ (ethereum.org); Starknet von StarkWare ist ein Validity Rollup, das statt der EVM seine eigene Cairo-VM ausführt, wobei Solidity-Verträge separat überbrückt werden. L2BEAT erfasst beide als durch Validity Proofs gesicherte Rollups statt durch das Fraud-Proof-Anfechtungsfenster optimistischer Rollups (l2beat.com). Auf der Datenschutzseite war Zcash Pionier bei zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) für abgeschirmte Transaktionen; Adressen der Nutzer, Transaktionsbetrag und weitere Details bleiben verschlüsselt, während das Netzwerk die Gültigkeit der Transaktion weiterhin bestätigt (z.cash).

Der Kompromiss: Das Erzeugen eines ZK-Beweises ist rechenintensiv — Beweisschaltkreise durchlaufen jede Transaktion eines Batches und führen dessen Prüfungen erneut aus. Beweiszeit und Hardwarekosten sind daher reale Grenzen, auch wenn die On-Chain-Prüfung günstig und schnell ist. Die Sicherheit beruht auf den kryptografischen Annahmen des Beweissystems, einer sicheren Parametererzeugung und der korrekten Implementierung von Schaltkreis und Protokoll; bei einigen Beweissystemen gehört außerdem eine einmalige Trusted-Setup-Zeremonie dazu. Die Ethereum-Dokumentation weist darauf hin, dass kompromittierte Setup-Entropie falsche Beweise ermöglichen und Implementierungsfehler das Sicherheitsmodell untergraben können (ethereum.org).

Vollständig homomorphe Verschlüsselung (FHE)

Vollständig homomorphe Verschlüsselung verfolgt einen anderen Ansatz: Statt eine Tatsache über verborgene Daten zu beweisen, erlaubt sie, direkt auf verschlüsselten Daten zu rechnen und ein verschlüsseltes Ergebnis zu erhalten, das nach Entschlüsselung dieselbe Antwort ergibt wie eine Rechnung auf Klartext. Zama, eines der führenden Forschungs- und Infrastrukturunternehmen für FHE, beschreibt dies so: „FHE enables data processing without decryption—companies provide services without accessing user data, while users experience unchanged functionality“ (zama.org).

Was verborgen wird: Rohdaten, Zwischenzustand und Ausgaben einer Berechnung — jeder außer dem Schlüsselinhaber sieht nur Ciphertext, auch die Partei, die die Berechnung durchführt.

Funktionsweise auf hoher Ebene: FHE-Schemata kodieren Klartextwerte in auf Gittermathematik aufgebauten Ciphertexts und definieren verschlüsselte Entsprechungen von Addition und Multiplikation, sodass beliebige Schaltkreise auf Ciphertexts ausgeführt werden können. Auf eine Blockchain angewandt bedeutet das, dass ein Smart Contract Tokens bewegen oder Logik auswerten kann, ohne die betreffenden Beträge zu sehen. Wie Zamas Beispiel sagt: „the blockchain verified Alice has sufficient funds without ever seeing the actual amounts“ (zama.org). Zama weist außerdem darauf hin, dass gitterbasierte FHE-Schemata „inherently post-quantum resilient“ sind, was für langfristige kryptografische Risiken wichtig ist (zama.org).

Beispielprojekte: Zama entwickelt die Open-Source-FHE-Bibliotheken TFHE-rs und Concrete sowie die fhEVM, die vertrauliche Smart-Contract-Ausführung für EVM-Chains ermöglicht. Fhenix ist eine Blockchain, die speziell dafür gebaut wurde, dass „developers build privacy-preserving smart contracts using Fully Homomorphic Encryption“, sodass „sensitive data remains encrypted throughout computation“. Dazu gehören die JavaScript-Bibliothek Cofhejs für clientseitige Verschlüsselung und eine Solidity-FHE-Bibliothek für verschlüsselte On-Chain-Operationen (cofhe-docs.fhenix.zone).

Der Kompromiss: Die besondere Garantie von FHE besteht darin, dass unterstützte Berechnungen ausgeführt werden können, ohne Eingaben oder Zwischenwerte zu entschlüsseln. Die konkrete Sicherheit hängt jedoch weiterhin vom Schema und der Parameterwahl ab; aus diesem Grund veröffentlicht HomomorphicEncryption.org schemaspezifische Sicherheitstabellen und Leitlinien zur Parameterwahl (HomomorphicEncryption.org). Gegenüber Klartextausführung ist FHE zugleich mit Abstand der rechenintensivste Ansatz in dieser Liste. Deshalb führen FHE-basierte Chains heute vertraulichkeitskritische Logik statt jeder Transaktion aus, und deshalb ist Hardwarebeschleunigung für FHE ein aktives Forschungsrennen.

Sichere Mehrparteienberechnung (MPC)

Sichere Mehrparteienberechnung löst ein verwandtes, aber anderes Problem: Statt dass eine Partei auf verschlüsselten Daten rechnet, berechnen mehrere Parteien, die jeweils einen privaten Teil der Eingabe halten, gemeinsam eine Funktion, ohne einander ihre individuellen Eingaben zu offenbaren. Nach der formalen Definition ist MPC „a subfield of cryptography with the goal of creating methods for parties to jointly compute a function over their inputs while keeping those inputs private“; für drei Teilnehmer können „Alice, Bob, and Charlie ... F(x, y, z)“ lernen, ohne offenzulegen, wer was einbringt (Wikipedia).

Was verborgen wird: die individuelle Eingabe jeder Partei vor allen anderen — nur die vereinbarte Ausgabe wird offengelegt, und kein einzelner Teilnehmer sieht jemals das gesamte Geheimnis.

Vertrauensannahme: Es gibt keinen universellen Korruptionsschwellenwert für MPC. Im klassischen BGW-Ergebnis für ein vollständiges Netzwerk gilt Privatsphäre gegen passive Fehler für t < n/2, während Robustheit gegen byzantinische Fehler für t < n/3 gilt (ACM). Diese Grenzen beschreiben dieses Protokollmodell, nicht MPC insgesamt: Bei vorausgesetztem Broadcast können vollständig sichere Protokolle t < n/2 erreichen (TCC 2021), während das auf rechnerischer Sicherheit beruhende SPDZ-Protokoll in seinem Vorverarbeitungsmodell aktive Sicherheit bei bis zu n - 1 korrupten Parteien bietet (IACR). Diese Garantie bei unehrlicher Mehrheit ist Sicherheit mit Abbruch — ein korrupter Teilnehmer kann die Berechnung weiterhin stoppen — und nicht Fairness oder eine garantierte Ausgabe (PoPETs). Eine konkrete Bereitstellung muss daher das Protokoll, das passive oder aktive Korruptionsmodell, Synchronitäts- und Kanal-/Setup-Annahmen einschließlich Broadcast sowie die Annahme einer ehrlichen oder unehrlichen Mehrheit benennen.

Heutige Nutzung — Verwahrung mit Threshold-Signaturen: Die sichtbarste Blockchain-Anwendung von MPC teilt einen privaten Schlüssel auf unabhängige Parteien auf, sodass kein Gerät und keine Person je den gesamten Schlüssel hält. Der Verwahrungsinfrastrukturanbieter Fireblocks beschreibt es direkt: „Multi-party computation (MPC) is a cryptographic method that splits a private key into separate shares distributed across multiple independent parties“; entscheidend ist, dass „the complete key is never assembled in one place, at any point in time“ (fireblocks.com). Wenn eine Transaktion signiert werden soll, prüfen Endpunkte eines Quorums jeweils die Transaktion und liefern eine Teilsignatur. Zu keinem Zeitpunkt wird der private Schlüssel zusammengesetzt; selbst wenn ein Endpunkt kompromittiert ist, sind die anderswo gehaltenen Key Shares isoliert nutzlos (fireblocks.com). Dieses Threshold-Signature-Muster liegt heute dem Großteil der institutionellen Krypto-Verwahrung und vielen Multi-Signer-Wallets zugrunde.

Der Kompromiss: MPC vermeidet den einzelnen Ausfallpunkt eines privaten Schlüssels auf einem Gerät, fügt jedoch Kommunikationsrunden zwischen den Parteien und damit Latenz hinzu und verlangt sorgfältiges Protokolldesign. Seine Garantie ist nur so stark wie die kryptografischen, Korruptions- und Netzwerkannahmen des gewählten Protokolls sowie die operative Unabhängigkeit der Parteien. MPC kann einen einzelnen Schlüsselinhaber beseitigen, ohne damit Vertrauen aus dem Systemdesign zu entfernen.

Vertrauenswürdige Ausführungsumgebungen (TEEs)

Eine vertrauenswürdige Ausführungsumgebung geht einen weiteren Weg: Statt Daten während einer Berechnung durchgehend zu verschlüsseln, isoliert sie die Berechnung in einem hardwaregeschützten Bereich eines Chips — einer Secure Enclave —, den selbst das Betriebssystem der Maschine nicht einsehen kann. Intels SGX (Software Guard Extensions), die bekannteste Implementierung, wird auf Wikipedia als „a set of instruction codes implementing trusted execution environment that are built into some Intel central processing units (CPUs)“ beschrieben (Wikipedia). Mechanisch verschlüsselt SGX durch die CPU einen Teil des Speichers, die Enclave; Daten und Code aus ihr werden innerhalb der CPU im laufenden Betrieb entschlüsselt und dadurch vor Inspektion oder Lesen durch anderen Code geschützt, auch durch Code auf höheren Privilegstufen wie Betriebssystem und Hypervisor (Wikipedia).

Was verborgen wird: die Daten und der Code innerhalb der Enclave vor jedem anderen Prozess auf derselben Maschine, einschließlich eines kompromittierten Betriebssystems — nützlich, wenn Sie der Ausführung eines bestimmten Codeteils vertrauen müssen, aber nicht dem Serverbetreiber.

Vertrauensannahme: Die Trennlinie lautet nicht „reine Mathematik“ bei ZKPs, FHE und MPC gegenüber ausschließlichem Herstellervertrauen bei einem TEE. Eingesetzte kryptografische Systeme hängen ebenfalls von ihren angegebenen Härteannahmen, Parametern oder Setups, korrekten Implementierungen und — bei MPC — vom Teilnehmer- und Kommunikationsmodell des Protokolls ab. Ein TEE ergänzt dieses Systemvertrauen um hardwaregestützte Isolation und Attestierung. Intel definiert die Trusted Computing Base von SGX als die Hardware, CPU-Firmware und Plattformsoftware, die zum Erreichen der SGX-Sicherheitsziele erforderlich sind; durch Attestierung kann eine vertrauende Partei die Identität der Enclave und den Patchstand der Plattform beurteilen (Intel). Diese Vertrauensgrenze wurde geprüft: SGX „does not protect against side-channel attacks“, und Forscher zeigten wiederholt praktische Brüche, von der Extraktion von RSA-Schlüsseln aus SGX-Enclaves auf demselben System innerhalb von fünf Minuten im Jahr 2017 bis zur Foreshadow-Attacke, die speculative execution und buffer overflow kombiniert, um SGX zu umgehen, im Jahr 2018, sowie späteren Schwachstellen wie Plundervolt, LVI, SGAxe und ÆPIC Leak (Wikipedia). Deshalb werden TEEs gewöhnlich als pragmatischer, schneller Mittelweg und nicht als kryptografisch wasserdichte Garantie beschrieben.

Beispielprojekte: Das Sapphire-Netzwerk von Oasis Protocol führt Smart Contracts in Hardware-Enclaves aus, sodass Nutzer „run code inside hardware-secured enclaves“ können, in denen „data stays encrypted even from server operators“, während „every execution produces cryptographic proof that users can verify without blind trust“. So liefert es „confidential smart contracts“ mit „EVM compatibility and composability“ (oasis.net). Secret Network und mehrere Datenschutzprodukte im Umfeld von Restaking bauen ebenfalls auf TEEs, häufig zusammen mit anderen Techniken für Defense in Depth.

Der Kompromiss: TEEs laufen nahezu mit nativer Geschwindigkeit — weit schneller als FHE oder aufwendige ZK-Beweiserzeugung — und sind dadurch für latenzempfindliche Anwendungen attraktiv. Diese Geschwindigkeit geht jedoch mit einer breiteren Trusted Computing Base aus Hardware und Software einher, die eine reale, dokumentierte Geschichte von Side-Channel-Brüchen hat. Verglichen werden daher unterschiedliche Systemannahmen, nicht Hardwarevertrauen und eine annahmenfreie „reine Kryptografie“.

Ringsignaturen und Stealth-Adressen

Das letzte Technikenpaar schützt ein engeres, aber sehr praktisches Ziel: zu verbergen, wer eine Transaktion gesendet und wer sie erhalten hat, obwohl die Transaktion selbst On-Chain sichtbar ist. Monero ist das führende Produktionsbeispiel für beides.

Ringsignaturen verbergen den Sender. Die eigene Dokumentation von Monero erklärt, dass „a ring signature is a type of digital signature that can be performed by any member of a group of users that each have keys“ und dass es rechnerisch nicht praktikabel sein soll festzustellen, welcher Schlüssel der Gruppenmitglieder die Signatur erzeugt hat (getmonero.org). Praktisch mischt eine Monero-Transaktion den Schlüssel des tatsächlichen Ausgebers mit Köder-öffentlichen-Schlüsseln, die mittels einer Gamma-Verteilung aus der Blockchain gezogen werden. In einem Ring möglicher Signierer sind alle Ringmitglieder gleich und gültig; ein externer Beobachter kann nicht feststellen, welcher mögliche Signierer einer Signaturgruppe zu Ihrem Konto gehört (getmonero.org).

Stealth-Adressen verbergen den Empfänger. Statt eine öffentliche Adresse wiederzuverwenden, erzeugt der Sender für jede Transaktion im Namen des Empfängers zufällige Einmaladressen. Eingehende Zahlungen gelangen so auf einzigartige Adressen in der Blockchain und können weder mit der veröffentlichten Adresse des Empfängers noch mit den Adressen anderer Transaktionen verknüpft werden (getmonero.org). Ein Empfänger durchsucht die Chain mit einem privaten View Key nach Zahlungen und bewegt sie mit einem privaten Spend Key; nur Sender und Empfänger können daher bestimmen, wohin eine Zahlung ging (getmonero.org).

Was verborgen wird: Identität des Senders (Ringsignaturen) und Identität des Empfängers (Stealth-Adressen). Transaktionsbeträge werden durch einen separaten Mechanismus, Confidential Transactions / RingCT, verborgen; diese beiden Techniken allein decken ihn nicht ab.

Der Kompromiss: Beide Techniken laufen effizient auf gewöhnlicher Hardware, ohne Aufwand für Beweiserzeugung oder Abhängigkeit von Enclaves, und passen daher gut zu einem live betriebenen Zahlungsnetz. Ihr Vertrauensmodell beruht jedoch darauf, dass Ködermengen statistisch nicht vom tatsächlichen Signierer zu unterscheiden sind. Schwache Köderauswahl oder Heuristiken der Blockchain-Analyse haben Anonymitätsmengen in frühen Ringsignatur-Deployments historisch eingeengt. Daher zählen Parameterentscheidungen wie Ringgröße und Köderverteilung ebenso wie das zugrunde liegende Primitiv.

Vergleich der fünf Ansätze

Keine einzelne Technologie gewinnt auf jeder Achse. Daher kombiniert die aktuelle Forschung sie zunehmend, etwa indem ZK-Proofs die Korrektheit einer MPC-Berechnung prüfen oder TEEs zusammen mit FHE für Defense in Depth genutzt werden.

Verbindung zu tokenisierten Domains

Tokenisierte Domains erben dieselbe Standardtransparenz wie jeder andere On-Chain-Vermögenswert: Eigentumsübertragungen, Gebote und Metadatenaktualisierungen sind öffentlich lesbar. Das ist überwiegend ein Vorteil — Provenienz und Eigentumshistorie machen eine tokenisierte Domain gerade als handelbaren Vermögenswert vertrauenswürdig —, doch es bedeutet auch, dass Bestände und Verkaufspreise eines Domainportfolios für jeden sichtbar sind, der die Chain beobachtet.

Die Datenschutztechnologien dieses Leitfadens zeigen, wohin Infrastruktur für Domains als NFTs künftig gehen könnte: MPC-basierte Threshold-Verwahrung sichert bereits institutionelle Wallets mit Domain-NFTs genauso wie andere digitale Vermögenswerte. ZK-Proofs könnten einem Bieter irgendwann ermöglichen nachzuweisen, dass er ein Angebot finanzieren kann, ohne seinen gesamten Kontostand zu offenbaren. Und vertrauliche Berechnungstechniken könnten es einem Registrar oder Marktplatz erlauben, Berechtigungsregeln zu prüfen, ohne die vollständige Identität eines Käufers offenzulegen. Nichts davon ist heute in der Domaintokenisierung eingesetzt, aber die zugrunde liegenden Primitive sind dieselben, die derzeit Milliarden Dollar in DeFi und Verwahrungsinfrastruktur sichern.

Quellen und weiterführende Lektüre

• Zero-Knowledge Proofs — ethereum.org
• Proofs, Arguments, and Zero-Knowledge — Justin Thaler
• ZK-Rollups — ethereum.org
• L2BEAT Scaling Summary
• Zcash Technology Overview
• Introduction to Homomorphic Encryption — Zama
• Security Guidelines — HomomorphicEncryption.org
• Fhenix cofhe Documentation
• Secure Multi-Party Computation — Wikipedia
• Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation — ACM
• Efficient Perfectly Secure Computation — TCC 2021
• Multiparty Computation from Somewhat Homomorphic Encryption (SPDZ) — IACR
• Extending the Security of SPDZ with Fairness — PoPETs
• What Is MPC? — Fireblocks
• Software Guard Extensions (SGX) — Wikipedia
• Intel SGX Attestation Technical Details
• Oasis Protocol Technology
• Ring Signatures — Monero Moneropedia
• Stealth Addresses — Monero Moneropedia