8 Beiträge getaggt mit „Datenschutz“

Wenn die weltweit größte auf Krypto spezialisierte Venture-Capital-Firma ihre jährlichen Prognosen veröffentlicht, hört die Branche zu. Aber sollte man alles glauben, was Andreessen Horowitz einem über das Jahr 2026 erzählt?

a16z crypto hat vor Kurzem „17 Dinge, auf die wir uns im Krypto-Bereich im Jahr 2026 freuen“ veröffentlicht – ein umfassendes Manifest, das KI-Agenten, Stablecoins, Privatsphäre, Prognosemärkte und die Zukunft des Bezahlens im Internet abdeckt. Mit einem verwalteten Krypto-Vermögen von 7,6 Milliarden $ und einem Portfolio, das Schwergewichte wie Coinbase, Uniswap und Solana umfasst, sagt a16z nicht nur die Zukunft voraus. Sie wetten Milliarden darauf.

Das erzeugt eine interessante Spannung. Wenn eine VC-Firma, die 18 % des gesamten US-Venture-Capitals verwaltet, auf bestimmte Trends hinweist, folgen die Kapitalströme. Sind diese Vorhersagen also echte Weitsicht oder ausgeklügeltes Marketing für ihre Portfoliounternehmen? Lassen Sie uns jedes Hauptthema sezieren – was wirklich aufschlussreich ist, was eigennützig ist und was sie falsch einschätzen.

Die Stablecoin-These: Glaubwürdig, aber übertrieben​

Die größte Wette von a16z besteht darin, dass Stablecoins ihre explosive Entwicklung fortsetzen werden. Die Zahlen, die sie anführen, sind beeindruckend: 46 Billionen $ Transaktionsvolumen im vergangenen Jahr – mehr als das 20-fache des Volumens von PayPal, womit sie in die Reichweite von Visa rücken und schnell zu ACH aufschließen.

Was sie richtig erkannt haben: Stablecoins sind im Jahr 2025 tatsächlich im Mainstream-Finanzsektor angekommen. Visa hat sein USDC-Settlement-Programm auf Solana ausgeweitet. Mastercard trat dem Global Dollar Network von Paxos bei. Circle hat über 100 Finanzinstitute in seiner Pipeline. Bloomberg Intelligence prognostiziert, dass die Zahlungsströme von Stablecoins bis Ende 2026 5,3 Billionen $ erreichen werden – ein Anstieg von 82,7 %.

Auch der regulatorische Rückenwind ist real. Der GENIUS Act, dessen Verabschiedung für Anfang 2026 erwartet wird, würde klare Regeln für die Emission von Stablecoins unter FDIC-Aufsicht festlegen und Banken einen regulierten Weg zur Ausgabe von dollarbasierten Stablecoins bieten.

Der Gegenpunkt: a16z ist über Portfoliounternehmen wie Coinbase (das USDC durch seine Partnerschaft mit Circle ausgibt) tief in das Stablecoin-Ökosystem investiert. Wenn sie vorhersagen, dass „das Internet zur Bank wird“, indem programmierbares Stablecoin-Settlement Einzug hält, beschreiben sie eine Zukunft, in der ihre Investitionen zur Infrastruktur werden.

Auch die Zahl von 46 Billionen $verdient eine genauere Betrachtung. Ein Großteil des Stablecoin-Transaktionsvolumens ist zirkulär – Händler, die Gelder zwischen Börsen verschieben, DeFi-Protokolle, die Liquidität umschichten, und Arbitrageure, die Positionen wechseln. Das US-Finanzministerium identifiziert 5,7 Billionen$ an „gefährdeten“ Einlagen, die zu Stablecoins migrieren könnten, aber die tatsächliche Akzeptanz durch Verbraucher und Unternehmen bleibt nur ein Bruchteil der Schlagzeilen-Zahlen.

Realitätscheck: Stablecoins werden deutlich wachsen, aber „das Internet wird zur Bank“ ist eine Vision für in zehn Jahren, keine Realität für 2026. Banken bewegen sich aus guten Gründen langsam – Compliance, Betrugsprävention, Verbraucherschutz. Dass Stripe Stablecoin-Zahlungsschienen hinzufügt, bedeutet nicht, dass Ihre Großmutter nächstes Jahr ihre Miete in USDC bezahlen wird.

Die KI-Agenten-Prognose: Visionär, aber verfrüht​

Die zukunftsorientierteste Prognose von a16z führt „KYA“ ein – Know Your Agent – ein kryptografisches Identitätssystem für KI-Agenten, das es autonomen Systemen ermöglichen würde, Zahlungen zu leisten, Verträge zu unterzeichnen und Transaktionen ohne menschliches Eingreifen durchzuführen.

Sean Neville, der diese Prognose verfasst hat, argumentiert, dass sich der Engpass von der KI-Intelligenz zur KI-Identität verschoben hat. Im Finanzdienstleistungssektor gibt es mittlerweile „nicht-menschliche Identitäten“, die menschliche Mitarbeiter im Verhältnis 96 zu 1 übertreffen, doch diese Systeme bleiben „banklose Geister“, die nicht autonom transagieren können.

Was sie richtig erkannt haben: Die Agenten-Ökonomie ist real und wächst. Fetch.ai führt im Januar 2026 das nach eigenen Angaben weltweit erste autonome KI-Zahlungssystem ein. Das Trusted Agent Protocol von Visa bietet kryptografische Standards zur Verifizierung von KI-Agenten. PayPal und OpenAI sind eine Partnerschaft eingegangen, um Agenten-basierten Handel in ChatGPT zu ermöglichen. Das x402-Protokoll für Machine-to-Machine-Zahlungen wurde von Google Cloud, AWS und Anthropic übernommen.

Der Gegenpunkt: Der DeFAI-Hype-Zyklus von Anfang 2025 ist bereits einmal zusammengebrochen. Teams experimentierten mit KI-Agenten für automatisierten Handel, Wallet-Management und Token-Sniping. Die meisten lieferten keinen realen Mehrwert.

Die grundlegende Herausforderung ist nicht technischer Natur – es ist die Haftung. Wenn ein KI-Agent einen schlechten Trade macht oder zu einer bösartigen Transaktion verleitet wird, wer ist verantwortlich? Aktuelle rechtliche Rahmenbedingungen haben darauf keine Antwort. KYA löst das Identitätsproblem, aber nicht das Haftungsproblem.

Es gibt auch das systemische Risiko, über das niemand sprechen möchte: Was passiert, wenn Tausende von KI-Agenten, die ähnliche Strategien verfolgen, interagieren? „Hochreaktive Agenten können Kettenreaktionen auslösen“, räumt eine Branchenanalyse ein. „Strategiekollisionen werden kurzfristiges Chaos verursachen.“

Realitätscheck: KI-Agenten, die autonome Krypto-Zahlungen leisten, werden auch 2026 experimentell bleiben. Die Infrastruktur wird zwar gebaut, aber regulatorische Klarheit und Haftungsrahmen liegen Jahre hinter der Technologie zurück.

Privatsphäre als „Der ultimative Burggraben“: Richtiges Problem, falscher Rahmen​

Ali Yahyas Prognose, dass Privatsphäre im Jahr 2026 die Blockchain-Gewinner definieren wird, ist das technisch anspruchsvollste Argument der Sammlung. Seine These: Die Durchsatz-Kriege sind vorbei. Jede größere Chain verarbeitet mittlerweile Tausende von Transaktionen pro Sekunde. Das neue Differenzierungsmerkmal ist die Privatsphäre, und „das Überbrücken von Geheimnissen ist schwierig“ – was bedeutet, dass Nutzer, die sich auf eine die Privatsphäre wahrende Chain festlegen, auf echten Widerstand stoßen, wenn sie diese verlassen wollen.

Was sie richtig erkannt haben: Die Nachfrage nach Privatsphäre steigt sprunghaft an. Google-Suchanfragen nach Krypto-Privatsphäre erreichten 2025 neue Höchststände. Der Shielded Pool von Zcash wuchs auf fast 4 Millionen ZEC an. Die Transaktionsströme von Railgun überstiegen monatlich 200 Millionen $. Arthur Hayes schloss sich dieser Meinung an: „Große Institutionen wollen nicht, dass ihre Informationen öffentlich sind oder Gefahr laufen, öffentlich zu werden.“

Das technische Argument ist stichhaltig. Privatsphäre schafft Netzwerkeffekte, die Durchsatz allein nicht bietet. Man kann Token trivial zwischen Chains überbrücken. Man kann jedoch keine Transaktionshistorie überbrücken, ohne sie preiszugeben.

Der Gegenpunkt: a16z hält bedeutende Investitionen in Ethereum-L2s und Projekte, die von Privatsphäre-Upgrades profitieren würden. Wenn sie vorhersagen, dass Privatsphäre essenziell wird, betreiben sie zum Teil Lobbyarbeit für Funktionen, die ihre Portfoliounternehmen benötigen.

Noch wichtiger ist, dass es ein regulatorisches Problem gibt, das kaum jemand anspricht. Dieselben Regierungen, die kürzlich Tornado Cash sanktioniert haben, werden Privatsphäre-Chains nicht über Nacht akzeptieren. Das Spannungsverhältnis zwischen institutioneller Akzeptanz (die KYC/AML erfordert) und echter Privatsphäre (die dies untergräbt) ist noch nicht gelöst.

Realitätscheck: Privatsphäre wird 2026 eine größere Rolle spielen, aber die „Winner-take-most“-Dynamik ist übertrieben. Regulatorischer Druck wird den Markt in konforme Quasi-Privatsphäre-Lösungen für Institutionen und echt private Chains für alle anderen fragmentieren.

Prognosemärkte: Eigentlich unterschätzt​

Andrew Halls Vorhersage, dass Prognosemärkte „größer, breiter und smarter“ werden, ist vielleicht der am wenigsten kontroverseste Punkt auf der Liste – und einer, bei dem a16z die Chancen möglicherweise unterschätzt.

Was sie richtig erkannt haben: Polymarket hat während der US-Wahlen 2024 bewiesen, dass Prognosemärkte massentauglich werden können. Die Plattform lieferte in mehreren Rennen genauere Vorhersagen als traditionelle Umfragen. Nun stellt sich die Frage, ob sich dieser Erfolg auch auf Ereignisse jenseits der Politik übertragen lässt.

Hall prognostiziert LLM-Orakel, die umstrittene Märkte auflösen, KI-Agenten, die handeln, um neuartige prädiktive Signale zu finden, und Kontrakte auf alles, von Unternehmensgewinnen bis hin zu Wetterereignissen.

Der Gegenpunkt: Prognosemärkte stehen außerhalb von Großereignissen vor fundamentalen Liquiditätsproblemen. Ein Markt, der das Ergebnis des Super Bowl vorhersagt, zieht Millionen an Volumen an. Ein Markt, der die iPhone-Verkäufe des nächsten Quartals prognostiziert, hat Schwierigkeiten, Gegenparteien zu finden.

Auch regulatorische Unsicherheit droht. Die CFTC ist zunehmend aggressiv vorgegangen, um Prognosemärkte als Derivate zu behandeln, was eine belastende Compliance für Privatanleger erfordern würde.

Realitätscheck: Prognosemärkte werden erheblich expandieren, aber die Vision von „Märkten für alles“ erfordert die Lösung von Liquiditätsengpässen und regulatorische Klarheit. Beides ist schwieriger als die Technologie.

Die übersehenen Vorhersagen, die man im Auge behalten sollte​

Jenseits der Hauptthemen verdienen einige leisere Vorhersagen Aufmerksamkeit:

„Von ‚Code is Law‘ zu ‚Spec is Law‘“ — Daejun Park beschreibt den Übergang der DeFi-Sicherheit von der Fehlersuche hin zum Beweis globaler Invarianten durch KI-gestützte Spezifikationserstellung. Dies ist unspektakuläre Infrastrukturarbeit, könnte aber die jährlich durch Hacks verlorenen 3,4 Milliarden Dollar drastisch reduzieren.

„Die unsichtbare Steuer auf das offene Web“ — Elizabeth Harkavys Warnung, dass KI-Agenten Inhalte extrahieren, ohne die Urheber zu entschädigen, das ökonomische Modell des Internets zerstören könnte, ist wirklich wichtig. Wenn KI die Monetarisierungsebene von Inhalten entfernt und Werbung umgeht, muss etwas anderes an deren Stelle treten.

„Trading als Zwischenstation, nicht als Ziel“ — Arianna Simpsons Rat, dass Gründer, die auf unmittelbare Handelsgewinne aus sind, verteidigungsfähige Chancen verpassen, ist wahrscheinlich die ehrlichste Vorhersage in der Sammlung – und ein stillschweigendes Geständnis, dass ein Großteil der aktuellen Krypto-Aktivitäten Spekulation ist, die sich als Nutzen tarnt.

Worüber a16z nicht sprechen möchte​

Auffallend abwesend in den 17 Vorhersagen: jegliche Anerkennung der Risiken, die ihr optimistischer Ausblick ignoriert.

Die Memecoin-Müdigkeit ist real. Über 13 Millionen Memecoins wurden letztes Jahr gelauncht, aber die Neuerscheinungen gingen von Januar bis September um 56 % zurück. Der Spekulationsmotor, der das Interesse der Privatanleger antrieb, stottert.

Makroökonomischer Gegenwind könnte alles aus der Bahn werfen. Die Vorhersagen setzen eine fortgesetzte institutionelle Akzeptanz, regulatorische Klarheit und technologische Bereitstellung voraus. Eine Rezession, der Kollaps einer großen Börse oder aggressive regulatorische Maßnahmen könnten den Zeitplan um Jahre zurückwerfen.

Der a16z-Portfolio-Effekt wirkt verzerrend. Wenn eine Firma, die insgesamt 46 Milliarden Dollar an verwaltetem Vermögen (AUM) und 7,6 Milliarden Dollar in Krypto verwaltet, Vorhersagen veröffentlicht, die ihren Investitionen zugutekommen, reagiert der Markt – und schafft selbsterfüllende Prophezeiungen, die nicht die organische Nachfrage widerspiegeln.

Fazit​

Die 17 Vorhersagen von a16z sind am besten als strategisches Dokument und nicht als neutrale Analyse zu verstehen. Sie sagen Ihnen, wo sie ihre Wetten platziert haben und warum Sie glauben sollten, dass sich diese Wetten auszahlen werden.

Das macht sie nicht falsch. Viele dieser Vorhersagen – Stablecoin-Wachstum, Infrastruktur für KI-Agenten, Datenschutz-Upgrades – spiegeln echte Trends wider. Die Firma beschäftigt einige der klügsten Köpfe im Krypto-Bereich und hat eine Erfolgsbilanz bei der frühzeitigen Identifizierung gewinnbringender Narrative.

Doch anspruchsvolle Leser sollten einen Risikoabschlag vornehmen. Fragen Sie sich, wer von jeder Vorhersage profitiert. Überlegen Sie, welche Portfoliounternehmen positioniert sind, um Werte zu schöpfen. Achten Sie darauf, was auffallend fehlt.

Die wertvollste Erkenntnis könnte die implizite These sein, die allen 17 Vorhersagen zugrunde liegt: Die Ära der Krypto-Spekulation endet, und die Ära der Infrastruktur beginnt. Ob das Wunschdenken oder eine genaue Prognose ist, wird sich im kommenden Jahr an der Realität messen lassen.

---

Die 17 a16z Krypto-Vorhersagen für 2026 im Überblick:

1. Bessere Stablecoin-On/Off-Ramps, die digitale Dollars mit Zahlungssystemen verbinden
2. Krypto-native RWA-Tokenisierung mit Perpetual Futures und Onchain-Originierung
3. Stablecoins, die Upgrades von Bankbüchern ermöglichen, ohne Legacy-Systeme umschreiben zu müssen
4. Das Internet wird durch programmierbares Settlement zur Finanzinfrastruktur
5. KI-gestütztes Wealth Management für jeden zugänglich
6. KYA (Know Your Agent) kryptografische Identität für KI-Agenten
7. KI-Modelle, die autonom Forschung auf Doktorandenniveau betreiben
8. Umgang mit der „unsichtbaren Steuer“ der KI auf offene Webinhalte
9. Privatsphäre als ultimativer Wettbewerbsvorteil für Blockchains
10. Dezentrales Messaging, das resistent gegen Quantenbedrohungen ist
11. Secrets-as-a-Service für programmierbare Datenzugriffskontrolle
12. „Spec is Law“ ersetzt „Code is Law“ in der DeFi-Sicherheit
13. Prognosemärkte expandieren über Wahlen hinaus
14. Staked Media ersetzt vorgetäuschte journalistische Neutralität
15. SNARKs ermöglichen verifizierbares Cloud Computing
16. Trading als Zwischenstation, nicht als Ziel, für Entwickler
17. Rechtliche Architektur entspricht der technischen Architektur in der Krypto-Regulierung

---

Dieser Artikel dient ausschließlich zu Bildungszwecken und sollte nicht als Finanzberatung betrachtet werden. Der Autor hält keine Positionen in den in diesem Artikel besprochenen a16z-Portfoliounternehmen.

Das Krypto-Team von Andreessen Horowitz war in der Vergangenheit bemerkenswert vorausschauend – sie sagten den NFT-Boom, den DeFi-Sommer und die These der modularen Blockchain voraus, bevor die meisten anderen es taten. Jetzt haben sie ihre 17 großen Ideen für 2026 veröffentlicht, und die Vorhersagen reichen vom Offensichtlichen (Stablecoins werden weiter wachsen) bis zum Kontroversen (KI-Agenten werden ihre eigenen Identitätssysteme benötigen). Hier ist unsere Analyse jeder Vorhersage, wo wir zustimmen und wo wir glauben, dass sie das Ziel verfehlt haben.

Die Stablecoin-These: Bereits bewiesen, aber wie viel höher?​

a16z-Vorhersage: Stablecoins werden ihren explosiven Wachstumskurs fortsetzen.

Die Zahlen sind atemberaubend. Im Jahr 2024 verarbeiteten Stablecoins ein Transaktionsvolumen von 15,6 Billionen US-Dollar. Bis 2025 erreichte diese Zahl 46 Billionen US-Dollar – mehr als das 20-fache des Volumens von PayPal und das Dreifache von Visa. Allein USDT macht über 190 Milliarden US-Dollar im Umlauf aus, während USDC nach dem Schreckmoment bei der Silicon Valley Bank wieder auf 45 Milliarden US-Dollar angestiegen ist.

Unsere Meinung: Dies ist weniger eine Vorhersage als vielmehr eine Tatsachenfeststellung. Die eigentliche Frage ist nicht, ob Stablecoins wachsen werden, sondern ob neue Marktteilnehmer wie PayPals PYUSD, Ripples RLUSD oder renditebringende Alternativen wie Ethenas USDe bedeutende Marktanteile vom Tether-Circle-Duopol erobern können.

Die interessantere Dynamik ist regulatorischer Natur. Der US GENIUS Act und der CLARITY Act gestalten die Stablecoin-Landschaft neu und schaffen potenziell ein Zwei-Klassen-System: konforme, US-regulierte Stablecoins für die institutionelle Nutzung und Offshore-Alternativen für den Rest der Welt.

KI-Agenten benötigen Krypto-Wallets​

a16z-Vorhersage: KI-Agenten werden zu bedeutenden Nutzern von Krypto-Infrastruktur werden und ihre eigenen Wallets sowie Identitätsnachweise durch ein „Know Your Agent“ (KYA)-System benötigen.

Dies ist eine der zukunftsweisenderen Vorhersagen von a16z. Da sich KI-Agenten immer weiter verbreiten – sie buchen Reisen, verwalten Investitionen, führen Trades aus –, müssen sie autonom Transaktionen durchführen. Traditionelle Zahlungssysteme erfordern eine menschliche Identitätsprüfung, was eine grundlegende Inkompatibilität schafft.

Unsere Meinung: Die Prämisse ist solide, aber der Zeitplan ist ehrgeizig. Die meisten aktuellen KI-Agenten agieren in Sandbox-Umgebungen mit menschlicher Genehmigung für finanzielle Aktionen. Der Sprung zu vollständig autonomen Agenten mit eigenen Krypto-Wallets steht vor erheblichen Hürden:

1. Haftungsfragen: Wer ist verantwortlich, wenn ein KI-Agent einen schlechten Trade macht?
2. Sybil-Angriffe: Was hindert jemanden daran, Tausende von KI-Agenten zu erstellen?
3. Regulatorische Unsicherheit: Werden Regulierungsbehörden von KI gesteuerte Wallets anders behandeln?

Das KYA-Konzept ist clever – im Grunde eine kryptografische Bestätigung, dass ein Agent von einer verifizierten Entität erstellt wurde und innerhalb bestimmter Parameter arbeitet. Die Implementierung wird der Vision jedoch um mindestens 2-3 Jahre hinterherhinken.

Datenschutz als Wettbewerbsvorteil (Burggraben)​

a16z-Vorhersage: Technologien zur Wahrung der Privatsphäre werden zu einer wesentlichen Infrastruktur und nicht nur zu optionalen Funktionen.

Der Zeitpunkt ist bemerkenswert. Gerade als Blockchain-Analysefirmen eine fast lückenlose Überwachung öffentlicher Chains erreicht haben, wettet a16z darauf, dass die Privatsphäre wieder an Priorität gewinnt. Technologien wie FHE (Fully Homomorphic Encryption), ZK-Proofs und Confidential Computing entwickeln sich von akademischen Kuriositäten zu produktionsreifen Infrastrukturen.

Unsere Meinung: Wir stimmen voll und ganz zu, jedoch mit Nuancen. Der Datenschutz wird sich in zwei Richtungen aufteilen:

• Institutionelle Privatsphäre: Unternehmen benötigen Vertraulichkeit bei Transaktionen ohne Bedenken hinsichtlich der Compliance. Lösungen wie das Confidential Computing von Oasis Network oder CCIP von Chainlink mit Datenschutzfunktionen werden hier dominieren.
• Individuelle Privatsphäre: Umstrittener. Der regulatorische Druck auf Mixing-Dienste und Privacy Coins wird zunehmen und datenschutzbewusste Nutzer zu konformen Lösungen drängen, die eine selektive Offenlegung ermöglichen.

Die Projekte, denen dieser Spagat gelingt – Privatsphäre bei gleichzeitiger Einhaltung regulatorischer Vorgaben –, werden einen enormen Wert schöpfen.

SNARKs für verifizierbares Cloud Computing​

a16z-Vorhersage: Zero-Knowledge-Proofs werden über die Blockchain hinausgehen, um jede Berechnung zu verifizieren und so ein „trustless“ Cloud Computing zu ermöglichen.

Dies ist vielleicht die technisch bedeutendste Vorhersage. Die heutigen SNARKs (Succinct Non-interactive Arguments of Knowledge) werden primär für die Skalierung von Blockchains (zkEVMs, rollups) und den Datenschutz eingesetzt. Dieselbe Technologie kann jedoch verifizieren, dass jede beliebige Berechnung korrekt durchgeführt wurde.

Stellen Sie sich vor: Sie senden Daten an einen Cloud-Anbieter, dieser liefert ein Ergebnis plus einen Beweis zurück, dass die Berechnung korrekt durchgeführt wurde. Es ist nicht nötig, AWS oder Google zu vertrauen – die Mathematik garantiert die Korrektheit.

Unsere Meinung: Die Vision ist überzeugend, aber der Overhead bleibt für die meisten Anwendungsfälle untragbar. Die Erstellung von ZK-Proofs für allgemeine Berechnungen kostet immer noch das 100- bis 1000-fache der ursprünglichen Berechnung. Projekte wie Boundless von RISC Zero und zkML von Modulus Labs machen Fortschritte, aber die breite Einführung liegt noch Jahre entfernt.

Die kurzfristigen Erfolge werden spezifische, hochwertige Anwendungsfälle sein: verifizierbare KI-Inferenz, prüfbare Finanzberechnungen und nachweisbare Compliance-Prüfungen.

Prognosemärkte werden massentauglich​

a16z-Prognose: Der Erfolg von Polymarket während der Wahlen 2024 wird einen breiteren Boom bei Prognosemärkten auslösen.

Polymarket verarbeitete ein Handelsvolumen von über 3 Mrd. $ im Zusammenhang mit der US-Wahl 2024 und erwies sich oft als genauer als traditionelle Umfragen. Dies waren nicht nur Krypto-Natives, die spekulierten – Mainstream-Medien zitierten die Quoten von Polymarket als legitime Prognosedaten.

Unsere Meinung: Die regulatorische Arbitrage wird nicht ewig halten. Polymarket operiert offshore, speziell um US-Glücksspiel- und Derivate-Regulierungen zu umgehen. Da Prognosemärkte an Legitimität gewinnen, werden sie einer zunehmenden regulatorischen Prüfung unterzogen.

Der nachhaltigere Weg führt über regulierte Handelsplätze. Kalshi verfügt über die SEC-Zulassung, bestimmte Ereigniskontrakte anzubieten. Die Frage ist, ob regulierte Prognosemärkte dieselbe Breite und Liquidität bieten können wie Offshore-Alternativen.

Die Verschiebung von Infrastruktur zu Anwendungen​

a16z-Prognose: Der Wert wird zunehmend den Anwendungen statt der Infrastruktur zufließen.

Jahrelang legte die „Fat-Protocol-These“ von Krypto nahe, dass Basisschichten (Ethereum, Solana) den Großteil des Wertes erfassen würden, während Anwendungen austauschbar blieben. a16z stellt dies nun infrage.

Die Belege: Hyperliquid erfasste im Jahr 2025 53 % der On-Chain-Einnahmen aus Perpetual-Swaps und übertraf damit die Gebühren vieler L1s. Uniswap generiert mehr Umsatz als die meisten Chains, auf denen es bereitgestellt wird. Friend.tech verdiente kurzzeitig mehr Geld als Ethereum.

Unsere Meinung: Das Pendel schwingt um, aber die Infrastruktur verschwindet nicht. Die Nuance ist, dass differenzierte Infrastruktur weiterhin Aufschläge verlangt – generische L1s und L2s werden tatsächlich zur Handelsware, aber spezialisierte Chains (Hyperliquid für den Handel, Story Protocol für IP) können Wert generieren.

Die Gewinner werden Anwendungen sein, die ihren Stack selbst besitzen: Entweder durch den Aufbau App-spezifischer Chains oder durch das Erreichen von genügend Volumen, um günstige Bedingungen von Infrastrukturanbietern zu fordern.

Dezentrale Identität jenseits der Finanzen​

a16z-Prognose: Blockchain-basierte Identitäts- und Reputationssysteme werden Anwendungsfälle jenseits von Finanzanwendungen finden.

Wir hören diese Vorhersage seit Jahren, und sie hat bisher konsequent zu wenig geliefert. Der Unterschied heute ist, dass KI-generierte Inhalte eine echte Nachfrage nach dem „Proof of Humanity“ geschaffen haben. Wenn jeder überzeugende Texte, Bilder oder Videos generieren kann, werden kryptografische Beglaubigungen menschlicher Schöpfung wertvoll.

Unsere Meinung: Vorsichtig optimistisch. Die technischen Bausteine existieren – Worldcoins Iris-Scanning, der Ethereum Attestation Service und verschiedene Soul-bound Token-Implementierungen. Die Herausforderung besteht darin, Systeme zu schaffen, die sowohl die Privatsphäre schützen als auch weit verbreitet sind.

Die Killer-App ist vielleicht nicht „Identität“ an sich, sondern spezifische Nachweise: Belege für berufliche Qualifikationen, verifizierte Bewertungen oder Beglaubigungen der Authentizität von Inhalten.

Die Beschleunigung der RWA-Tokenisierung​

a16z-Prognose: Die Tokenisierung von Real-World Assets (RWA) wird sich beschleunigen, angetrieben durch institutionelle Akzeptanz.

Der BUIDL-Fonds von BlackRock überschritt ein Vermögen von 500 Mio. $. Franklin Templeton, WisdomTree und Hamilton Lane haben alle tokenisierte Produkte auf den Markt gebracht. Der gesamte RWA-Markt (ohne Stablecoins) erreichte im Jahr 2025 16 Mrd.$.

Unsere Meinung: Das Wachstum ist real, aber der Kontext zählt. 16 Mrd. $ sind ein Rundungsfehler im Vergleich zu traditionellen Asset-Märkten. Die aussagekräftigere Kennzahl ist die Geschwindigkeit – wie schnell werden neue Vermögenswerte tokenisiert und finden sie Liquidität am Sekundärmarkt?

Der Engpass ist nicht die Technologie, sondern die rechtliche Infrastruktur. Die Tokenisierung einer Staatsanleihe ist einfach. Die Tokenisierung von Immobilien mit klaren Eigentumstiteln, Zwangsvollstreckungsrechten und regulatorischer Compliance über verschiedene Gerichtsbarkeiten hinweg ist enorm komplex.

Cross-Chain-Interoperabilität wird reif​

a16z-Prognose: Die Ära der „Walled Gardens“ von Blockchains wird enden, da sich die Cross-Chain-Infrastruktur verbessert.

CCIP von Chainlink, LayerZero, Wormhole und andere machen Cross-Chain-Transfers zunehmend nahtlos. Die Benutzererfahrung beim Bridging von Assets hat sich gegenüber den umständlichen und riskanten Prozessen von 2021 drastisch verbessert.

Unsere Meinung: Die Infrastruktur reift, aber Sicherheitsbedenken bleiben bestehen. Bridge-Exploits waren in den letzten Jahren für Verluste in Milliardenhöhe verantwortlich. Jede Interoperabilitätslösung führt neue Vertrauensannahmen und Angriffsflächen ein.

Der gewinnbringende Ansatz wird wahrscheinlich native Interoperabilität sein – Chains, die von Grund auf für die Kommunikation gebaut wurden, statt nachträglich aufgesetzte Bridge-Lösungen.

Krypto-Anwendungen für Endverbraucher kommen endlich an​

a16z-Prognose: Im Jahr 2026 werden wir die ersten Krypto-Anwendungen mit mehr als 100 Millionen Nutzern sehen, die sich nicht wie „Krypto-Apps“ anfühlen.

Das Argument: Infrastrukturverbesserungen (niedrigere Gebühren, bessere Wallets, Account Abstraction) haben die Reibung beseitigt, die zuvor die Massenadoption blockierte. Das fehlende Puzzleteil waren überzeugende Anwendungen.

Unsere Meinung: Dies wird seit 2017 jedes Jahr vorhergesagt. Der Unterschied heute ist, dass die Infrastruktur tatsächlich besser ist. Die Transaktionskosten auf L2s werden in Bruchteilen eines Cents gemessen. Smart Wallets können Seed-Phrasen abstrahieren. Fiat-On-Ramps sind integriert.

Aber „überzeugende Anwendungen“ sind der schwierige Teil. Die Krypto-Apps, die Skalierung erreicht haben (Coinbase, Binance), sind im Grunde Finanzprodukte. Nicht-finanzielle Killer-Apps bleiben schwer fassbar.

Unsere Ergänzungen: Was a16z übersehen hat​

1. Die Sicherheitskrise wird 2026 definieren​

Die Vorhersagen von a16z schweigen auffallend zum Thema Sicherheit. Im Jahr 2025 verlor der Krypto-Sektor über 3,5 Milliarden $ durch Hacks und Exploits. Der 1,5 Milliarden $ schwere Hack von ByBit hat gezeigt, dass selbst große Börsen weiterhin anfällig sind. Staatlich unterstützte Akteure (wie die nordkoreanische Lazarus Group) agieren immer raffinierter.

Solange die Branche keine grundlegenden Sicherheitsprobleme löst, wird die Akzeptanz im Mainstream begrenzt bleiben.

2. Regulatorische Fragmentierung​

Die USA bewegen sich auf eine klarere Krypto-Regulierung zu, aber das globale Bild fragmentiert sich. Die MiCA der EU, Singapurs Lizenzierungssystem und der Rahmen für virtuelle Vermögenswerte in Hongkong bilden ein Patchwork, durch das Projekte navigieren müssen.

Diese Fragmentierung wird einigen zugutekommen (Möglichkeiten für regulatorische Arbitrage) und anderen schaden (Compliance-Kosten für globale Operationen).

3. Die Bitcoin-Treasury-Bewegung​

Über 70 börsennotierte Unternehmen halten mittlerweile Bitcoin in ihren Bilanzen. Die Strategie von MicroStrategy – die Nutzung von Unternehmensreserven für Bitcoin-Exposures – wird weltweit kopiert. Diese institutionelle Akzeptanz ist wohl bedeutender als jede technische Entwicklung.

Fazit: Signal von Rauschen trennen​

Die Vorhersagen von a16z sind ernst zu nehmen – sie verfügen über das Portfolio-Engagement und die technische Tiefe, um zukünftige Trends frühzeitig zu erkennen. Ihre Thesen zu Stablecoins, KI-Agenten und Privatsphäre sind besonders überzeugend.

Wo wir anderer Meinung sind, ist der Zeitplan. Die Krypto-Industrie hat konsequent überschätzt, wie schnell transformative Technologien den Mainstream erreichen würden. SNARKs für allgemeine Berechnungen, KI-Agenten mit Krypto-Wallets und Consumer-Apps mit 100 Millionen Nutzern sind alle plausibel – nur nicht unbedingt im Jahr 2026.

Die sicherere Wette: schrittweise Fortschritte bei bewährten Anwendungsfällen (Stablecoins, DeFi, tokenisierte Assets), während spekulativere Anwendungen weiter reifen.

Für Entwickler ist die Botschaft klar: Fokus auf echten Nutzen statt auf Narrativ-Hype. Die Projekte, die das Blutbad von 2025 überlebt haben, waren diejenigen, die tatsächliche Einnahmen generierten und echte Nutzerbedürfnisse bedienten. Diese Lektion gilt unabhängig davon, welche Vorhersagen von a16z sich als richtig erweisen.

---

BlockEden.xyz bietet Blockchain-Infrastruktur auf Enterprise-Niveau für Entwickler, die auf langfristige Wertschöpfung setzen. Egal, ob Sie die nächste Stablecoin-Anwendung, eine KI-Agenten-Plattform oder einen RWA-Tokenisierungsdienst aufbauen, unsere APIs und Infrastrukturen sind so konzipiert, dass sie mit Ihrer Vision skalieren. Entdecken Sie unsere Services, um auf Fundamenten zu bauen, die auf Dauer ausgelegt sind.

Zama hat sich als der definitive Marktführer im Bereich Fully Homomorphic Encryption (FHE) für Blockchains etabliert und wurde im Juni 2025 zum weltweit ersten FHE-Unicorn mit einer Bewertung von 1 Milliarde US-Dollar, nachdem mehr als 150 Millionen US-Dollar eingesammelt wurden. Das in Paris ansässige Unternehmen konkurriert nicht mit Blockchains – es stellt die kryptografische Infrastruktur bereit, die es jeder EVM-Chain ermöglicht, verschlüsselte Smart Contracts zu verarbeiten, ohne die zugrunde liegenden Daten jemals zu entschlüsseln. Mit dem Start seines Mainnets auf Ethereum Ende Dezember 2025 und dem Beginn der $ZAMA Token-Auktion am 12. Januar 2026 befindet sich Zama an einem entscheidenden Wendepunkt, an dem theoretische kryptografische Durchbrüche auf eine produktionsreife Implementierung treffen.

Die strategische Bedeutung kann nicht hoch genug eingeschätzt werden: Während Zero-Knowledge-Proofs die Korrektheit von Berechnungen beweisen und Trusted Execution Environments auf Hardware-Sicherheit basieren, ermöglicht FHE auf einzigartige Weise Berechnungen auf verschlüsselten Daten von mehreren Parteien – und löst damit das fundamentale Blockchain-Trilemma zwischen Transparenz, Datenschutz und Compliance. Institutionen wie JP Morgan haben diesen Ansatz bereits durch das Projekt EPIC validiert und den vertraulichen Handel mit tokenisierten Vermögenswerten unter vollständiger Einhaltung regulatorischer Vorschriften demonstriert. Zamas Positionierung als Infrastruktur statt als konkurrierende Chain bedeutet, dass es unabhängig davon Wert schöpft, welche L1 oder L2 letztendlich dominiert.

---

Technische Architektur ermöglicht verschlüsselte Berechnungen ohne Vertrauensannahmen​

Die vollhomomorphe Verschlüsselung (Fully Homomorphic Encryption, FHE) stellt einen Durchbruch in der Kryptografie dar, der theoretisch seit 2009 existiert, aber erst vor Kurzem praktikabel wurde. Der Begriff „homomorph“ bezieht sich auf die mathematische Eigenschaft, bei der Operationen auf verschlüsselten Daten nach der Entschlüsselung identische Ergebnisse wie Operationen auf den ursprünglichen Klartextdaten liefern. Zamas Implementierung verwendet TFHE (Torus Fully Homomorphic Encryption), ein Verfahren, das sich durch schnelles Bootstrapping auszeichnet – die grundlegende Operation, die das akkumulierte Rauschen in Chiffretexten zurücksetzt und eine unbegrenzte Berechnungstiefe ermöglicht.

Die fhEVM-Architektur führt ein symbolisches Ausführungsmodell ein, das die Leistungsbeschränkungen der Blockchain elegant löst. Anstatt tatsächliche verschlüsselte Daten on-chain zu verarbeiten, werden Smart Contracts mit leichtgewichtigen Handles (Pointern) ausgeführt, während die eigentlichen FHE-Berechnungen asynchron auf spezialisierte Koprozessoren ausgelagert werden. Dieses Design bedeutet, dass Host-Chains wie Ethereum keine Modifikationen benötigen, Nicht-FHE-Transaktionen keine Verlangsamung erfahren und FHE-Operationen parallel statt sequentiell ausgeführt werden können. Die Architektur besteht aus fünf integrierten Komponenten: der fhEVM-Bibliothek für Solidity-Entwickler, Koprozessor-Nodes für FHE-Berechnungen, einem Key Management Service mit 13 MPC-Nodes mit Threshold-Entschlüsselung, einem Access Control List-Contract für programmierbaren Datenschutz und einem Gateway, das Cross-Chain-Operationen orchestriert.

Performance-Benchmarks zeigen schnelle Verbesserungen. Die Bootstrapping-Latenz – die kritische Metrik für FHE – sank von anfänglich 53 Millisekunden auf unter 1 Millisekunde auf NVIDIA H100 GPUs, wobei der Durchsatz 189.000 Bootstraps pro Sekunde über acht H100-GPUs erreichte. Der aktuelle Protokolldurchsatz liegt bei über 20 TPS auf der CPU, was für alle heute verschlüsselten Ethereum-Transaktionen ausreicht. Die Roadmap sieht 500 – 1.000 TPS bis Ende 2026 durch GPU-Migration vor, mit einer Skalierung auf über 100.000 TPS durch dedizierte ASICs in den Jahren 2027 – 2028. Im Gegensatz zu TEE-Lösungen, die anfällig für Hardware-Seitenkanalangriffe sind, ruht die Sicherheit von FHE auf gitterbasierten kryptografischen Härteannahmen, die Post-Quantum-Resistenz bieten.

---

Entwickler-Tools sind von der Forschung zur Produktion gereift​

Zamas Open-Source-Ökosystem umfasst vier miteinander verbundene Produkte, die über 5.000 Entwickler angezogen haben, was einem Marktanteil von etwa 70 % im Bereich Blockchain-FHE entspricht. Die TFHE-rs-Bibliothek bietet eine reine Rust-Implementierung mit GPU-Beschleunigung über CUDA, FPGA-Unterstützung durch AMD Alveo-Hardware und mehrstufige APIs, die von High-Level-Operationen bis hin zu kryptografischen Kern-Primitiven reichen. Die Bibliothek unterstützt verschlüsselte Ganzzahlen bis zu 256 Bit mit Operationen wie Arithmetik, Vergleichen und bedingten Verzweigungen.

Concrete fungiert als TFHE-Compiler auf Basis der LLVM/MLIR-Infrastruktur und wandelt Standard-Python-Programme in FHE-äquivalente Schaltkreise um. Entwickler benötigen keine Kryptografie-Expertise – sie schreiben normalen Python-Code und Concrete kümmert sich um die Komplexität der Schaltkreisoptimierung, Schlüsselgenerierung und das Management von Chiffretexten. Für Anwendungen des maschinellen Lernens bietet Concrete ML Ersatzlösungen für scikit-learn-Modelle, die automatisch in FHE-Schaltkreise kompiliert werden, und unterstützt lineare Modelle, baumbasierte Ensembles und sogar das verschlüsselte Fine-Tuning von LLMs. Version 1.8 demonstrierte das Fine-Tuning eines LLAMA 8B-Modells auf 100.000 verschlüsselten Token in etwa 70 Stunden.

Die fhEVM-Solidity-Bibliothek ermöglicht es Entwicklern, vertrauliche Smart Contracts mit vertrauter Syntax und verschlüsselten Typen (euint8 bis euint256, ebool, eaddress) zu schreiben. Ein verschlüsselter ERC-20 Transfer verwendet beispielsweise TFHE.le(), um verschlüsselte Guthaben zu vergleichen, und TFHE.select() für bedingte Logik – alles ohne Werte preiszugeben. Die Partnerschaft mit OpenZeppelin im September 2025 etablierte standardisierte Implementierungen für vertrauliche Token, Primitive für Auktionen mit verdeckten Geboten (sealed-bid) und Governance-Frameworks, die die Einführung in Unternehmen beschleunigen.

Geschäftsmodell schöpft Wert als Infrastrukturanbieter​

Zamas Finanzierungsverlauf spiegelt das wachsende institutionelle Vertrauen wider : eine $73 Millionen Series - A** im März 2024 unter der Leitung von Multicoin Capital und Protocol Labs , gefolgt von einer **$ 57 Millionen Series - B im Juni 2025 unter der Leitung von Pantera Capital , die den Unicorn - Status erreichte . Die Liste der Investoren liest sich wie die Elite der Blockchain - Welt — Juan Benet ( Gründer und Vorstandsmitglied von Filecoin ) , Gavin Wood ( Mitbegründer von Ethereum und Polkadot ) , Anatoly Yakovenko ( Mitbegründer von Solana ) und Tarun Chitra ( Gründer von Gauntlet ) nahmen alle teil .

Das Erlösmodell nutzt eine BSD3 - Clear Dual - Licensing - Strategie : Die Technologien bleiben für nicht - kommerzielle Forschung und Prototyping kostenlos , während der produktive Einsatz den Erwerb von Patentnutzungsrechten erfordert . Bis März 2024 hatte Zama innerhalb von sechs Monaten nach der Kommerzialisierung Verträge im Wert von über **$50 Millionen** unterzeichnet , wobei sich hunderte weitere Kunden in der Pipeline befinden . Für private Blockchain - Deployments gilt eine transaktionsbasierte Preisgestaltung , während Kryptoprojekte häufig in Token bezahlen . Das kommende Zama - Protokoll führt eine On - Chain - Ökonomie ein : Betreiber staken$ ZAMA , um sich für Verschlüsselungs - und Entschlüsselungsarbeiten zu qualifizieren , mit Gebühren zwischen $0,005 -$ 0,50 pro ZKPoK - Verifizierung und $0,001 -$ 0,10 pro Entschlüsselungsvorgang .

Das Team stellt die weltweit größte dedizierte FHE - Forschungsorganisation dar : 96 + Mitarbeiter aus 26 Nationalitäten , von denen 37 einen Doktortitel ( PhD ) halten ( ~ 40 % der Belegschaft ) . Mitbegründer und CTO Pascal Paillier erfand das Paillier - Verschlüsselungsverfahren , das in Milliarden von Smartcards verwendet wird , und erhielt 2025 die prestigeträchtige IACR - Fellowship . CEO Rand Hindi gründete zuvor Snips , eine KI - Sprachplattform , die von Sonos übernommen wurde . Diese Konzentration kryptografischer Talente schafft erhebliche Burggräben durch geistiges Eigentum — Paillier hält etwa 25 Patentfamilien zum Schutz von Kerninnovationen .

---

Wettbewerbspositionierung als „ Schaufel und Spitzhacke “ - Ansatz für Blockchain - Privatsphäre​

Die Landschaft der Privatsphäre - Lösungen unterteilt sich in drei grundlegende Ansätze mit jeweils unterschiedlichen Kompromissen . Trusted Execution Environments ( TEEs ) , die von Secret Network und Oasis Network verwendet werden , bieten nahezu native Performance , verlassen sich jedoch auf Hardwaresicherheit mit einer Vertrauensschwelle von eins — wenn die Enklave kompromittiert wird , bricht die gesamte Privatsphäre zusammen . Die Offenlegung von TEE - Schwachstellen im Oktober 2022 , die das Secret Network betrafen , unterstrich diese Risiken . Zero - Knowledge - Proofs , die vom Aztec Protocol ( $ 100 Mio . Series - B von a16z ) eingesetzt werden , beweisen die Korrektheit der Berechnung , ohne Eingabewerte preiszugeben , können aber nicht auf verschlüsselten Daten von mehreren Parteien rechnen — was ihre Anwendbarkeit für Shared - State - Anwendungen wie Lending - Pools einschränkt .

FHE nimmt eine einzigartige Position ein : mathematisch garantierte Privatsphäre mit konfigurierbaren Vertrauensschwellen , keine Hardwareabhängigkeiten und die entscheidende Fähigkeit , verschlüsselte Daten aus mehreren Quellen zu verarbeiten . Dies ermöglicht Anwendungsfälle , die mit anderen Ansätzen unmöglich sind — vertrauliche AMMs , die über verschlüsselte Reserven von Liquiditätsanbietern rechnen , oder Lending - Protokolle , die verschlüsselte Besicherungspositionen verwalten .

Innerhalb von FHE agiert Zama speziell als Infrastrukturschicht , während andere darauf Chains aufbauen . Fhenix ( $22 Mio . gesammelt ) baut ein Optimistic Rollup L2 unter Verwendung von Zamas TFHE - rs über eine Partnerschaft auf und hat den CoFHE - Koprozessor auf Arbitrum als erste praktische FHE - Implementierung bereitgestellt . **Inco Network** ($ 4,5 Mio . gesammelt ) bietet Confidentiality - as - a - Service für bestehende Chains unter Verwendung von Zamas fhEVM an und bietet sowohl TEE - basierte schnelle Verarbeitung als auch FHE + MPC sichere Berechnungen . Beide Projekte hängen von Zamas Kerntechnologie ab — was bedeutet , dass Zama unabhängig davon Wert schöpft , welche FHE - Chain an Dominanz gewinnt . Diese Infrastrukturpositionierung spiegelt wider , wie OpenZeppelin von der Smart - Contract - Einführung profitiert , ohne direkt mit Ethereum zu konkurrieren .

---

Anwendungsfälle erstrecken sich über DeFi , KI , RWAs und konforme Zahlungen​

Im Bereich DeFi löst FHE grundlegend das MEV - Problem ( Maximal Extractable Value ) . Da Transaktionsparameter bis zum Einschluss in den Block verschlüsselt bleiben , werden Front - Running - und Sandwich - Attacken mathematisch unmöglich — es gibt schlichtweg keine sichtbaren Mempool - Daten , die ausgenutzt werden könnten . Die ZamaSwap - Referenzimplementierung demonstriert verschlüsselte AMM - Swaps mit vollständig verschlüsselten Salden und Poolreserven . Über den MEV - Schutz hinaus können vertrauliche Lending - Protokolle verschlüsselte Besicherungspositionen und Liquidationsschwellen aufrechterhalten , was On - Chain - Credit - Scorings ermöglicht , die über privaten Finanzdaten berechnet werden .

Für KI und maschinelles Lernen ermöglicht Concrete ML datenschutzfreundliche Berechnungen im Gesundheitswesen ( verschlüsselte medizinische Diagnosen ) , im Finanzwesen ( Betrugserkennung bei verschlüsselten Transaktionen ) und in der Biometrie ( Authentifizierung ohne Preisgabe der Identität ) . Das Framework unterstützt verschlüsseltes LLM - Feintuning — das Training von Sprachmodellen auf sensiblen Daten , die niemals die verschlüsselte Form verlassen . Während KI - Agenten in der Web3 - Infrastruktur zunehmen , bietet FHE die vertrauliche Berechnungsschicht , die den Datenschutz gewährleistet , ohne den Nutzen zu opfern .

Die Tokenisierung von Real - World Assets ( RWA ) stellt vielleicht die größte Chance dar . Der Proof - of - Concept des JP Morgan Kinexys Project EPIC demonstrierte die Tokenisierung institutioneller Vermögenswerte mit verschlüsselten Gebotsbeträgen , verborgenen Anlegerbeständen und KYC / AML - Prüfungen auf verschlüsselten Daten — unter Wahrung der vollständigen regulatorischen Compliance . Dies adressiert die grundlegende Barriere , die das traditionelle Finanzwesen daran hindert , öffentliche Blockchains zu nutzen : die Unfähigkeit , Handelsstrategien und Positionen vor Wettbewerbern zu verbergen . Da für tokenisierte RWAs ein adressierbarer Markt von über $ 100 Billionen prognostiziert wird , erschließt FHE die institutionelle Teilnahme , die private Blockchains nicht bedienen können .

Zahlungs - und Stablecoin - Privatsphäre vervollständigt das Bild . Der Mainnet - Launch im Dezember 2025 beinhaltete den ersten vertraulichen Stablecoin - Transfer unter Verwendung von cUSDT . Im Gegensatz zu Mixing - basierten Ansätzen ( Tornado Cash ) ermöglicht FHE programmierbare Compliance — Entwickler definieren Zugriffskontrollregeln , die festlegen , wer was entschlüsseln kann , was eine regulatorisch konforme Privatsphäre anstelle von absoluter Anonymität ermöglicht . Autorisierte Prüfer und Regulierungsbehörden erhalten angemessenen Zugriff , ohne die allgemeine Transaktionsprivatsphäre zu gefährden .

---

Regulierungslandschaft schafft Rückenwind für konformen Datenschutz​

Die MiCA-Verordnung der EU, die seit dem 30. Dezember 2024 vollständig in Kraft ist, schafft eine starke Nachfrage nach Datenschutzlösungen, die konform bleiben. Die Travel Rule verpflichtet Krypto-Dienstleister dazu, Daten über Absender und Empfänger bei allen Übertragungen zu teilen, ohne einen Schwellenwert (de minimis) – was Privacy-by-Default-Ansätze wie Mixing unpraktisch macht. Die Mechanismen der selektiven Offenlegung von FHE entsprechen genau dieser Anforderung: Transaktionen bleiben vor allgemeiner Beobachtung verschlüsselt, während autorisierte Parteien auf die notwendigen Informationen zugreifen können.

In den Vereinigten Staaten schaffte die Unterzeichnung des GENIUS Act im Juli 2025 den ersten umfassenden föderalen Rahmen für Stablecoins und signalisierte eine regulatorische Reife, die konforme Datenschutzlösungen gegenüber regulatorischer Umgehung bevorzugt. Die Asien-Pazifik-Region treibt weiterhin fortschrittliche Rahmenbedingungen voran, wobei das Stablecoin-Regulierungssystem in Hongkong im August 2025 in Kraft tritt und Singapur seine führende Rolle bei der Krypto-Lizenzierung behauptet. Über alle Jurisdiktionen hinweg begünstigt das Muster Lösungen, die sowohl Datenschutz als auch regulatorische Compliance ermöglichen – genau das Wertversprechen von Zama.

Die Verschiebung der Durchsetzung im Jahr 2025 von reaktiver Strafverfolgung hin zu proaktiven Rahmenbedingungen schafft Chancen für die Einführung von FHE. Projekte, die von Anfang an mit konformen Datenschutzarchitekturen bauen – anstatt Privacy-First-Designs nachträglich für die Compliance anzupassen – werden einfachere Wege zur institutionellen Akzeptanz und regulatorischen Genehmigung finden.

---

Technische und marktbezogene Herausforderungen erfordern sorgfältige Navigation​

Die Performance bleibt das primäre Hindernis, obwohl der Trend klar ist. FHE-Operationen laufen derzeit etwa 100-mal langsamer als ihre Klartext-Äquivalente – akzeptabel für Transaktionen mit geringer Frequenz und hohem Wert, aber einschränkend für Anwendungen mit hohem Durchsatz. Die Roadmap für die Skalierung hängt von der Hardwarebeschleunigung ab: GPU-Migration im Jahr 2026, FPGA-Optimierung und letztendlich spezialgefertigte ASICs. Die Finanzierung des DARPA DPRIVE-Programms für Intel, Duality, SRI und Niobium zur Entwicklung von FHE-Beschleunigern stellt eine bedeutende staatliche Investition dar, die diesen Zeitplan beschleunigt.

Die Schlüsselverwaltung bringt ihre eigenen Komplexitäten mit sich. Das derzeitige MPC-Komitee aus 13 Knoten für die Schwellenwert-Entschlüsselung erfordert Annahmen über eine ehrliche Mehrheit – Absprachen unter den Schwellenwert-Knoten könnten „stille Angriffe“ ermöglichen, die für andere Teilnehmer nicht erkennbar sind. Die Roadmap sieht eine Erweiterung auf über 100 Knoten mit HSM-Integration und Post-Quanten-ZK-Proofs vor, was diese Garantien stärkt.

Konkurrenz durch TEE- und ZK-Alternativen sollte nicht unterschätzt werden. Secret Network und Oasis bieten produktionsreife Confidential-Computing-Lösungen mit wesentlich besserer aktueller Performance. Die Unterstützung von Aztec in Höhe von 100 Millionen US-Dollar und das Team, das PLONK erfunden hat – die dominierende ZK-SNARK-Konstruktion –, bedeuten einen formidablen Wettbewerb bei datenschutzfreundlichen Rollups. Der Performance-Vorteil von TEE könnte bestehen bleiben, wenn sich die Hardwaresicherheit schneller verbessert als die FHE-Beschleunigung, obwohl Hardware-Trust-Annahmen eine fundamentale Obergrenze schaffen, die ZK- und FHE-Lösungen nicht teilen.

---

Fazit: Infrastruktur-Positionierung schöpft Wert über das Ökosystemwachstum ab​

Zamas strategisches Geschick liegt in seiner Positionierung als Infrastruktur und nicht als konkurrierende Chain. Sowohl Fhenix als auch Inco – die führenden FHE-Blockchain-Implementierungen – bauen auf der TFHE-rs- und fhEVM-Technologie von Zama auf. Das bedeutet, dass Zama Lizenzgebühren einnimmt, unabhängig davon, welches Protokoll sich durchsetzt. Das duale Lizenzmodell stellt sicher, dass die Akzeptanz durch Open-Source-Entwickler die Nachfrage von kommerziellen Unternehmen antreibt, während der im Januar 2026 startende $ZAMA-Token eine On-Chain-Ökonomie schafft, die die Anreize der Betreiber mit dem Netzwerkwachstum in Einklang bringt.

Drei Faktoren werden über den endgültigen Erfolg von Zama entscheiden: Umsetzung der Performance-Roadmap von heute 20 TPS auf über 100.000 TPS mit ASICs; institutionelle Akzeptanz nach der Validierung durch JP Morgan; und das Wachstum des Entwickler-Ökosystems über die derzeitigen 5.000 Entwickler hinaus bis hin zur allgemeinen Web3-Penetration. Das regulatorische Umfeld hat sich entscheidend zugunsten von konformem Datenschutz verschoben, und die einzigartige Fähigkeit von FHE für verschlüsselte Multi-Party-Computation adressiert Anwendungsfälle, die weder ZK noch TEE bedienen können.

Für Web3-Forscher und Investoren stellt Zama die klassische „Spitzhacken und Schaufeln“-Gelegenheit im Bereich Blockchain-Datenschutz dar – eine Infrastruktur, die Wert abschöpft, während der Confidential-Computing-Layer in den Bereichen DeFi, KI, RWAs und bei institutioneller Akzeptanz reift. Die Bewertung von 1 Milliarde US-Dollar spiegelt ein erhebliches Umsetzungsrisiko wider, aber eine erfolgreiche Lieferung der technischen Roadmap könnte Zama als unverzichtbare Infrastruktur für das nächste Jahrzehnt der Blockchain-Entwicklung positionieren.

Öffentliche Blockchains bieten jedem Teilnehmer ein synchronisiertes, auditierbares Ledger – doch sie legen standardmäßig auch jedes Datenelement offen. Seal, seit dem 3. September 2025 live im Sui Mainnet, begegnet diesem Problem, indem es On-Chain-Richtlinienlogik mit dezentraler Schlüsselverwaltung kombiniert, sodass Web3-Entwickler genau entscheiden können, wer welche Payloads entschlüsseln darf.

TL;DR​

• Was es ist: Seal ist ein Netzwerk zur Geheimnisverwaltung, das Sui-Smart Contracts ermöglicht, Entschlüsselungsrichtlinien On-Chain durchzusetzen, während Clients Daten mit identitätsbasierter Verschlüsselung (IBE) verschlüsseln und sich für die Schlüsselableitung auf Schwellenwert-Schlüsselserver verlassen.
• Warum es wichtig ist: Anstelle von benutzerdefinierten Backends oder undurchsichtigen Off-Chain-Skripten werden Datenschutz und Zugriffskontrolle zu erstklassigen Move-Primitiven. Entwickler können Chiffriertexte überall speichern – Walrus ist der natürliche Begleiter – aber dennoch steuern, wer lesen darf.
• Wer profitiert: Teams, die Token-gesteuerte Medien, zeitgesteuerte Offenlegungen, private Nachrichten oder richtlinienbewusste KI-Agenten bereitstellen, können das SDK von Seal nutzen und sich auf die Produktlogik konzentrieren, anstatt auf maßgeschneiderte Krypto-Infrastruktur.

Richtlinienlogik lebt in Move​

Seal-Pakete enthalten seal_approve* Move-Funktionen, die definieren, wer Schlüssel für eine bestimmte Identitätszeichenfolge und unter welchen Bedingungen anfordern kann. Richtlinien können NFT-Besitz, Whitelists, Zeit-Sperren oder benutzerdefinierte Rollensysteme mischen. Wenn ein Benutzer oder Agent die Entschlüsselung anfordert, bewerten die Schlüsselserver diese Richtlinien über den Sui-Full-Node-Status und genehmigen nur, wenn die Kette zustimmt.

Da die Zugriffsregeln Teil Ihres On-Chain-Pakets sind, sind sie transparent, auditierbar und versionierbar, zusammen mit dem Rest Ihres Smart-Contract-Codes. Governance-Updates können wie jedes andere Move-Upgrade ausgerollt werden, mit Community-Überprüfung und On-Chain-Historie.

Schwellenwert-Kryptographie verwaltet die Schlüssel​

Seal verschlüsselt Daten für anwendungsdefinierte Identitäten. Ein Komitee unabhängiger Schlüsselserver – vom Entwickler ausgewählt – teilt das IBE-Master-Geheimnis. Wenn eine Richtlinienprüfung erfolgreich ist, leitet jeder Server einen Schlüsselanteil für die angeforderte Identität ab. Sobald ein Quorum von t Servern antwortet, kombiniert der Client die Anteile zu einem nutzbaren Entschlüsselungsschlüssel.

Sie können den Kompromiss zwischen Lebendigkeit und Vertraulichkeit festlegen, indem Sie Komiteemitglieder (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One oder Mystens Enoki-Dienst) auswählen und den Schwellenwert bestimmen. Benötigen Sie eine stärkere Verfügbarkeit? Wählen Sie ein größeres Komitee mit einem niedrigeren Schwellenwert. Wünschen Sie höhere Datenschutzgarantien? Ziehen Sie das Quorum enger und verlassen Sie sich auf zugelassene Anbieter.

Entwicklererfahrung: SDKs und Sitzungsschlüssel​

Seal liefert ein TypeScript SDK (npm i @mysten/seal), das Verschlüsselungs-/Entschlüsselungsabläufe, Identitätsformatierung und Batching handhabt. Es gibt auch Sitzungsschlüssel aus, damit Wallets nicht ständig mit Aufforderungen bombardiert werden, wenn eine App wiederholten Zugriff benötigt. Für fortgeschrittene Workflows können Move-Kontrakte On-Chain-Entschlüsselung über spezialisierte Modi anfordern, wodurch Logik wie Treuhand-Offenlegungen oder MEV-resistente Auktionen direkt im Smart-Contract-Code ausgeführt werden können.

Da Seal speicherunabhängig ist, können Teams es mit Walrus für überprüfbaren Blob-Speicher, mit IPFS oder sogar mit zentralisierten Speichern kombinieren, wenn dies den operativen Realitäten entspricht. Die Verschlüsselungsgrenze – und ihre Richtliniendurchsetzung – wandert mit den Daten, unabhängig davon, wo der Chiffriertext gespeichert ist.

Design mit Seal: Best Practices​

• Verfügbarkeitsrisiko modellieren: Schwellenwerte wie 2-von-3 oder 3-von-5 entsprechen direkt den Verfügbarkeitsgarantien. Produktionsbereitstellungen sollten Anbieter mischen, Telemetrie überwachen und SLAs aushandeln, bevor kritische Workflows anvertraut werden.
• Auf Zustandsvarianz achten: Die Richtlinienbewertung hängt davon ab, dass Full Nodes dry_run-Aufrufe durchführen. Vermeiden Sie Regeln, die von sich schnell ändernden Zählern oder der Reihenfolge innerhalb von Checkpoints abhängen, um inkonsistente Genehmigungen über Server hinweg zu verhindern.
• Schlüsselhygiene planen: Abgeleitete Schlüssel befinden sich auf dem Client. Instrumentieren Sie die Protokollierung, rotieren Sie Sitzungsschlüssel und erwägen Sie die Umschlagverschlüsselung – verwenden Sie Seal, um einen symmetrischen Schlüssel zu schützen, der die größere Payload verschlüsselt –, um den Schadensradius zu begrenzen, falls ein Gerät kompromittiert wird.
• Rotation architektonisch planen: Das Komitee eines Chiffriertextes ist zum Zeitpunkt der Verschlüsselung festgelegt. Erstellen Sie Upgrade-Pfade, die Daten durch neue Komitees neu verschlüsseln, wenn Sie Anbieter wechseln oder Vertrauensannahmen anpassen müssen.

Was als Nächstes kommt​

Die Roadmap von Seal weist auf von Validatoren betriebene MPC-Server, DRM-ähnliche Client-Tools und Post-Quanten-KEM-Optionen hin. Für Entwickler, die KI-Agenten, Premium-Inhalte oder regulierte Datenflüsse erforschen, bietet die heutige Veröffentlichung bereits einen klaren Bauplan: Kodieren Sie Ihre Richtlinie in Move, stellen Sie ein vielfältiges Schlüsselkomitee zusammen und liefern Sie verschlüsselte Erlebnisse, die die Privatsphäre der Benutzer respektieren, ohne die Vertrauensgrenze von Sui zu verlassen.

Wenn Sie Seal für Ihren nächsten Start in Betracht ziehen, beginnen Sie mit dem Prototyping einer einfachen NFT-gesteuerten Richtlinie mit einem offenen 2-von-3-Komitee und iterieren Sie dann zu der Anbieterkombination und den operativen Kontrollen, die dem Risikoprofil Ihrer App entsprechen.

1. Überblick über die TEE-Technologie​

Definition und Architektur: Eine Trusted Execution Environment (TEE) ist ein sicherer Bereich eines Prozessors, der den darin geladenen Code und die Daten im Hinblick auf Vertraulichkeit und Integrität schützt. In der Praxis fungiert eine TEE als isolierte „Enklave“ innerhalb der CPU – eine Art Black Box, in der sensible Berechnungen geschützt vom Rest des Systems ausgeführt werden können. Code, der innerhalb einer TEE-Enklave ausgeführt wird, ist so geschützt, dass selbst ein kompromittiertes Betriebssystem oder ein Hypervisor die Daten oder den Code der Enklave nicht lesen oder manipulieren kann. Die wichtigsten von TEEs bereitgestellten Sicherheitseigenschaften umfassen:

• Isolierung: Der Speicher der Enklave ist von anderen Prozessen und sogar vom Betriebssystemkern isoliert. Selbst wenn ein Angreifer volle Administratorrechte auf der Maschine erhält, kann er den Speicher der Enklave nicht direkt inspizieren oder modifizieren.
• Integrität: Die Hardware stellt sicher, dass Code, der in der TEE ausgeführt wird, nicht durch externe Angriffe verändert werden kann. Jede Manipulation des Enklaven-Codes oder des Laufzeitstatus wird erkannt, was kompromittierte Ergebnisse verhindert.
• Vertraulichkeit: Daten innerhalb der Enklave bleiben im Speicher verschlüsselt und werden nur für die Verwendung innerhalb der CPU entschlüsselt, sodass geheime Daten der Außenwelt nicht im Klartext zugänglich sind.
• Remote Attestation: Die TEE kann kryptografische Beweise (Attestierungen) erstellen, um eine entfernte Partei davon zu überzeugen, dass sie echt ist und dass spezifischer vertrauenswürdiger Code darin ausgeführt wird. Dies bedeutet, dass Benutzer überprüfen können, ob sich eine Enklave in einem vertrauenswürdigen Zustand befindet (z. B. Ausführung des erwarteten Codes auf echter Hardware), bevor sie sie mit geheimen Daten versorgen.

Konzeptionelles Diagramm einer Trusted Execution Environment als sichere Enklave „Black Box“ für die Ausführung von Smart Contracts. Verschlüsselte Eingaben (Daten und Vertragscode) werden innerhalb der sicheren Enklave entschlüsselt und verarbeitet, und nur verschlüsselte Ergebnisse verlassen die Enklave. Dies stellt sicher, dass sensible Vertragsdaten für jeden außerhalb der TEE vertraulich bleiben.

Unter der Haube werden TEEs durch hardwarebasierte Speicherverschlüsselung und Zugriffskontrolle in der CPU ermöglicht. Wenn beispielsweise eine TEE-Enklave erstellt wird, weist die CPU ihr einen geschützten Speicherbereich zu und verwendet dedizierte Schlüssel (die in die Hardware eingebrannt sind oder von einem sicheren Koprozessor verwaltet werden), um Daten on-the-fly zu verschlüsseln/entschlüsseln. Jeder Versuch von externer Software, den Enklavenspeicher zu lesen, liefert nur verschlüsselte Bytes. Dieser einzigartige Schutz auf CPU-Ebene ermöglicht es sogar Code auf Benutzerebene, private Speicherbereiche (Enklaven) zu definieren, die privilegierte Malware oder sogar ein böswilliger Systemadministrator nicht ausspähen oder modifizieren kann. Im Wesentlichen bietet eine TEE ein höheres Sicherheitsniveau für Anwendungen als die normale Betriebsumgebung, während sie gleichzeitig flexibler ist als dedizierte Sicherheitselemente oder Hardware-Sicherheitsmodule.

Wichtige Hardware-Implementierungen: Es existieren mehrere Hardware-TEE-Technologien, jede mit unterschiedlichen Architekturen, aber dem ähnlichen Ziel, eine sichere Enklave innerhalb des Systems zu schaffen:

• Intel SGX (Software Guard Extensions): Intel SGX ist eine der am weitesten verbreiteten TEE-Implementierungen. Sie ermöglicht es Anwendungen, Enklaven auf Prozessebene zu erstellen, wobei Speicherverschlüsselung und Zugriffskontrollen von der CPU erzwungen werden. Entwickler müssen ihren Code in „vertrauenswürdigen“ Code (innerhalb der Enklave) und „nicht vertrauenswürdigen“ Code (normale Welt) aufteilen und spezielle Anweisungen (ECALL/OCALL) verwenden, um Daten in die Enklave hinein und aus ihr heraus zu transferieren. SGX bietet eine starke Isolierung für Enklaven und unterstützt Remote Attestation über Intels Attestation Service (IAS). Viele Blockchain-Projekte – insbesondere Secret Network und Oasis Network – haben datenschutzfreundliche Smart-Contract-Funktionalitäten auf SGX-Enklaven aufgebaut. Das Design von SGX auf komplexen x86-Architekturen hat jedoch zu einigen Schwachstellen geführt (siehe §4), und die Attestierung von Intel führt eine zentralisierte Vertrauensabhängigkeit ein.

• ARM TrustZone: TrustZone verfolgt einen anderen Ansatz, indem es die gesamte Ausführungsumgebung des Prozessors in zwei Welten unterteilt: eine Secure World und eine Normal World. Sensibler Code läuft in der Secure World, die Zugriff auf bestimmte geschützte Speicherbereiche und Peripheriegeräte hat, während die Normal World das reguläre Betriebssystem und die Anwendungen ausführt. Wechsel zwischen den Welten werden von der CPU gesteuert. TrustZone wird häufig in Mobil- und IoT-Geräten für Dinge wie sichere Benutzeroberflächen, Zahlungsabwicklung oder digitales Rechtemanagement verwendet. In einem Blockchain-Kontext könnte TrustZone mobile-first Web3-Anwendungen ermöglichen, indem private Schlüssel oder sensible Logik in der sicheren Enklave des Telefons ausgeführt werden. TrustZone-Enklaven sind jedoch typischerweise grobkörniger (auf Betriebssystem- oder VM-Ebene) und werden in aktuellen Web3-Projekten nicht so häufig eingesetzt wie SGX.

• AMD SEV (Secure Encrypted Virtualization): Die SEV-Technologie von AMD zielt auf virtualisierte Umgebungen ab. Anstatt Enklaven auf Anwendungsebene zu erfordern, kann SEV den Speicher ganzer virtueller Maschinen verschlüsseln. Es verwendet einen eingebetteten Sicherheitsprozessor zur Verwaltung kryptografischer Schlüssel und zur Durchführung der Speicherverschlüsselung, sodass der Speicher einer VM selbst für den hostenden Hypervisor vertraulich bleibt. Dies macht SEV gut geeignet für Cloud- oder Server-Anwendungsfälle: Beispielsweise könnte ein Blockchain-Knoten oder ein Off-Chain-Worker innerhalb einer vollständig verschlüsselten VM laufen und seine Daten vor einem böswilligen Cloud-Anbieter schützen. Das Design von SEV bedeutet weniger Aufwand für Entwickler bei der Partitionierung von Code (man kann eine bestehende Anwendung oder sogar ein ganzes Betriebssystem in einer geschützten VM ausführen). Neuere Iterationen wie SEV-SNP fügen Funktionen wie Manipulationserkennung hinzu und ermöglichen es VM-Besitzern, ihre VMs zu attestieren, ohne auf einen zentralisierten Dienst angewiesen zu sein. SEV ist für den TEE-Einsatz in Cloud-basierter Blockchain-Infrastruktur hochrelevant.

Andere aufkommende oder Nischen-TEE-Implementierungen umfassen Intel TDX (Trust Domain Extensions für enklavenähnlichen Schutz in VMs auf neueren Intel-Chips), Open-Source-TEEs wie Keystone (RISC-V) und Secure-Enclave-Chips in Mobilgeräten (wie die Secure Enclave von Apple, obwohl sie normalerweise nicht für beliebigen Code offen ist). Jede TEE bringt ihr eigenes Entwicklungsmodell und ihre eigenen Vertrauensannahmen mit, aber alle teilen die Kernidee der hardware-isolierten sicheren Ausführung.

Privatsphäre-wahrende Smart Contracts​

Eine der bekanntesten Anwendungen von TEEs in Web3 ist die Ermöglichung von vertraulichen Smart Contracts – Programmen, die auf einer Blockchain laufen, aber private Daten sicher verarbeiten können. Blockchains wie Ethereum sind standardmäßig transparent: Alle Transaktionsdaten und der Vertragsstatus sind öffentlich. Diese Transparenz ist problematisch für Anwendungsfälle, die Vertraulichkeit erfordern (z. B. private Finanzgeschäfte, geheime Abstimmungen, Verarbeitung personenbezogener Daten). TEEs bieten eine Lösung, indem sie als privatsphärenschonende Rechenenklave fungieren, die mit der Blockchain verbunden ist.

In einem TEE-gestützten Smart-Contract-System können Transaktionseingaben an eine sichere Enklave auf einem Validator- oder Worker-Node gesendet werden. Dort werden sie innerhalb der Enklave verarbeitet, wo sie für die Außenwelt verschlüsselt bleiben. Anschließend kann die Enklave ein verschlüsseltes oder gehashtes Ergebnis zurück an die Chain ausgeben. Nur autorisierte Parteien mit dem Entschlüsselungsschlüssel (oder die Vertragslogik selbst) können auf das Klartextergebnis zugreifen. Zum Beispiel verwendet das Secret Network Intel SGX in seinen Konsens-Nodes, um CosmWasm-Smart-Contracts mit verschlüsselten Eingaben auszuführen. So können Dinge wie Kontostände, Transaktionsbeträge oder der Vertragsstatus vor der Öffentlichkeit verborgen bleiben, während sie dennoch für Berechnungen nutzbar sind. Dies hat Secret DeFi-Anwendungen ermöglicht – z. B. private Token-Swaps, bei denen die Beträge vertraulich sind, oder geheime Auktionen, bei denen Gebote verschlüsselt und erst nach Auktionsende offengelegt werden. Ein weiteres Beispiel ist das Parcel von Oasis Network und das vertrauliche ParaTime, die es ermöglichen, Daten zu tokenisieren und in Smart Contracts unter Vertraulichkeitsbeschränkungen zu nutzen, was Anwendungsfälle wie Kredit-Scoring oder medizinische Daten auf der Blockchain unter Einhaltung des Datenschutzes ermöglicht.

Privatsphäre-wahrende Smart Contracts via TEEs sind attraktiv für die Einführung von Blockchain in Unternehmen und Institutionen. Organisationen können Smart Contracts nutzen und gleichzeitig sensible Geschäftslogik und Daten vertraulich behandeln. Beispielsweise könnte eine Bank einen TEE-fähigen Vertrag verwenden, um Kreditanträge oder Handelsabwicklungen zu bearbeiten, ohne Kundendaten on-chain preiszugeben, und dennoch von der Transparenz und Integrität der Blockchain-Verifizierung profitieren. Diese Fähigkeit adressiert direkt regulatorische Datenschutzanforderungen (wie die DSGVO oder HIPAA) und ermöglicht die konforme Nutzung von Blockchain im Gesundheitswesen, im Finanzwesen und in anderen sensiblen Branchen. Tatsächlich erleichtern TEEs die Einhaltung von Datenschutzgesetzen, indem sie sicherstellen, dass personenbezogene Daten innerhalb einer Enklave verarbeitet werden können und nur verschlüsselte Ausgaben nach außen gelangen, was die Regulierungsbehörden davon überzeugt, dass die Daten geschützt sind.

Über die Vertraulichkeit hinaus helfen TEEs auch dabei, die Fairness in Smart Contracts zu erzwingen. Beispielsweise könnte eine dezentrale Börse ihre Matching-Engine innerhalb einer TEE ausführen, um zu verhindern, dass Miner oder Validatoren ausstehende Aufträge sehen und Transaktionen unzulässig durch Front-Running manipulieren. Zusammenfassend lässt sich sagen, dass TEEs eine dringend benötigte Privatsphäre-Schicht in Web3 bringen und Anwendungen wie vertrauliches DeFi, private Abstimmungen/Governance und Unternehmensverträge freischalten, die zuvor auf öffentlichen Ledgern nicht machbar waren.

Skalierbarkeit und Off-Chain-Berechnung​

Eine weitere kritische Rolle für TEEs ist die Verbesserung der Blockchain-Skalierbarkeit durch das Auslagern schwerer Berechnungen off-chain in eine sichere Umgebung. Blockchains haben aufgrund von Leistungsgrenzen und Kosten für die On-Chain-Ausführung Schwierigkeiten mit komplexen oder rechenintensiven Aufgaben. TEE-fähige Off-Chain-Berechnungen ermöglichen es, diese Aufgaben außerhalb der Haupt-Chain zu erledigen (wodurch kein Block-Gas verbraucht oder der On-Chain-Durchsatz verlangsamt wird), während gleichzeitig Vertrauensgarantien über die Korrektheit der Ergebnisse erhalten bleiben. Effektiv kann eine TEE als verifizierbarer Off-Chain-Rechenbeschleuniger für Web3 dienen.

Beispielsweise nutzt die Plattform iExec TEEs, um einen dezentralen Cloud-Computing-Marktplatz zu schaffen, auf dem Entwickler Berechnungen off-chain ausführen können und Ergebnisse erhalten, denen die Blockchain vertraut. Eine dApp kann eine Berechnung anfordern (z. B. eine komplexe KI-Modell-Inferenz oder eine Big-Data-Analyse), die von iExec-Worker-Nodes durchgeführt werden soll. Diese Worker-Nodes führen die Aufgabe innerhalb einer SGX-Enklave aus und produzieren ein Ergebnis zusammen mit einem Attest (Nachweis), dass der korrekte Code in einer echten Enklave lief. Das Ergebnis wird dann on-chain zurückgegeben, und der Smart Contract kann das Attest der Enklave verifizieren, bevor er die Ausgabe akzeptiert. Diese Architektur ermöglicht es, schwere Arbeitslasten off-chain zu bewältigen, ohne auf Vertrauen zu verzichten, was den Durchsatz effektiv steigert. Die Integration des iExec Orchestrators mit Chainlink demonstriert dies: Ein Chainlink-Oracle ruft externe Daten ab, übergibt dann eine komplexe Berechnung an die TEE-Worker von iExec (z. B. Aggregieren oder Bewerten der Daten), und schließlich wird das sichere Ergebnis on-chain geliefert. Anwendungsfälle umfassen Dinge wie dezentrale Versicherungsberechnungen (wie iExec gezeigt hat), bei denen eine große Menge an Datenverarbeitung kostengünstig off-chain durchgeführt werden kann, wobei nur das Endergebnis auf die Blockchain gelangt.

TEE-basierte Off-Chain-Berechnungen bilden auch die Grundlage für einige Layer-2-Skalierungslösungen. Der frühe Prototyp von Oasis Labs, Ekiden (der Vorläufer des Oasis Network), nutzte SGX-Enklaven, um die Transaktionsausführung off-chain parallel auszuführen und dann nur State Roots an die Haupt-Chain zu übermitteln – im Prinzip ähnlich wie Rollup-Ideen, aber unter Verwendung von Hardware-Vertrauen. Durch die Vertragsausführung in TEEs erreichten sie einen hohen Durchsatz, während sie sich auf Enklaven verließen, um die Sicherheit zu gewährleisten. Ein weiteres Beispiel ist das kommende Op-Succinct L2 von Sanders Network, das TEEs und zkSNARKs kombiniert: TEEs führen Transaktionen privat und schnell aus, und anschließend werden ZK-Proofs generiert, um Ethereum die Korrektheit dieser Ausführungen zu beweisen. Dieser hybride Ansatz nutzt die Geschwindigkeit von TEEs und die Verifizierbarkeit von ZK für eine skalierbare, private L2-Lösung.

Im Allgemeinen können TEEs Berechnungen mit nahezu nativer Leistung ausführen (da sie tatsächliche CPU-Instruktionen verwenden, nur mit Isolierung). Daher sind sie für komplexe Logik um Größenordnungen schneller als rein kryptografische Alternativen wie homomorphe Verschlüsselung oder Zero-Knowledge-Proofs. Durch das Auslagern von Arbeit in Enklaven können Blockchains komplexere Anwendungen verarbeiten (wie maschinelles Lernen, Bild-/Audioverarbeitung, große Analysen), die on-chain unpraktisch wären. Die Ergebnisse kommen mit einem Attest zurück, das der On-Chain-Vertrag oder die Benutzer als von einer vertrauenswürdigen Enklave stammend verifizieren können, wodurch Datenintegrität und Korrektheit gewahrt bleiben. Dieses Modell wird oft als „verifizierbare Off-Chain-Berechnung“ bezeichnet, und TEEs sind ein Eckpfeiler für viele solcher Entwürfe (z. B. nutzt das Trusted Compute Framework von Hyperledger Avalon, entwickelt von Intel, iExec und anderen, TEEs zur Off-Chain-Ausführung von EVM-Bytecode mit on-chain veröffentlichtem Korrektheitsnachweis).

Sichere Oracles und Datenintegrität​

Oracles schlagen die Brücke zwischen Blockchains und realen Daten, bringen jedoch Herausforderungen in Bezug auf das Vertrauen mit sich: Wie kann ein Smart Contract darauf vertrauen, dass ein Off-Chain-Datenfeed korrekt und unmanipuliert ist? TEEs bieten eine Lösung, indem sie als sichere Sandbox für Oracle-Nodes fungieren. Ein TEE-basierter Oracle-Node kann Daten von externen Quellen (APIs, Webdiensten) abrufen und sie innerhalb einer Enklave verarbeiten, die garantiert, dass die Daten nicht vom Node-Betreiber oder einer Malware auf dem Node manipuliert wurden. Die Enklave kann dann die Wahrheit der bereitgestellten Daten signieren oder attestieren. Dies verbessert die Datenintegrität und Vertrauenswürdigkeit von Oracles erheblich. Selbst wenn ein Oracle-Betreiber bösartig ist, kann er die Daten nicht ändern, ohne das Attest der Enklave zu brechen (was die Blockchain erkennen würde).

Ein bemerkenswertes Beispiel ist Town Crier, ein bei Cornell entwickeltes Oracle-System, das als eines der ersten Intel SGX-Enklaven nutzte, um authentifizierte Daten für Ethereum-Verträge bereitzustellen. Town Crier rief Daten (z. B. von HTTPS-Websites) innerhalb einer SGX-Enklave ab und lieferte sie zusammen mit einem Beweis (einer Enklaven-Signatur) an einen Vertrag, dass die Daten direkt von der Quelle stammten und nicht gefälscht wurden. Chainlink erkannte den Wert davon und erwarb Town Crier im Jahr 2018, um TEE-basierte Oracles in sein dezentrales Netzwerk zu integrieren. Heute haben Chainlink und andere Oracle-Anbieter TEE-Initiativen: Beispielsweise beinhalten die DECO- und Fair Sequencing Services von Chainlink TEEs, um Datenvertraulichkeit und eine faire Reihenfolge zu gewährleisten. Wie in einer Analyse angemerkt wurde: „TEEs haben die Oracle-Sicherheit revolutioniert, indem sie eine manipulationssichere Umgebung für die Datenverarbeitung bieten... selbst die Node-Betreiber selbst können die Daten während der Verarbeitung nicht manipulieren“. Dies ist besonders wichtig für hochwertige Finanzdatenfeeds (wie Preis-Oracles für DeFi): Eine TEE kann selbst subtile Manipulationen verhindern, die zu großen Exploits führen könnten.

TEEs ermöglichen es Oracles auch, mit sensiblen oder proprietären Daten umzugehen, die nicht im Klartext auf einer Blockchain veröffentlicht werden könnten. Beispielsweise könnte ein Oracle-Netzwerk Enklaven nutzen, um private Daten (wie vertrauliche Aktien-Orderbücher oder persönliche Gesundheitsdaten) zu aggregieren und nur abgeleitete Ergebnisse oder validierte Beweise an die Blockchain zu liefern, ohne die rohen sensiblen Eingaben preiszugeben. Auf diese Weise erweitern TEEs den Umfang der Daten, die sicher in Smart Contracts integriert werden können, was entscheidend für die Tokenisierung realer Vermögenswerte (RWA), Kredit-Scoring, Versicherungen und andere datenintensive On-Chain-Dienste ist.

Beim Thema Cross-Chain-Bridges verbessern TEEs die Integrität in ähnlicher Weise. Bridges verlassen sich oft auf eine Gruppe von Validatoren oder eine Multi-Sig, um Vermögenswerte zu verwahren und Übertragungen zwischen Chains zu validieren, was sie zu Hauptzielen für Angriffe macht. Durch die Ausführung der Bridge-Validator-Logik innerhalb von TEEs kann man die privaten Schlüssel und Verifizierungsprozesse der Bridge gegen Manipulationen absichern. Selbst wenn das Betriebssystem eines Validators kompromittiert ist, sollte der Angreifer nicht in der Lage sein, private Schlüssel zu extrahieren oder Nachrichten aus dem Inneren der Enklave zu fälschen. TEEs können erzwingen, dass Bridge-Transaktionen genau nach den Protokollregeln verarbeitet werden, was das Risiko verringert, dass menschliche Betreiber oder Malware betrügerische Übertragungen einschleusen. Darüber hinaus können TEEs Atomic Swaps und Cross-Chain-Transaktionen ermöglichen, die in einer sicheren Enklave abgewickelt werden, die entweder beide Seiten abschließt oder sauber abbricht, um Szenarien zu verhindern, in denen Gelder aufgrund von Störungen stecken bleiben. Mehrere Bridge-Projekte und Konsortien haben TEE-basierte Sicherheit untersucht, um die Plage von Bridge-Hacks abzumildern, die in den letzten Jahren aufgetreten sind.

Datenintegrität und Verifizierbarkeit Off-Chain​

In all den oben genannten Szenarien ist ein wiederkehrendes Thema, dass TEEs dazu beitragen, die Datenintegrität auch außerhalb der Blockchain aufrechtzuerhalten. Da eine TEE beweisen kann, welchen Code sie ausführt (über ein Attest) und sicherstellen kann, dass der Code ohne Einmischung läuft, bietet sie eine Form des verifizierbaren Computings. Benutzer und Smart Contracts können den Ergebnissen einer TEE vertrauen, als wären sie on-chain berechnet worden, sofern das Attest gültig ist. Diese Integritätsgarantie ist der Grund, warum TEEs manchmal so bezeichnet werden, dass sie einen „Vertrauensanker“ für Off-Chain-Daten und -Berechnungen bilden.

Es ist jedoch erwähnenswert, dass dieses Vertrauensmodell einige Annahmen auf die Hardware verlagert (siehe §4). Die Datenintegrität ist nur so stark wie die Sicherheit der TEE. Wenn die Enklave kompromittiert oder das Attest gefälscht wird, könnte die Integrität versagen. Dennoch machen TEEs in der Praxis (wenn sie auf dem neuesten Stand gehalten werden) bestimmte Angriffe erheblich schwieriger. Beispielsweise könnte eine DeFi-Lending-Plattform eine TEE verwenden, um Kredit-Scores aus den privaten Daten eines Benutzers off-chain zu berechnen, und der Smart Contract würde den Score nur akzeptieren, wenn er von einem gültigen Enklaven-Attest begleitet wird. Auf diese Weise weiß der Vertrag, dass der Score durch den genehmigten Algorithmus auf echten Daten berechnet wurde, anstatt dem Benutzer oder einem Oracle blind zu vertrauen.

TEEs spielen auch eine Rolle in aufstrebenden Systemen für dezentrale Identität (DID) und Authentifizierung. Sie können private Schlüssel, persönliche Daten und Authentifizierungsprozesse sicher verwalten, sodass die sensiblen Informationen des Benutzers niemals der Blockchain oder dApp-Anbietern ausgesetzt werden. Beispielsweise könnte eine TEE auf einem mobilen Gerät die biometrische Authentifizierung verarbeiten und eine Blockchain-Transaktion signieren, wenn die biometrische Prüfung erfolgreich ist – und das alles, ohne die Biometrie des Benutzers preiszugeben. Dies bietet sowohl Sicherheit als auch Privatsphäre im Identitätsmanagement – eine wesentliche Komponente, wenn Web3 Dinge wie Reisepässe, Zertifikate oder KYC-Daten auf nutzersouveräne Weise handhaben soll.

Zusammenfassend lässt sich sagen, dass TEEs als vielseitiges Werkzeug in Web3 dienen: Sie ermöglichen Vertraulichkeit für die On-Chain-Logik, erlauben Skalierung über sichere Off-Chain-Berechnungen, schützen die Integrität von Oracles und Bridges und eröffnen neue Einsatzmöglichkeiten (von privater Identität bis hin zum konformen Datenaustausch). Als Nächstes werden wir uns spezifische Projekte ansehen, die diese Funktionen nutzen.

3. Namhafte Web3-Projekte, die TEEs nutzen​

Eine Reihe führender Blockchain-Projekte hat ihr Kernangebot um Trusted Execution Environments (TEEs) herum aufgebaut. Im Folgenden gehen wir auf einige bemerkenswerte Projekte ein und untersuchen, wie sie die TEE-Technologie nutzen und welchen einzigartigen Mehrwert sie dadurch schaffen:

Secret Network​

Secret Network ist eine Layer-1-Blockchain (basierend auf dem Cosmos SDK), die Pionierarbeit bei datenschutzfreundlichen Smart Contracts unter Verwendung von TEEs geleistet hat. Alle Validator-Knoten im Secret Network führen Intel SGX-Enklaven aus, die den Smart-Contract-Code so verarbeiten, dass der Vertragsstatus sowie die Ein- und Ausgaben selbst für die Knotenbetreiber verschlüsselt bleiben. Dies macht Secret zu einer der ersten Privacy-first Smart-Contract-Plattformen – Datenschutz ist kein optionales Add-on, sondern ein Standardmerkmal des Netzwerks auf Protokollebene.

Im Modell des Secret Networks übermitteln Benutzer verschlüsselte Transaktionen, die von den Validatoren zur Ausführung in ihre SGX-Enklave geladen werden. Die Enklave entschlüsselt die Eingaben, führt den Vertrag aus (geschrieben in einer modifizierten CosmWasm-Laufzeitumgebung) und erzeugt verschlüsselte Ausgaben, die in die Blockchain geschrieben werden. Nur Benutzer mit dem richtigen „Viewing Key“ (oder der Vertrag selbst mit seinem internen Schlüssel) können die tatsächlichen Daten entschlüsseln und einsehen. Dies ermöglicht es Anwendungen, private Daten On-Chain zu verwenden, ohne sie öffentlich preiszugeben.

Das Netzwerk hat mehrere neuartige Anwendungsfälle demonstriert:

• Secret DeFi: z. B. SecretSwap (ein AMM), bei dem die Kontostände und Transaktionsbeträge der Benutzer privat sind, was Front-Running abmildert und Handelsstrategien schützt. Liquiditätsanbieter und Händler können agieren, ohne jeden ihrer Schritte an die Konkurrenz zu senden.
• Secret Auctions: Auktionsverträge, bei denen Gebote bis zum Ende der Auktion geheim gehalten werden, um strategisches Verhalten basierend auf den Geboten anderer zu verhindern.
• Private Abstimmungen und Governance: Token-Inhaber können über Vorschläge abstimmen, ohne ihre Wahlentscheidung preiszugeben, während das Gesamtergebnis dennoch verifiziert werden kann – was eine faire, einschüchterungsfreie Governance gewährleistet.
• Datenmarktplätze: Sensible Datensätze können gehandelt und für Berechnungen verwendet werden, ohne die Rohdaten gegenüber Käufern oder Knoten offenzulegen.

Secret Network integriert TEEs im Wesentlichen auf Protokollebene, um ein einzigartiges Wertversprechen zu schaffen: Es bietet programmierbare Privatsphäre. Zu den Herausforderungen, die sie bewältigen, gehören die Koordinierung der Enklaven-Attestierung über ein dezentrales Validator-Set hinweg und die Verwaltung der Schlüsselverteilung, damit Verträge Eingaben entschlüsseln können, während sie vor Validatoren geheim gehalten werden. Nach allgemeiner Einschätzung hat Secret die Durchführbarkeit von TEE-gestützter Vertraulichkeit auf einer öffentlichen Blockchain bewiesen und sich als Marktführer in diesem Bereich etabliert.

Oasis Network​

Oasis Network ist eine weitere Layer-1-Blockchain, die auf Skalierbarkeit und Datenschutz abzielt und in ihrer Architektur intensiv TEEs (Intel SGX) nutzt. Oasis führte ein innovatives Design ein, das Konsens von Berechnung trennt und in verschiedene Schichten unterteilt, die als Consensus Layer und ParaTime Layer bezeichnet werden. Der Consensus Layer übernimmt die Blockchain-Sortierung und Finalität, während jede ParaTime eine Laufzeitumgebung für Smart Contracts sein kann. Bemerkenswerterweise ist die Emerald ParaTime von Oasis eine EVM-kompatible Umgebung, und Sapphire ist eine vertrauliche EVM, die TEEs verwendet, um den Status von Smart Contracts privat zu halten.

Der Einsatz von TEEs bei Oasis konzentriert sich auf vertrauliche Berechnungen in großem Maßstab. Durch die Isolierung der rechenintensiven Aufgaben in parallelisierbaren ParaTimes (die auf vielen Knoten laufen können) erreichen sie einen hohen Durchsatz. Durch den Einsatz von TEEs innerhalb dieser ParaTime-Knoten stellen sie sicher, dass die Berechnungen sensible Daten enthalten können, ohne diese preiszugeben. Beispielsweise könnte eine Institution einen Kredit-Scoring-Algorithmus auf Oasis ausführen, indem sie private Daten in eine vertrauliche ParaTime einspeist – die Daten bleiben für den Knoten verschlüsselt (da sie in der Enklave verarbeitet werden), und nur das Ergebnis wird ausgegeben. Währenddessen zeichnet der Oasis-Konsens lediglich den Beweis auf, dass die Berechnung korrekt stattgefunden hat.

Technisch gesehen hat Oasis zusätzliche Sicherheitsebenen über das Standard-SGX hinaus hinzugefügt. Sie implementierten eine „geschichtete Vertrauensbasis“ (layered root of trust): Sie nutzen die Quoting-Enklave von Intel SGX und einen speziellen leichtgewichtigen Kernel, um die Vertrauenswürdigkeit der Hardware zu verifizieren und die Systemaufrufe der Enklave in einer Sandbox zu isolieren. Dies reduziert die Angriffsfläche (indem gefiltert wird, welche Betriebssystemaufrufe Enklaven tätigen können) und schützt vor bestimmten bekannten SGX-Angriffen. Oasis führte auch Funktionen wie persistente Enklaven (damit Enklaven den Status über Neustarts hinweg beibehalten können) und sicheres Logging ein, um Rollback-Angriffe abzumildern (bei denen ein Knoten versuchen könnte, einen alten Enklavenstatus erneut abzuspielen). Diese Innovationen wurden in ihren technischen Whitepapern beschrieben und sind mit ein Grund, warum Oasis als forschungsorientiertes Projekt im Bereich des TEE-basierten Blockchain-Computings gilt.

Aus Sicht des Ökosystems hat sich Oasis für Bereiche wie privates DeFi (das es Banken ermöglicht teilzunehmen, ohne Kundendaten preiszugeben) und Datentokenisierung (bei der Einzelpersonen oder Unternehmen Daten auf vertrauliche Weise mit KI-Modellen teilen und dafür vergütet werden können, alles über die Blockchain) positioniert. Sie haben auch mit Unternehmen an Pilotprojekten zusammengearbeitet (beispielsweise mit BMW zum Thema Datenschutz und mit anderen im Bereich des Austauschs medizinischer Forschungsdaten). Insgesamt zeigt das Oasis Network, wie die Kombination von TEEs mit einer skalierbaren Architektur sowohl Datenschutz als auch Leistung adressieren kann, was es zu einem bedeutenden Akteur bei TEE-basierten Web3-Lösungen macht.

Sanders Network​

Sanders Network ist ein dezentrales Cloud-Computing-Netzwerk im Polkadot-Ökosystem, das TEEs nutzt, um vertrauliche und hochperformante Rechendienste bereitzustellen. Es ist eine Parachain auf Polkadot, was bedeutet, dass es von der Sicherheit und Interoperabilität von Polkadot profitiert, aber eine eigene neuartige Laufzeitumgebung für Off-Chain-Berechnungen in sicheren Enklaven einführt.

Die Kernidee von Sanders besteht darin, ein großes Netzwerk von Worker-Knoten (sogenannte Sanders-Miner) zu unterhalten, die Aufgaben innerhalb von TEEs (speziell Intel SGX) ausführen und verifizierbare Ergebnisse produzieren. Diese Aufgaben können von der Ausführung von Smart-Contract-Segmenten bis hin zu universellen Berechnungen reichen, die von Benutzern angefordert werden. Da die Worker in SGX laufen, gewährleistet Sanders, dass die Berechnungen mit Vertraulichkeit (Eingabedaten sind vor dem Worker-Betreiber verborgen) und Integrität (die Ergebnisse werden mit einer Attestierung geliefert) durchgeführt werden. Dies schafft effektiv eine vertrauenslose Cloud, in der Benutzer Workloads bereitstellen können, in dem Wissen, dass der Host diese nicht einsehen oder manipulieren kann.

Man kann sich Sanders analog zu Amazon EC2 oder AWS Lambda vorstellen, jedoch dezentralisiert: Entwickler können Code im Sanders-Netzwerk bereitstellen und ihn auf vielen SGX-fähigen Rechnern weltweit ausführen lassen, wobei sie den Dienst mit dem Sanders-Token bezahlen. Einige hervorgehobene Anwendungsfälle:

• Web3-Analytik und KI: Ein Projekt könnte Benutzerdaten analysieren oder KI-Algorithmen in Sanders-Enklaven ausführen, sodass rohe Benutzerdaten verschlüsselt bleiben (Schutz der Privatsphäre), während nur aggregierte Erkenntnisse die Enklave verlassen.
• Game-Backends und Metaverse: Sanders kann intensive Spiellogik oder Simulationen virtueller Welten Off-Chain verarbeiten und nur Verpflichtungen (Commitments) oder Hashes an die Blockchain senden, was ein reichhaltigeres Gameplay ermöglicht, ohne auf einen einzelnen Server vertrauen zu müssen.
• On-Chain-Dienste: Sanders hat eine Off-Chain-Rechenplattform namens Sanders Cloud aufgebaut. Diese kann beispielsweise als Backend für Bots, dezentrale Webdienste oder sogar ein Off-Chain-Orderbuch dienen, das Trades mit TEE-Attestierung an einen DEX-Smart-Contract übermittelt.

Sanders betont, dass es vertrauliche Berechnungen horizontal skalieren kann: Wird mehr Kapazität benötigt? Dann werden einfach mehr TEE-Worker-Knoten hinzugefügt. Dies unterscheidet sich von einer einzelnen Blockchain, bei der die Rechenkapazität durch den Konsens begrenzt ist. Somit eröffnet Sanders Möglichkeiten für rechenintensive dApps, die dennoch vertrauenslose Sicherheit wünschen. Wichtig ist, dass Sanders sich nicht rein auf Hardware-Vertrauen verlässt; es wird in den Konsens von Polkadot integriert (z. B. Staking und Slashing bei fehlerhaften Ergebnissen) und erforscht sogar eine Kombination aus TEE mit Zero-Knowledge Proofs (wie erwähnt nutzt ihr kommendes L2 TEEs zur Beschleunigung der Ausführung und ZKPs zur prägnanten Verifizierung auf Ethereum). Dieser hybride Ansatz hilft, das Risiko einer Kompromittierung eines einzelnen TEEs zu mindern, indem eine zusätzliche kryptografische Verifizierung hinzugefügt wird.

Zusammenfassend lässt sich sagen, dass das Sanders Network TEEs nutzt, um eine dezentrale, vertrauliche Cloud für Web3 bereitzustellen, die Off-Chain-Berechnungen mit Sicherheitsgarantien ermöglicht. Dies setzt eine Klasse von Blockchain-Anwendungen frei, die sowohl hohe Rechenleistung als auch Datenschutz benötigen, und schließt die Lücke zwischen On-Chain- und Off-Chain-Welten.

iExec​

iExec ist ein dezentraler Marktplatz für Cloud-Computing-Ressourcen, der auf Ethereum aufbaut. Im Gegensatz zu den drei vorgenannten Projekten (die eigene Chains oder Parachains sind), operiert iExec als Layer-2- oder Off-Chain-Netzwerk, das mit Ethereum-Smart-Contracts koordiniert. TEEs (speziell Intel SGX) sind ein Eckpfeiler des Ansatzes von iExec, um Vertrauen in Off-Chain-Berechnungen zu schaffen.

Das iExec-Netzwerk besteht aus Worker-Knoten, die von verschiedenen Anbietern beigesteuert werden. Diese Worker können Aufgaben ausführen, die von Benutzern (dApp-Entwicklern, Datenanbietern usw.) angefordert werden. Um sicherzustellen, dass diese Off-Chain-Berechnungen vertrauenswürdig sind, hat iExec ein Framework für „Trusted Off-chain Computing“ eingeführt: Aufgaben können innerhalb von SGX-Enklaven ausgeführt werden, und die Ergebnisse werden mit einer Enklaven-Signatur geliefert, die beweist, dass die Aufgabe korrekt auf einem sicheren Knoten ausgeführt wurde. iExec ist eine Partnerschaft mit Intel eingegangen, um diese Trusted-Computing-Funktion einzuführen, und ist sogar dem Confidential Computing Consortium beigetreten, um Standards voranzutreiben. Ihr Konsensprotokoll namens Proof-of-Contribution (PoCo) aggregiert bei Bedarf Stimmen/Attestierungen von mehreren Workern, um einen Konsens über das korrekte Ergebnis zu erzielen. In vielen Fällen reicht die Attestierung einer einzelnen Enklave aus, wenn der Code deterministisch ist und das Vertrauen in SGX hoch ist; für eine höhere Absicherung kann iExec Aufgaben über mehrere TEEs hinweg replizieren und einen Konsens oder Mehrheitsentscheid verwenden.

Die Plattform von iExec ermöglicht mehrere interessante Anwendungsfälle:

• Dezentrales Oracle-Computing: Wie bereits erwähnt, kann iExec mit Chainlink zusammenarbeiten. Ein Chainlink-Knoten könnte Rohdaten abrufen, diese dann an einen iExec SGX-Worker übergeben, um eine Berechnung (z. B. einen proprietären Algorithmus oder eine KI-Inferenz) auf diesen Daten durchzuführen, und schließlich ein Ergebnis On-Chain zurückgeben. Dies erweitert die Möglichkeiten von Oracles über das bloße Weiterleiten von Daten hinaus – sie können nun berechnete Dienste anbieten (wie den Aufruf eines KI-Modells oder die Aggregation vieler Quellen), wobei TEE die Ehrlichkeit gewährleistet.
• KI und DePIN (Decentralized Physical Infrastructure Network): iExec positioniert sich als Vertrauensebene für dezentrale KI-Apps. Beispielsweise kann eine dApp, die ein maschinelles Lernmodell verwendet, das Modell in einer Enklave ausführen, um sowohl das Modell (falls es proprietär ist) als auch die eingespeisten Benutzerdaten zu schützen. Im Kontext von DePIN (wie verteilten IoT-Netzwerken) können TEEs auf Edge-Geräten eingesetzt werden, um Sensormesswerten und Berechnungen auf diesen Werten zu vertrauen.
• Sichere Datenmonetarisierung: Datenanbieter können ihre Datensätze in verschlüsselter Form auf dem Marktplatz von iExec zur Verfügung stellen. Käufer können ihre Algorithmen senden, um sie auf den Daten innerhalb eines TEEs auszuführen (sodass die Rohdaten des Datenanbieters niemals offengelegt werden, was dessen geistiges Eigentum schützt, und auch die Details des Algorithmus verborgen bleiben können). Das Ergebnis der Berechnung wird an den Käufer zurückgegeben, und die entsprechende Zahlung an den Datenanbieter wird über Smart Contracts abgewickelt. Dieses Schema, das oft als sicherer Datenaustausch bezeichnet wird, wird durch die Vertraulichkeit von TEEs ermöglicht.

Insgesamt bietet iExec das Bindeglied zwischen Ethereum-Smart-Contracts und einer sicheren Off-Chain-Ausführung. Es zeigt, wie TEE-„Worker“ vernetzt werden können, um eine dezentrale Cloud zu bilden, komplett mit einem Marktplatz (unter Verwendung des RLC-Tokens von iExec für Zahlungen) und Konsensmechanismen. Durch die Leitung der Trusted Compute Working Group der Enterprise Ethereum Alliance und die Mitwirkung an Standards (wie Hyperledger Avalon) treibt iExec zudem die breitere Akzeptanz von TEEs in Enterprise-Blockchain-Szenarien voran.

Andere Projekte und Ökosysteme​

Über die vier oben genannten hinaus gibt es einige weitere erwähnenswerte Projekte:

• Integritee – eine weitere Polkadot-Parachain ähnlich wie Sanders (tatsächlich ging sie aus der TEE-Arbeit der Energy Web Foundation hervor). Integritee nutzt TEEs, um „Parachain-as-a-Service“ für Unternehmen anzubieten, wobei On-Chain- und Off-Chain-Enklavenverarbeitung kombiniert werden.
• Automata Network – ein Middleware-Protokoll für Web3-Privatsphäre, das TEEs für private Transaktionen, anonyme Abstimmungen und MEV-resistente Transaktionsverarbeitung nutzt. Automata fungiert als Off-Chain-Netzwerk, das Dienste wie ein privates RPC-Relay anbietet, und wurde im Zusammenhang mit der Nutzung von TEEs für Dinge wie geschützte Identitäten und gaslose private Transaktionen erwähnt.
• Hyperledger Sawtooth (PoET) – im Unternehmensbereich führte Sawtooth einen Konsensalgorithmus namens Proof of Elapsed Time ein, der auf SGX beruhte. Jeder Validator führt eine Enklave aus, die eine zufällige Zeit lang wartet und einen Beweis erstellt; derjenige mit der kürzesten Wartezeit „gewinnt“ den Block, eine faire Lotterie, die durch SGX erzwungen wird. Obwohl Sawtooth per se kein Web3-Projekt ist (eher Enterprise-Blockchain), ist es eine kreative Nutzung von TEEs für den Konsens.
• Unternehmens-/Konsortial-Chains – Viele Enterprise-Blockchain-Lösungen (z. B. ConsenSys Quorum, IBM Blockchain) integrieren TEEs, um vertrauliche Konsortialtransaktionen zu ermöglichen, bei denen nur autorisierte Knoten bestimmte Daten sehen. Beispielsweise nutzt das Blueprint des Trusted Compute Framework (TCF) der Enterprise Ethereum Alliance TEEs, um private Verträge Off-Chain auszuführen und Merkle-Proofs On-Chain zu liefern.

Diese Projekte zeigen zusammen die Vielseitigkeit von TEEs: Sie treiben ganze datenschutzorientierte L1s an, dienen als Off-Chain-Netzwerke, sichern Infrastrukturkomponenten wie Oracles und Bridges und bilden sogar die Grundlage für Konsensalgorithmen. Als Nächstes betrachten wir die breiteren Vorteile und Herausforderungen des Einsatzes von TEEs in dezentralen Umgebungen.

4. Vorteile und Herausforderungen von TEEs in dezentralen Umgebungen​

Die Einführung von Trusted Execution Environments ( TEEs ) in Blockchain-Systemen bringt sowohl signifikante technische Vorteile als auch bemerkenswerte Herausforderungen und Kompromisse mit sich. Wir werden beide Seiten untersuchen: was TEEs für dezentrale Anwendungen bieten und welche Probleme oder Risiken aus ihrer Verwendung resultieren.

Vorteile und technische Stärken​

• Starke Sicherheit & Privatsphäre: Der wichtigste Vorteil sind die Garantien für Vertraulichkeit und Integrität. TEEs ermöglichen es, sensiblen Code mit der Gewissheit auszuführen, dass er nicht von externer Malware ausspioniert oder verändert werden kann. Dies bietet ein Maß an Vertrauen in Off-Chain-Berechnungen, das zuvor nicht verfügbar war. Für die Blockchain bedeutet dies, dass private Daten genutzt werden können ( was die Funktionalität von dApps erweitert ), ohne die Sicherheit zu opfern. Selbst in nicht vertrauenswürdigen Umgebungen ( Cloud-Server, von Dritten betriebene Validator-Nodes ) halten TEEs Geheimnisse sicher. Dies ist besonders vorteilhaft für die Verwaltung von privaten Schlüsseln, Benutzerdaten und proprietären Algorithmen innerhalb von Krypto-Systemen. Zum Beispiel könnte eine Hardware-Wallet oder ein Cloud-Signierungsdienst ein TEE verwenden, um Blockchain-Transaktionen intern zu signieren, sodass der private Schlüssel niemals im Klartext offengelegt wird, was Komfort mit Sicherheit kombiniert.

• Nahezu native Performance: Im Gegensatz zu rein kryptografischen Ansätzen für sicheres Rechnen ( wie ZK-Proofs oder homomorphe Verschlüsselung ) ist der Overhead von TEEs relativ gering. Der Code wird direkt auf der CPU ausgeführt, sodass eine Berechnung innerhalb einer Enklave in etwa so schnell ist wie außerhalb ( mit gewissen Einbußen für Enklaven-Übergänge und Speicherverschlüsselung, typischerweise im einstelligen Prozentbereich bei SGX ). Das bedeutet, dass TEEs rechenintensive Aufgaben effizient bewältigen können, was Anwendungsfälle ermöglicht ( wie Echtzeit-Datenfeeds, komplexe Smart Contracts, maschinelles Lernen ), die um Größenordnungen langsamer wären, wenn sie mit kryptografischen Protokollen durchgeführt würden. Die geringe Latenz von Enklaven macht sie für Bereiche geeignet, in denen schnelle Reaktionen erforderlich sind ( z. B. durch TEEs gesicherte Hochfrequenz-Trading-Bots oder interaktive Anwendungen und Spiele, bei denen die Benutzererfahrung unter hohen Verzögerungen leiden würde ).

• Verbesserte Skalierbarkeit ( durch Auslagerung ): Durch die Ermöglichung sicherer Off-Chain-Berechnungen tragen TEEs dazu bei, Überlastungen und Gaskosten auf den Hauptketten zu reduzieren. Sie ermöglichen Layer-2-Designs und Side-Protokolle, bei denen die Blockchain nur zur Verifizierung oder endgültigen Abrechnung verwendet wird, während der Großteil der Berechnungen in parallelen Enklaven stattfindet. Diese Modularisierung ( rechenintensive Logik in TEEs, Konsens auf der Chain ) kann den Durchsatz und die Skalierbarkeit dezentraler Anwendungen drastisch verbessern. Beispielsweise könnte eine DEX das Matchmaking in einem TEE off-chain durchführen und nur die gematchten Trades on-chain posten, was den Durchsatz erhöht und das On-Chain-Gas reduziert.

• Bessere Benutzererfahrung & Funktionalität: Mit TEEs können dApps Funktionen wie Vertraulichkeit oder komplexe Analysen anbieten, die mehr Nutzer ( einschließlich Institutionen ) anziehen. TEEs ermöglichen auch gaslose oder Meta-Transaktionen, indem sie diese sicher off-chain ausführen und dann die Ergebnisse übermitteln, wie in Automatas Nutzung von TEEs zur Reduzierung von Gas für private Transaktionen angemerkt. Darüber hinaus kann das Speichern von sensitivem Status off-chain in einer Enklave die Menge der on-chain veröffentlichten Daten reduzieren, was gut für die Privatsphäre der Nutzer und die Netzwerkeffizienz ist ( weniger On-Chain-Daten zum Speichern / Verifizieren ).

• Komponierbarkeit mit anderen Technologien: Interessanterweise können TEEs andere Technologien ergänzen ( was nicht unbedingt ein inhärenter Vorteil von TEEs allein ist, sondern in Kombination ). Sie können als Bindeglied für hybride Lösungen dienen: z. B. das Ausführen eines Programms in einer Enklave und das gleichzeitige Erzeugen eines ZK-Proofs seiner Ausführung, wobei die Enklave Teile des Beweisprozesses unterstützt, um diesen zu beschleunigen. Oder die Verwendung von TEEs in MPC-Netzwerken, um bestimmte Aufgaben mit weniger Kommunikationsrunden zu bewältigen. Wir werden Vergleiche in §5 diskutieren, aber viele Projekte betonen, dass TEEs die Kryptografie nicht ersetzen müssen – sie können zusammenarbeiten, um die Sicherheit zu stärken ( Sanders’ Mantra: „Die Stärke von TEEs liegt darin, andere zu unterstützen, nicht sie zu ersetzen“ ).

Vertrauensannahmen und Sicherheitsanfälligkeiten​

Trotz ihrer Stärken führen TEEs spezifische Vertrauensannahmen ein und sind nicht unantastbar. Es ist entscheidend, diese Herausforderungen zu verstehen:

• Hardware-Vertrauen und Zentralisierung: Durch die Verwendung von TEEs setzt man inhärent Vertrauen in den Chiphersteller ( Silicon Vendor ) sowie in die Sicherheit seines Hardware-Designs und seiner Lieferkette. Die Verwendung von Intel SGX bedeutet beispielsweise das Vertrauen darauf, dass Intel keine Backdoors eingebaut hat, dass die Fertigung sicher ist und dass der Mikrocode der CPU die Enklaven-Isolierung korrekt implementiert. Dies ist ein zentralisierteres Vertrauensmodell im Vergleich zu reiner Kryptografie ( die auf mathematischen Annahmen beruht, die unter allen Nutzern verteilt sind ). Darüber hinaus beruht die Attestierung für SGX historisch auf der Kontaktaufnahme mit Intels Attestation Service. Das bedeutet: Wenn Intel offline ginge oder beschließen würde, Schlüssel zu widerrufen, könnten Enklaven weltweit betroffen sein. Diese Abhängigkeit von der Infrastruktur eines einzelnen Unternehmens wirft Bedenken auf: Es könnte ein Single Point of Failure oder sogar ein Ziel für staatliche Regulierungen sein ( z. B. könnten US-Exportkontrollen theoretisch einschränken, wer starke TEEs nutzen darf ). AMD SEV mildert dies ab, indem es eine dezentralere Attestierung ermöglicht ( VM-Besitzer können ihre VMs attestieren ), vertraut aber weiterhin dem Chip und der Firmware von AMD. Das Zentralisierungsrisiko wird oft als etwas angeführt, das dem Dezentralisierungsgedanken der Blockchain widerspricht. Projekte wie Keystone ( Open-Source-TEE ) und andere erforschen Wege, um die Abhängigkeit von proprietären Black Boxes zu verringern, aber diese sind noch nicht im Mainstream angekommen.

• Seitenkanal- und andere Schwachstellen: Ein TEE ist kein Allheilmittel; es kann durch indirekte Mittel angegriffen werden. Seitenkanalangriffe ( Side-Channel Attacks ) nutzen die Tatsache aus, dass, selbst wenn der direkte Speicherzugriff blockiert ist, der Betrieb einer Enklave das System subtil beeinflussen kann ( durch Timing, Cache-Nutzung, Stromverbrauch, elektromagnetische Emissionen usw. ). In den letzten Jahren wurden zahlreiche akademische Angriffe auf Intel SGX demonstriert: von Foreshadow ( Extrahieren von Enklaven-Geheimnissen über L1-Cache-Timing-Leckagen ) über Plundervolt ( Voltage Fault Injection über privilegierte Befehle ) bis hin zu SGAxe ( Extrahieren von Attestierungsschlüsseln ) und anderen. Diese hochentwickelten Angriffe zeigen, dass TEEs kompromittiert werden können, ohne kryptografische Schutzmechanismen brechen zu müssen – stattdessen durch das Ausnutzen von mikroarchitektonischen Verhaltensweisen oder Fehlern in der Implementierung. Infolgedessen wird anerkannt, dass „Forscher verschiedene potenzielle Angriffsvektoren identifiziert haben, die Hardware-Schwachstellen oder Zeitunterschiede bei TEE-Operationen ausnutzen könnten“. Obwohl diese Angriffe nicht trivial sind und oft entweder lokalen Zugriff oder bösartige Hardware erfordern, stellen sie eine reale Bedrohung dar. TEEs schützen im Allgemeinen auch nicht vor physischen Angriffen, wenn ein Angreifer den Chip in der Hand hat ( z. B. das Öffnen des Chips / Decapping, das Sondieren von Bussen usw. kann die meisten kommerziellen TEEs überwinden ).

  Die Reaktionen der Hersteller auf Entdeckungen von Seitenkanälen bestanden in Mikrocode-Patches und Updates des Enklaven-SDKs, um bekannte Lecks zu mildern ( manchmal auf Kosten der Performance ). Aber es bleibt ein Katz-und-Maus-Spiel. Für Web3 bedeutet dies: Wenn jemand einen neuen Seitenkanal auf SGX findet, könnte ein „sicherer“ DeFi-Vertrag, der in SGX läuft, potenziell ausgenutzt werden ( z. B. um geheime Daten zu lecken oder die Ausführung zu manipulieren ). Sich auf TEEs zu verlassen, bedeutet also, eine potenzielle Angriffsfläche auf Hardware-Ebene zu akzeptieren, die außerhalb des typischen Blockchain-Bedrohungsmodells liegt. Es ist ein aktives Forschungsgebiet, TEEs gegen diese Angriffe zu stärken ( zum Beispiel durch das Entwerfen von Enklaven-Code mit Constant-Time-Operationen, das Vermeiden von geheimnisabhängigen Speicherzugriffsmustern und die Verwendung von Techniken wie Oblivious RAM ). Einige Projekte ergänzen TEEs auch durch sekundäre Prüfungen – z. B. die Kombination mit ZK-Proofs oder das Ausführen mehrerer Enklaven auf Hardware verschiedener Hersteller, um das Risiko eines einzelnen Chips zu verringern.

• Performance- und Ressourcenbeschränkungen: Obwohl TEEs bei CPU-gebundenen Aufgaben mit nahezu nativer Geschwindigkeit laufen, bringen sie einige Overheads und Einschränkungen mit sich. Der Wechsel in eine Enklave ( ein ECALL ) und heraus ( OCALL ) verursacht Kosten, ebenso wie die Verschlüsselung / Entschlüsselung von Speicherseiten. Dies kann die Performance bei sehr häufigen Enklaven-Grenzübergängen beeinträchtigen. Enklaven haben zudem oft Einschränkungen bei der Speichergröße. Beispielsweise hatte das frühe SGX einen begrenzten Enclave Page Cache ( EPC ), und wenn Enklaven mehr Speicher verwendeten, mussten Seiten ausgelagert werden ( mit Verschlüsselung ), was die Performance massiv verlangsamte. Selbst neuere TEEs erlauben es oft nicht, den gesamten System-RAM problemlos zu nutzen – es gibt einen sicheren Speicherbereich, der begrenzt sein kann. Dies bedeutet, dass sehr umfangreiche Berechnungen oder Datensätze eine Herausforderung darstellen können, wenn sie vollständig innerhalb eines TEEs abgewickelt werden sollen. Im Web3-Kontext könnte dies die Komplexität von Smart Contracts oder ML-Modellen einschränken, die in einer Enklave laufen können. Entwickler müssen für den Speicher optimieren und möglicherweise Arbeitslasten aufteilen.

• Komplexität der Attestierung und Schlüsselverwaltung: Die Verwendung von TEEs in einer dezentralen Umgebung erfordert robuste Attestierungs-Workflows: Jeder Knoten muss anderen beweisen, dass er eine authentische Enklave mit dem erwarteten Code ausführt. Die Einrichtung dieser On-Chain-Attestierungsverifizierung kann komplex sein. In der Regel müssen der öffentliche Attestierungsschlüssel oder das Zertifikat des Herstellers fest im Protokoll kodiert und die Verifizierungslogik in Smart Contracts oder Off-Chain-Clients geschrieben werden. Dies führt zu Overhead im Protokolldesign, und alle Änderungen ( wie der Wechsel des Attestierungs-Signaturschlüsselformats von EPID zu DCAP durch Intel ) können Wartungsaufwand verursachen. Darüber hinaus fügt die Verwaltung von Schlüsseln innerhalb von TEEs ( zum Entschlüsseln von Daten oder Signieren von Ergebnissen ) eine weitere Komplexitätsebene hinzu. Fehler bei der Enklaven-Schlüsselverwaltung könnten die Sicherheit untergraben ( z. B. wenn eine Enklave versehentlich einen Entschlüsselungsschlüssel durch einen Bug preisgibt, brechen alle ihre Vertraulichkeitsversprechen zusammen ). Best Practices beinhalten die Nutzung der Sealing-APIs des TEEs, um Schlüssel sicher zu speichern und Schlüssel bei Bedarf zu rotieren, aber auch dies erfordert ein sorgfältiges Design durch die Entwickler.

• Denial-of-Service und Verfügbarkeit: Ein vielleicht weniger diskutiertes Problem: TEEs helfen nicht bei der Verfügbarkeit und können sogar neue DoS-Wege eröffnen. Zum Beispiel könnte ein Angreifer einen TEE-basierten Dienst mit Eingaben überfluten, deren Verarbeitung kostspielig ist, wohlwissend, dass die Enklave vom Betreiber nicht einfach inspiziert oder unterbrochen werden kann ( da sie isoliert ist ). Wenn zudem eine Schwachstelle gefunden wird und ein Patch Firmware-Updates erfordert, müssen während dieses Zyklus viele Enklaven-Dienste möglicherweise aus Sicherheitsgründen pausieren, bis die Knoten gepatcht sind, was zu Ausfallzeiten führt. Stellen Sie sich im Blockchain-Konsens vor, ein kritischer SGX-Bug würde gefunden – Netzwerke wie Secret müssten möglicherweise anhalten, bis ein Fix vorliegt, da das Vertrauen in die Enklaven gebrochen wäre. Die Koordinierung solcher Reaktionen in einem dezentralen Netzwerk ist eine Herausforderung.

Komponierbarkeit und Ökosystem-Einschränkungen​

• Eingeschränkte Komponierbarkeit mit anderen Verträgen: In einer öffentlichen Smart-Contract-Plattform wie Ethereum können Verträge problemlos andere Verträge aufrufen, und der gesamte Status ist offen, was DeFi-Money-Legos und eine reichhaltige Komposition ermöglicht. In einem TEE-basierten Vertragsmodell kann der private Status nicht frei geteilt oder kombiniert werden, ohne die Vertraulichkeit zu verletzen. Wenn beispielsweise Vertrag A in einer Enklave mit Vertrag B interagieren muss und beide geheime Daten enthalten, wie arbeiten sie zusammen? Entweder müssen sie ein komplexes sicheres Multi-Party-Protokoll durchführen ( was einen Teil der Einfachheit von TEEs zunichtemacht ) oder sie werden in einer Enklave kombiniert ( was die Modularität verringert ). Dies ist eine Herausforderung, vor der das Secret Network und andere stehen: Vertragsübergreifende Aufrufe mit Privatsphäre sind nicht trivial. Einige Lösungen sehen vor, dass eine einzige Enklave die Ausführung mehrerer Verträge übernimmt, sodass sie intern geteilte Geheimnisse verwalten kann, aber das kann das System monolithischer machen. Daher ist die Komponierbarkeit privater Verträge eingeschränkter als die öffentlicher oder erfordert neue Designmuster. Ebenso erfordert die Integration von TEE-basierten Modulen in bestehende Blockchain-dApps ein sorgfältiges Schnittstellendesign – oft wird nur das Ergebnis einer Enklave on-chain gepostet, was ein SNARK oder ein Hash sein kann, und andere Verträge können nur diese begrenzten Informationen nutzen. Dies ist definitiv ein Kompromiss; Projekte wie Secret bieten Viewing-Keys an und erlauben das Teilen von Geheimnissen nach dem „Need-to-know“-Prinzip, aber es ist nicht so nahtlos wie die normale On-Chain-Komponierbarkeit.

• Standardisierung und Interoperabilität: Dem TEE-Ökosystem fehlen derzeit einheitliche Standards über verschiedene Hersteller hinweg. Intel SGX, AMD SEV und ARM TrustZone haben alle unterschiedliche Programmiermodelle und Attestierungsmethoden. Diese Fragmentierung bedeutet, dass eine für SGX-Enklaven geschriebene dApp nicht ohne Weiteres auf TrustZone usw. portierbar ist. In der Blockchain kann dies ein Projekt an eine bestimmte Hardware binden ( z. B. sind Secret und Oasis derzeit an x86-Server mit SGX gebunden ). Wenn diese später ARM-Knoten unterstützen wollten ( z. B. Validatoren auf Mobilgeräten ), würde dies zusätzliche Entwicklung und vielleicht eine andere Attestierungs-Verifizierungslogik erfordern. Es gibt Bemühungen ( wie das CCC – Confidential Computing Consortium ), Attestierungs- und Enklaven-APIs zu standardisieren, aber wir sind noch nicht ganz am Ziel. Der Mangel an Standards wirkt sich auch auf die Entwickler-Tools aus – man findet vielleicht das SGX-SDK ausgereift, muss sich dann aber an ein anderes TEE mit einem anderen SDK anpassen. Diese Interoperabilitäts-Herausforderung kann die Akzeptanz verlangsamen und die Kosten erhöhen.

• Lernkurve für Entwickler: Das Erstellen von Anwendungen, die innerhalb von TEEs laufen, erfordert spezialisiertes Wissen, das viele Blockchain-Entwickler möglicherweise nicht haben. Oft ist Low-Level-Programmierung in C / C++ ( für SGX / TrustZone ) oder ein Verständnis von Speichersicherheit und seitenkanalresistentem Coding erforderlich. Das Debuggen von Enklaven-Code ist bekanntermaßen schwierig ( man kann aus Sicherheitsgründen während des Betriebs nicht einfach in eine Enklave hineinschauen! ). Obwohl Frameworks und höhere Sprachen existieren ( wie die Verwendung von Rust durch Oasis für ihre vertrauliche Runtime oder sogar Tools zum Ausführen von WebAssembly in Enklaven ), ist die Entwicklererfahrung immer noch mühsamer als die typische Smart-Contract-Entwicklung oder die Off-Chain-Web2-Entwicklung. Diese steile Lernkurve und unausgereifte Tools können Entwickler abschrecken oder zu Fehlern führen, wenn nicht sorgfältig vorgegangen wird. Hinzu kommt der Aspekt, dass Hardware zum Testen benötigt wird – zum Ausführen von SGX-Code ist eine SGX-fähige CPU oder ein Emulator erforderlich ( der langsamer ist ), sodass die Einstiegshürde höher ist. Infolgedessen sind heute relativ wenige Entwickler tief mit der Enklaven-Entwicklung vertraut, was Audits und Community-Support seltener macht als beispielsweise in der weit verbreiteten Solidity-Community.

• Betriebskosten: Der Betrieb einer TEE-basierten Infrastruktur kann kostspieliger sein. Die Hardware selbst kann teurer oder knapper sein ( z. B. verlangen bestimmte Cloud-Anbieter einen Aufpreis für SGX-fähige VMs ). Hinzu kommt der operative Aufwand: Firmware auf dem neuesten Stand halten ( für Sicherheitspatches ), Verwaltung des Attestierungs-Networkings usw., was kleine Projekte als belastend empfinden könnten. Wenn jeder Knoten eine bestimmte CPU haben muss, könnte dies den potenziellen Validator-Pool verkleinern ( nicht jeder hat die erforderliche Hardware ), was die Dezentralisierung beeinträchtigt und möglicherweise zu einer höheren Nutzung von Cloud-Hosting führt.

Zusammenfassend lässt sich sagen: Während TEEs leistungsstarke Funktionen freischalten, bringen sie auch Vertrauenskompromisse ( Hardware-Vertrauen vs. mathematisches Vertrauen ), potenzielle Sicherheitsforschwächen ( insbesondere Seitenkanäle ) und Integrationshürden in einem dezentralen Kontext mit sich. Projekte, die TEEs einsetzen, müssen diese Probleme sorgfältig umgehen – indem sie Defense-in-Depth anwenden ( nicht davon ausgehen, dass das TEE unzerbrechlich ist ), die Trusted Computing Base minimal halten und gegenüber den Nutzern transparent über die Vertrauensannahmen kommunizieren ( damit klar ist, dass man beispielsweise neben dem Blockchain-Konsens auch der Hardware von Intel vertraut ).

5. TEEs vs. andere datenschutzfreundliche Technologien (ZKP, FHE, MPC)​

Trusted Execution Environments (TEEs) sind ein Ansatz, um Datenschutz und Sicherheit im Web3 zu erreichen. Es gibt jedoch weitere wichtige Techniken, darunter Zero-Knowledge-Proofs (ZKPs), vollhomomorphe Verschlüsselung (FHE) und sichere Mehrparteienberechnung (MPC). Jede dieser Technologien verfügt über ein anderes Vertrauensmodell und Leistungsprofil. In vielen Fällen schließen sie sich nicht gegenseitig aus – sie können sich ergänzen –, aber es ist nützlich, ihre Abwägungen in Bezug auf Performance, Vertrauen und Benutzerfreundlichkeit für Entwickler zu vergleichen:

Kurzdefinitionen der Alternativen:

• ZKPs: Kryptographische Beweise (wie zk-SNARKs, zk-STARKs), die es einer Partei ermöglichen, anderen gegenüber zu beweisen, dass eine Aussage wahr ist (z. B. „Ich kenne ein Geheimnis, das diese Berechnung erfüllt“), ohne zu verraten, warum sie wahr ist (das Verbergen der geheimen Eingabe). In der Blockchain werden ZKPs für private Transaktionen (z. B. Zcash, Aztec) und für die Skalierbarkeit verwendet (Rollups, die Beweise für eine korrekte Ausführung übermitteln). Sie gewährleisten starken Datenschutz (keine geheimen Daten werden geleakt, nur Beweise) und durch Mathematik garantierte Integrität, aber die Erzeugung dieser Beweise kann rechentechnisch schwerfällig sein, und die Schaltkreise müssen sorgfältig entworfen werden.
• FHE: Ein Verschlüsselungsverfahren, das beliebige Berechnungen auf verschlüsselten Daten ermöglicht, sodass das Ergebnis nach der Entschlüsselung dem Ergebnis der Berechnung auf Klartexten entspricht. Theoretisch bietet FHE ultimativen Datenschutz – die Daten bleiben jederzeit verschlüsselt –, und man muss niemandem die Rohdaten anvertrauen. FHE ist jedoch für allgemeine Berechnungen extrem langsam (obwohl es sich durch Forschung verbessert); aufgrund der Performance befindet es sich noch größtenteils in der experimentellen oder spezialisierten Anwendung.
• MPC: Protokolle, bei denen mehrere Parteien gemeinsam eine Funktion über ihre privaten Eingaben berechnen, ohne diese Eingaben einander offenzulegen. Dabei werden Daten oft mittels Secret-Sharing auf Parteien verteilt und kryptographische Operationen durchgeführt, sodass die Ausgabe korrekt ist, die einzelnen Eingaben jedoch verborgen bleiben. MPC kann Vertrauen verteilen (keine einzelne Instanz sieht alle Daten) und für bestimmte Operationen effizient sein, verursacht aber typischerweise einen Kommunikations- und Koordinationsaufwand und kann für große Netzwerke komplex in der Implementierung sein.

Unten finden Sie eine Vergleichstabelle, die die wichtigsten Unterschiede zusammenfasst:

Technologie	Vertrauensmodell	Performance	Datenschutz	Benutzerfreundlichkeit für Entwickler
TEE (Intel SGX etc.)	Vertrauen in den Hardwarehersteller (in einigen Fällen zentralisierter Attestierungsserver). Setzt voraus, dass der Chip sicher ist; wenn die Hardware kompromittiert wird, ist die Sicherheit gebrochen.	Nahezu native Ausführungsgeschwindigkeit; minimaler Overhead. Gut für Echtzeitberechnungen und große Workloads. Skalierbarkeit begrenzt durch die Verfügbarkeit TEE-fähiger Nodes.	Daten liegen innerhalb der Enklave im Klartext vor, sind aber für die Außenwelt verschlüsselt. Starke Vertraulichkeit, wenn die Hardware hält; bei einer Verletzung der Enklave werden Geheimnisse offengelegt (kein zusätzlicher mathematischer Schutz).	Moderate Komplexität. Bestehender Code/Sprachen (C, Rust) können oft mit geringfügigen Änderungen in der Enklave ausgeführt werden. Niedrigste Einstiegshürde – keine fortgeschrittene Kryptographie nötig – erfordert jedoch Systemprogrammierung und TEE-spezifisches SDK-Wissen.
ZKP (zk-SNARK/STARK)	Vertrauen in mathematische Annahmen (z. B. Schwierigkeit kryptographischer Probleme) und manchmal ein Trusted Setup (für SNARKs). Keine Abhängigkeit von einer einzelnen Partei zur Laufzeit.	Beweiserzeugung ist rechenintensiv (besonders für komplexe Programme), oft um Größenordnungen langsamer als nativ. On-Chain-Verifizierung ist schnell (wenige ms). Nicht ideal für große Datenberechnungen aufgrund der Beweiszeit. Skalierbarkeit: gut für prägnante Verifizierung (Rollups), aber der Prover ist der Flaschenhals.	Sehr starker Datenschutz – Korrektheit kann bewiesen werden, ohne private Eingaben offenzulegen. Nur minimale Informationen (wie Beweisgröße) dringen nach außen. Ideal für finanzielle Privatsphäre etc.	Hohe Komplexität. Erfordert das Erlernen spezialisierter Sprachen (Circuits, zkDSLs wie Circom oder Noir) und das Denken in arithmetischen Schaltkreisen. Debugging ist schwierig. Wenige Experten verfügbar.
FHE	Vertrauen in die Mathematik (Gitterprobleme). Keine vertrauenswürdige Partei; Sicherheit hält, solange die Verschlüsselung nicht gebrochen wird.	Sehr langsam für den allgemeinen Gebrauch. Operationen auf verschlüsselten Daten sind mehrere Größenordnungen langsamer als auf Klartext. Skaliert allmählich mit Hardwareverbesserungen und besseren Algorithmen, ist aber aktuell unpraktisch für den Echtzeiteinsatz in Blockchain-Kontexten.	Ultimativer Datenschutz – Daten bleiben die gesamte Zeit verschlüsselt, auch während der Berechnung. Ideal für sensible Daten (z. B. medizinische Daten, institutionenübergreifende Analysen), sofern die Performance dies zulässt.	Sehr spezialisiert. Entwickler benötigen Kryptographie-Hintergrund. Einige Bibliotheken (wie Microsoft SEAL, TFHE) existieren, aber das Schreiben beliebiger Programme in FHE ist schwierig und umständlich. Noch kein routinemäßiges Entwicklungsziel für dApps.
MPC	Vertrauen verteilt auf mehrere Parteien. Setzt voraus, dass ein Schwellenwert von Parteien ehrlich ist (keine Kollusion über eine bestimmte Anzahl hinaus). Kein Hardware-Vertrauen nötig. Vertrauensbruch bei zu viel Kollusion.	Typischerweise langsamer als nativ aufgrund von Kommunikationsrunden, aber oft schneller als FHE. Performance variiert: Einfache Operationen (Addition, Multiplikation) können effizient sein; komplexe Logik kann Kommunikationskosten sprengen. Latenz ist abhängig von Netzwerkgeschwindigkeiten. Skalierbarkeit durch Sharding oder partielle Vertrauensannahmen verbesserbar.	Starker Datenschutz, wenn Annahmen halten – kein einzelner Knoten sieht die gesamte Eingabe. Informationen können jedoch über die Ausgabe leaken oder wenn Parteien ausfallen (zudem fehlt die Prägnanz von ZK – man erhält das Ergebnis, aber keinen einfach teilbaren Beweis ohne erneutes Ausführen des Protokolls).	Hohe Komplexität. Erfordert das Design eines benutzerdefinierten Protokolls pro Anwendungsfall oder die Nutzung von Frameworks (wie SPDZ). Entwickler müssen kryptographische Protokolle verstehen und oft die Bereitstellung mehrerer Knoten koordinieren. Integration in Blockchain-Apps kann komplex sein.

Quellen: Der obige Vergleich stützt sich auf Analysen wie die von Sanders Network, die hervorheben, dass TEEs bei Geschwindigkeit und Benutzerfreundlichkeit glänzen, während ZK und FHE auf maximale Vertrauenslosigkeit auf Kosten hoher Rechenleistung setzen und MPC Vertrauen verteilt, aber Netzwerk-Overhead einführt.

Aus der Tabelle ergeben sich einige wichtige Abwägungen:

• Performance: TEEs haben einen großen Vorteil bei der reinen Geschwindigkeit und der geringen Latenz. MPC kann oft moderate Komplexität mit gewissen Verzögerungen bewältigen, ZK ist langsam in der Erzeugung, aber schnell in der Verifizierung (asynchrone Nutzung), und FHE ist derzeit bei weitem am langsamsten für beliebige Aufgaben (wenn auch in Ordnung für begrenzte Operationen wie einfache Additionen/Multiplikationen). Wenn Ihre Anwendung komplexe Echtzeitverarbeitung benötigt (wie interaktive Anwendungen, Hochfrequenzentscheidungen), sind TEEs oder vielleicht MPC (mit wenigen Parteien und guten Verbindungen) heute die einzigen praktikablen Optionen. ZK und FHE wären in solchen Szenarien zu langsam.

• Vertrauensmodell: ZKP und FHE sind rein vertrauenslos (man vertraut nur der Mathematik). MPC verlagert das Vertrauen auf Annahmen über die Ehrlichkeit der Teilnehmer (was durch viele Parteien oder wirtschaftliche Anreize gestärkt werden kann). TEEs setzen Vertrauen in die Hardware und den Hersteller voraus. Dies ist ein grundlegender Unterschied: TEEs führen eine vertrauenswürdige dritte Partei (den Chip) in die normalerweise vertrauenslose Welt der Blockchain ein. Im Gegensatz dazu werden ZK und FHE oft dafür gelobt, dass sie besser mit dem dezentralen Ethos übereinstimmen – keine speziellen Instanzen, denen man vertrauen muss, nur rechnerische Härte. MPC liegt dazwischen: Vertrauen ist dezentralisiert, aber nicht eliminiert (wenn N von M Knoten kolludieren, bricht der Datenschutz). Für maximale Vertrauenslosigkeit (z. B. ein wirklich zensurresistentes, dezentrales System) tendiert man eher zu kryptographischen Lösungen. Andererseits akzeptieren viele praktische Systeme die Annahme, dass Intel ehrlich ist oder dass eine Gruppe großer Validatoren nicht kolludieren wird, und tauschen ein Stück Vertrauen gegen enorme Effizienzgewinne ein.

• Sicherheit/Schwachstellen: TEEs können, wie besprochen, durch Hardware-Bugs oder Seitenkanäle untergraben werden. Die Sicherheit von ZK und FHE kann untergraben werden, wenn die zugrunde liegende Mathematik (z. B. elliptische Kurven oder Gitterprobleme) gebrochen wird, aber dies sind gut untersuchte Probleme, und Angriffe würden wahrscheinlich bemerkt werden (zudem können Parameterwahlen bekannte Risiken mindern). Die Sicherheit von MPC kann durch aktive Angreifer gebrochen werden, wenn das Protokoll nicht dafür ausgelegt ist (einige MPC-Protokolle setzen „ehrliche, aber neugierige“ Teilnehmer voraus und könnten scheitern, wenn jemand offen betrügt). Im Blockchain-Kontext könnte ein TEE-Bruch katastrophaler sein (alle Enklaven-basierten Verträge könnten bis zum Patch gefährdet sein), während ein kryptographischer ZK-Bruch (wie die Entdeckung einer Schwachstelle in einer Hash-Funktion eines ZK-Rollups) ebenfalls katastrophal wäre, aber angesichts der einfacheren Annahme im Allgemeinen als weniger wahrscheinlich gilt. Die Angriffsfläche ist sehr unterschiedlich: TEEs müssen sich um Dinge wie Leistungsanalyse sorgen, während ZK sich um mathematische Durchbrüche sorgen muss.

• Datenschutz: FHE und ZK bieten die stärksten Datenschutzgarantien – Daten bleiben kryptographisch geschützt. MPC stellt sicher, dass Daten verteilt (secret-shared) werden, sodass keine einzelne Partei sie sieht (obwohl Informationen leaken könnten, wenn Ausgaben öffentlich sind). TEEs halten Daten vor der Außenwelt geheim, aber innerhalb der Enklave werden die Daten entschlüsselt; wenn jemand irgendwie die Kontrolle über die Enklave erlangt, geht die Vertraulichkeit verloren. Zudem erlauben TEEs dem Code typischerweise, alles mit den Daten zu tun (einschließlich des unbeabsichtigten Leakens durch Seitenkanäle oder das Netzwerk, wenn der Code bösartig ist). TEEs erfordern also, dass man auch dem Enklaven-Code vertraut, nicht nur der Hardware. Im Gegensatz dazu beweisen ZKPs Eigenschaften des Codes, ohne jemals Geheimnisse preiszugeben, sodass man nicht einmal dem Code vertrauen muss (über die Tatsache hinaus, dass er tatsächlich die bewiesene Eigenschaft besitzt). Wenn eine Enklaven-Anwendung einen Bug hätte, der Daten in eine Logdatei schreibt, würde die TEE-Hardware das nicht verhindern – während ein ZK-Beweissystem einfach nichts außer dem beabsichtigten Beweis offenbaren würde. Dies ist eine Nuance: TEEs schützen vor externen Angreifern, aber nicht unbedingt vor Logikfehlern im Enklaven-Programm selbst, während das Design von ZK einen deklarativeren Ansatz erzwingt (man beweist genau das, was beabsichtigt ist, und nichts mehr).

• Komponierbarkeit & Integration: TEEs lassen sich relativ einfach in bestehende Systeme integrieren – man kann ein bestehendes Programm nehmen, es in eine Enklave verschieben und erhält Sicherheitsvorteile, ohne das Programmiermodell zu stark zu verändern. ZK und FHE erfordern oft das Umschreiben des Programms in einen Schaltkreis oder eine restriktive Form, was einen massiven Aufwand bedeuten kann. Beispielsweise beinhaltet das Schreiben einer einfachen KI-Modellverifizierung in ZK die Transformation in eine Reihe von arithmetischen Operationen und Constraints, was weit davon entfernt ist, einfach TensorFlow in einer TEE auszuführen und das Ergebnis zu attestieren. MPC erfordert ähnlich oft benutzerdefinierte Protokolle pro Anwendungsfall. Aus Sicht der Entwicklerproduktivität und Kosten sind TEEs daher attraktiv. Wir haben in einigen Bereichen eine schnellere Einführung von TEEs gesehen, gerade weil man bestehende Software-Ökosysteme nutzen kann. ZK/MPC erfordern spezialisierte Ingenieurstalente, die knapp sind. Die Kehrseite ist jedoch, dass TEEs oft zu isolierteren Lösungen führen (man muss dieser Enklave oder dieser Gruppe von Knoten vertrauen), während ZK einen Beweis liefert, den jeder On-Chain prüfen kann, was es hochgradig komponierbar macht. ZK-Ergebnisse sind portabel – sie erzeugen einen kleinen Beweis, den beliebig viele andere Verträge oder Nutzer verwenden können. TEE-Ergebnisse liegen meist in Form einer Attestierung vor, die an eine bestimmte Hardware gebunden und möglicherweise nicht prägnant ist; sie sind vielleicht nicht so leicht teilbar oder Chain-agnostisch.

In der Praxis sehen wir hybride Ansätze: Zum Beispiel argumentiert Sanders Network, dass TEE, MPC und ZK jeweils in unterschiedlichen Bereichen glänzen und sich ergänzen können. Ein konkreter Fall ist die dezentrale Identität: Man könnte ZK-Beweise verwenden, um ein Identitätsmerkmal zu beweisen, ohne es offenzulegen, aber dieses Merkmal könnte durch einen TEE-basierten Prozess verifiziert und ausgestellt worden sein, der Dokumente privat geprüft hat. Oder betrachten Sie die Skalierung: ZK-Rollups liefern prägnante Beweise für viele Transaktionen, aber die Erzeugung dieser Beweise könnte beschleunigt werden, indem TEEs verwendet werden, um einige Berechnungen schneller durchzuführen (und dann nur eine kleinere Aussage zu beweisen). Die Kombination kann manchmal die Vertrauensanforderung an TEEs verringern (z. B. TEEs für Performance nutzen, aber die endgültige Korrektheit dennoch über einen ZK-Beweis oder ein On-Chain-Challenge-Game verifizieren, sodass eine kompromittierte TEE nicht betrügen kann, ohne erwischt zu werden). Gleichzeitig kann MPC mit TEEs kombiniert werden, indem der Rechenknoten jeder Partei eine TEE ist, was eine zusätzliche Schutzschicht bietet, sodass selbst bei Kollusion einiger Parteien diese die Daten der anderen nicht sehen können, es sei denn, sie brechen auch die Hardware-Sicherheit.

Zusammenfassend bieten TEEs einen sehr praktischen und unmittelbaren Weg zu sicherer Berechnung mit moderaten Annahmen (Hardware-Vertrauen), während ZK und FHE einen eher theoretischen und vertrauenslosen Weg bei hohen Rechenkosten bieten und MPC einen Pfad des verteilten Vertrauens mit Netzwerkkosten darstellt. Die richtige Wahl im Web3 hängt von den Anforderungen der Anwendung ab:

• Wenn Sie schnelle, komplexe Berechnungen auf privaten Daten benötigen (wie KI, große Datensätze) – sind TEEs (oder MPC mit wenigen Parteien) derzeit der einzige gangbare Weg.
• Wenn Sie maximale Dezentralisierung und Verifizierbarkeit benötigen – glänzen ZK-Beweise (beispielsweise bevorzugen private Kryptowährungstransaktionen ZKP wie in Zcash, da Nutzer nichts außer der Mathematik vertrauen wollen).
• Wenn Sie kollaboratives Rechnen zwischen mehreren Stakeholdern benötigen – ist MPC von Natur aus geeignet (wie Multi-Party Key Management oder Auktionen).
• Wenn Sie extrem sensible Daten haben und langfristiger Datenschutz ein Muss ist – könnte FHE attraktiv sein, falls sich die Performance verbessert, denn selbst wenn jemand Ihre Chiffretexte Jahre später erhielte, würde er ohne den Schlüssel nichts erfahren; während ein Enklaven-Bruch Geheimnisse rückwirkend offenlegen könnte, falls Logs aufbewahrt wurden.

Es ist bemerkenswert, dass der Blockchain-Raum all diese Technologien aktiv parallel erforscht. Wir werden wahrscheinlich Kombinationen sehen: z. B. Layer-2-Lösungen, die TEEs integrieren, um Transaktionen zu sequenzieren, und dann einen ZKP verwenden, um zu beweisen, dass die TEE die Regeln befolgt hat, oder MPC-Netzwerke, die TEEs in jedem Knoten verwenden, um die Komplexität der MPC-Protokolle zu verringern.

Letztendlich ist die Wahl zwischen TEEs, ZK, MPC und FHE keine Nullsummenentscheidung – sie zielen jeweils auf unterschiedliche Punkte im Dreieck aus Sicherheit, Performance und Vertrauenslosigkeit ab. Wie es in einem Artikel hieß: Alle vier stehen vor einem „unmöglichen Dreieck“ aus Performance, Kosten und Sicherheit – keine einzelne Lösung ist in allen Aspekten überlegen. Das optimale Design nutzt oft das richtige Werkzeug für den richtigen Teil des Problems.

6. Einführung in bedeutenden Blockchain-Ökosystemen​

Trusted Execution Environments (TEEs) wurden in verschiedenen Blockchain-Ökosystemen in unterschiedlichem Maße eingeführt, oft beeinflusst durch die Prioritäten dieser Communities und die Einfachheit der Integration. Hier bewerten wir, wie TEEs in einigen der wichtigsten Ökosysteme verwendet (oder erforscht) werden: Ethereum, Cosmos und Polkadot, sowie in weiteren Bereichen:

Ethereum (und allgemeine Layer-1-Lösungen)​

Auf dem Ethereum-Mainnet selbst sind TEEs kein Teil des Kernprotokolls, aber sie finden Anwendung in Anwendungen und Layer-2-Lösungen. Die Philosophie von Ethereum stützt sich primär auf kryptografische Sicherheit (z. B. die aufkommenden ZK-Rollups), doch TEEs haben Rollen in Orakeln und der Off-chain-Ausführung für Ethereum übernommen:

• Orakel-Dienste: Wie bereits erörtert, hat Chainlink TEE-basierte Lösungen wie Town Crier integriert. Obwohl nicht alle Chainlink-Nodes standardmäßig TEEs verwenden, ist die Technologie für Datenfeeds vorhanden, die ein besonderes Maß an Vertrauen erfordern. Auch API3 (ein weiteres Orakel-Projekt) hat die Verwendung von Intel SGX erwähnt, um APIs zu betreiben und Daten zu signieren, um die Authentizität zu gewährleisten. Diese Dienste liefern Daten an Ethereum-Smart-Contracts mit stärkeren Zusicherungen.

• Layer-2 und Rollups: In der Ethereum-Community gibt es laufende Forschungen und Debatten über den Einsatz von TEEs in Rollup-Sequencern oder Validatoren. Beispielsweise haben das „ZK-Portal“-Konzept von ConsenSys und andere die Nutzung von TEEs vorgeschlagen, um die korrekte Reihenfolge in optimistischen Rollups zu erzwingen oder den Sequencer vor Zensur zu schützen. Ein Medium-Artikel deutet sogar an, dass TEE bis 2025 ein Standardmerkmal in einigen L2-Lösungen für Bereiche wie den Schutz des Hochfrequenzhandels werden könnte. Projekte wie Catalyst (eine DEX für Hochfrequenzhandel) und Flashbots (für MEV-Relays) haben TEEs untersucht, um eine faire Reihenfolge von Transaktionen zu erzwingen, bevor sie die Blockchain erreichen.

• Enterprise Ethereum: In Konsortial- oder zugangsbeschränkten Ethereum-Netzwerken sind TEEs weiter verbreitet. Das Trusted Compute Framework (TCF) der Enterprise Ethereum Alliance war im Grunde ein Entwurf für die Integration von TEEs in Ethereum-Clients. Hyperledger Avalon (ehemals EEA TCF) ermöglicht es, Teile von Ethereum-Smart-Contracts off-chain in einem TEE auszuführen und anschließend on-chain zu verifizieren. Mehrere Unternehmen wie IBM, Microsoft und iExec haben dazu beigetragen. Während dies im öffentlichen Ethereum-Netzwerk nicht üblich geworden ist, können TEEs in privaten Implementierungen (z. B. eine Gruppe von Banken, die Quorum oder Besu nutzen) verwendet werden, damit selbst Konsortialmitglieder die Daten der anderen nicht sehen, sondern nur die autorisierten Ergebnisse. Dies kann die Datenschutzanforderungen im Unternehmensumfeld erfüllen.

• Bemerkenswerte Projekte: Neben iExec, das auf Ethereum operiert, gab es Projekte wie Enigma (das ursprünglich als MPC-Projekt am MIT begann, dann auf SGX umschwenkte und später zum Secret Network auf Cosmos wurde). Ein weiteres war Decentralized Cloud Services (DCS) in frühen Ethereum-Diskussionen. In jüngerer Zeit ermöglicht Oasis Ethereum ParaTime (Oasis Sapphire), dass Solidity-Contracts mit Vertraulichkeit ausgeführt werden, indem das TEE-Backend von Oasis genutzt wird, während die Abrechnung auf Ethereum erfolgt. Auch einige Ethereum-basierte DApps für den Austausch medizinischer Daten oder für Spiele haben mit TEEs experimentiert, indem sie eine Off-chain-Enklaven-Komponente nutzen, die mit ihren Smart Contracts interagiert.

Die Einführung bei Ethereum ist also eher indirekt – das Protokoll wurde nicht dahingehend geändert, TEEs vorauszusetzen, aber es gibt eine Vielzahl optionaler Dienste und Erweiterungen, die TEEs für spezifische Anforderungen nutzen. Wichtig ist, dass Ethereum-Forscher vorsichtig bleiben: Vorschläge für einen „nur TEE-basierten Shard“ oder eine tiefe Integration von TEEs stießen aufgrund von Vertrauensbedenken auf Skepsis in der Community. Stattdessen werden TEEs eher als „Co-Prozessoren“ für Ethereum und nicht als Kernkomponenten gesehen.

Cosmos-Ökosystem​

Das Cosmos-Ökosystem ist dank seines modularen SDKs und souveräner Chains offen für Experimente, und das Secret Network (oben behandelt) ist ein Paradebeispiel für die TEE-Einführung in Cosmos. Secret Network ist faktisch eine Cosmos SDK-Chain mit Tendermint-Konsens, die so modifiziert wurde, dass SGX für ihre Validatoren obligatorisch ist. Es ist eine der bekanntesten Cosmos-Zonen nach dem Cosmos Hub, was auf eine erhebliche Akzeptanz der TEE-Technologie in dieser Community hindeutet. Der Erfolg von Secret bei der Bereitstellung von Interchain-Datenschutz (durch seine IBC-Verbindungen kann Secret als Datenschutz-Hub für andere Cosmos-Chains fungieren) ist ein bemerkenswerter Fall von TEE-Integration auf Layer-1-Ebene.

Ein weiteres Projekt mit Cosmos-Bezug ist das Oasis Network (obwohl es nicht auf dem Cosmos SDK aufbaut, wurde es von einigen der gleichen Personen entworfen, die zu Tendermint beigetragen haben, und teilt ein ähnliches Ethos einer modularen Architektur). Oasis ist eigenständig, kann aber über Bridges usw. mit Cosmos verbunden werden. Sowohl Secret als auch Oasis zeigen, dass im Cosmos-Umfeld die Idee von „Datenschutz als Feature“ via TEEs genug Anklang fand, um dedizierte Netzwerke zu rechtfertigen.

Cosmos verfügt sogar über ein Konzept von „Datenschutz-Providern“ für Interchain-Anwendungen – z. B. kann eine App auf einer Chain einen Contract auf dem Secret Network via IBC aufrufen, um eine vertrauliche Berechnung durchzuführen, und das Ergebnis zurückerhalten. Diese Komponierbarkeit entwickelt sich gerade.

Zusätzlich hat das Projekt Anoma (nicht strikt Cosmos, aber im Sinne der Interoperabilität verwandt) über die Nutzung von TEEs für Intent-zentrierte Architekturen gesprochen, wenngleich dies eher theoretischer Natur ist.

Kurz gesagt: Cosmos hat mindestens eine große Chain, die TEEs vollständig nutzt (Secret), und andere, die damit interagieren, was eine gesunde Akzeptanz in diesem Bereich illustriert. Die Modularität von Cosmos könnte weitere solcher Chains ermöglichen (man könnte sich beispielsweise eine Cosmos-Zone vorstellen, die auf TEE-basierte Orakel oder Identität spezialisiert ist).

Polkadot und Substrate​

Das Design von Polkadot erlaubt es Parachains, sich zu spezialisieren, und tatsächlich beherbergt Polkadot mehrere Parachains, die TEEs nutzen:

• Sanders Network: Bereits beschrieben; eine Parachain, die eine TEE-basierte Compute-Cloud anbietet. Sanders ist als Parachain live und stellt Dienste für andere Chains über XCMP (Cross-Chain Message Passing) bereit. Beispielsweise kann ein anderes Polkadot-Projekt eine vertrauliche Aufgabe an die Worker von Sanders auslagern und einen Beweis oder ein Ergebnis zurückerhalten. Die Token-Ökonomik von Sanders schafft Anreize für den Betrieb von TEE-Nodes, und das Projekt hat eine beachtliche Community, was auf eine starke Akzeptanz hindeutet.
• Integritee: Eine weitere Parachain, die sich auf Unternehmens- und Datenschutzlösungen mittels TEEs konzentriert. Integritee ermöglicht es Teams, eigene private Sidechains (genannt Teewasms) bereitzustellen, in denen die Ausführung in Enklaven erfolgt. Es zielt auf Anwendungsfälle wie die vertrauliche Datenverarbeitung für Unternehmen ab, die dennoch die Sicherheit von Polkadot als Anker nutzen möchten.
• /Root oder Crust?: Es gab Ideen zur Nutzung von TEEs für dezentrale Speicherung oder Random Beacons in einigen Polkadot-bezogenen Projekten. Zum Beispiel plante das Crust Network (dezentraler Speicher) ursprünglich einen TEE-basierten Proof-of-Storage (obwohl man später zu einem anderen Design überging). Und Polkadots Random-Parachain (Entropy) zog TEEs gegenüber VRFs in Erwägung.

Polkadots Vertrauen auf On-chain-Governance und Upgrades bedeutet, dass Parachains neue Technologien schnell integrieren können. Sowohl Sanders und Integritee haben Upgrades durchlaufen, um ihre TEE-Integration zu verbessern (z. B. die Unterstützung neuer SGX-Funktionen oder die Verfeinerung von Attestierungsmethoden). Die Web3 Foundation finanzierte zudem frühere Bemühungen an Substrate-basierten TEE-Projekten wie SubstraTEE (ein früher Prototyp, der die Off-chain-Ausführung von Contracts in TEEs mit On-chain-Verifizierung demonstrierte).

Das Polkadot-Ökosystem zeigt somit mehrere unabhängige Teams, die auf TEE-Technologie setzen, was auf einen positiven Trend hindeutet. Es wird zu einem Verkaufsargument für Polkadot, dass man sagen kann: „Wenn Sie vertrauliche Smart Contracts oder Off-chain-Berechnungen benötigen, haben wir Parachains dafür.“

Andere Ökosysteme und allgemeine Einführung​

• Unternehmen und Konsortien: Außerhalb des öffentlichen Krypto-Sektors haben Hyperledger und Unternehmens-Chains TEEs stetig für zugangsbeschränkte Umgebungen übernommen. Beispielsweise testete der Basler Ausschuss eine TEE-basierte Blockchain für Handelsfinanzierung. Das allgemeine Muster ist: Wo Datenschutz oder Vertraulichkeit ein Muss sind und die Teilnehmer bekannt sind (sodass sie vielleicht sogar kollektiv in Hardware-Sicherheitsmodule investieren), finden TEEs ein ideales Zuhause. Diese machen vielleicht keine Schlagzeilen in den Krypto-Nachrichten, aber in Sektoren wie Lieferketten, Bankenkonsortien oder Netzwerken zum Austausch von Gesundheitsdaten sind TEEs oft die erste Wahl (als Alternative dazu, einfach einem Dritten zu vertrauen oder komplexe Kryptografie einzusetzen).

• Layer-1-Lösungen außerhalb von Ethereum: Einige neuere L1-Lösungen haben mit TEEs experimentiert. Das NEAR Protocol hatte ein frühes Konzept eines TEE-basierten Shards für private Contracts (noch nicht implementiert). Celo zog TEEs für Light-Client-Beweise in Betracht (ihre Plumo-Proofs basieren jetzt auf SNARKs, aber man untersuchte SGX, um Chain-Daten für Mobilgeräte zu komprimieren). Concordium, eine regulierte Datenschutz-L1, verwendet ZK für Anonymität, erforscht aber auch TEEs für die Identitätsprüfung. Dfinity/Internet Computer verwendet sichere Enklaven in seinen Node-Maschinen, allerdings für das Bootstrapping von Vertrauen (nicht für die Contract-Ausführung, da deren „Chain Key“-Kryptografie dies übernimmt).

• Bitcoin: Während Bitcoin selbst keine TEEs verwendet, gab es Nebenprojekte. Zum Beispiel TEE-basierte Custody-Lösungen (wie Vault-Systeme) für Bitcoin-Keys oder bestimmte Vorschläge in DLC (Discrete Log Contracts), Orakel zu verwenden, die durch TEEs gesichert sein könnten. Generell ist die Bitcoin-Community konservativer und würde Intel nicht ohne Weiteres als Teil des Konsenses vertrauen, aber als ergänzende Technologie (Hardware-Wallets mit Secure Elements) ist sie bereits akzeptiert.

• Regulierungsbehörden und Regierungen: Ein interessanter Aspekt der Einführung: Einige Forschungen zu CBDCs (zentralbankgestützte digitale Währungen) haben TEEs untersucht, um Datenschutz durchzusetzen und gleichzeitig Prüfbarkeit zu ermöglichen. Beispielsweise führte die Banque de France Experimente durch, bei denen ein TEE verwendet wurde, um bestimmte Compliance-Prüfungen für ansonsten private Transaktionen durchzuführen. Dies zeigt, dass selbst Regulierungsbehörden TEEs als einen Weg sehen, Datenschutz mit Aufsicht in Einklang zu bringen – man könnte eine CBDC haben, bei der Transaktionen für die Öffentlichkeit verschlüsselt sind, aber eine Regulierungs-Enklave sie unter bestimmten Bedingungen überprüfen kann (dies ist hypothetisch, wird aber in politischen Kreisen diskutiert).

• Metriken zur Einführung: Die Einführung lässt sich schwer quantifizieren, aber wir können auf Indikatoren wie die Anzahl der Projekte, investierte Mittel und die Verfügbarkeit von Infrastruktur blicken. In dieser Hinsicht haben wir heute (2025): mindestens 3-4 öffentliche Chains (Secret, Oasis, Sanders, Integritee, Automata als Off-chain), die explizit TEEs nutzen; große Orakel-Netzwerke, die sie integrieren; große Technologieunternehmen, die Confidential Computing unterstützen (Microsoft Azure und Google Cloud bieten TEE-VMs an – und diese Dienste werden von Blockchain-Nodes als Optionen genutzt). Das Confidential Computing Consortium umfasst mittlerweile Mitglieder mit Blockchain-Fokus (Ethereum Foundation, Chainlink, Fortanix etc.), was eine branchenübergreifende Zusammenarbeit zeigt. All dies deutet auf eine wachsende, aber nischige Einführung hin – TEEs sind im Web3 noch nicht allgegenwärtig, aber sie haben sich wichtige Nischen dort erschlossen, wo Datenschutz und sichere Off-chain-Berechnungen erforderlich sind.

Dies hat einen positiven regulatorischen Aspekt: Einige Aufsichtsbehörden haben angedeutet, dass Lösungen wie TEEs (und verwandte Konzepte des Confidential Computing) vorteilhaft sind, da sie die technische Durchsetzung des Datenschutzes gewährleisten. Wir haben gesehen, dass das Weltwirtschaftsforum und andere Organisationen TEEs als Mittel hervorheben, um „Privacy by Design“ in Blockchain-Systeme zu integrieren (im Grunde wird die Compliance direkt auf Protokollebene eingebettet). Aus geschäftlicher Sicht können TEEs somit die institutionelle Akzeptanz beschleunigen, indem sie eines der Haupthindernisse (Datenvertraulichkeit) beseitigen. Unternehmen sind eher bereit, Blockchain zu nutzen oder darauf aufzubauen, wenn sie wissen, dass es eine Hardware-Sicherung für ihre Daten gibt.

Ein weiterer Compliance-Aspekt ist die Auditierbarkeit und Aufsicht. Unternehmen benötigen oft Audit-Protokolle und die Möglichkeit, Prüfern gegenüber nachzuweisen, dass sie die Kontrolle über die Daten haben. TEEs können hier tatsächlich helfen, indem sie Attestierungsberichte und sichere Protokolle darüber erstellen, worauf zugegriffen wurde. Beispielsweise bietet das „durable logging“ von Oasis in einer Enklave ein manipulationssicheres Protokoll sensibler Operationen. Ein Unternehmen kann dieses Protokoll den Regulierungsbehörden vorlegen, um zu beweisen, dass beispielsweise nur autorisierter Code ausgeführt wurde und nur bestimmte Abfragen zu Kundendaten erfolgt sind. Diese Art von attestiertem Auditing könnte Regulierungsbehörden mehr überzeugen als ein traditionelles System, bei dem man den Protokollen von Systemadministratoren vertrauen muss.

Vertrauen und Haftung​

Auf der anderen Seite verändert die Einführung von TEEs die Vertrauensstruktur und damit das Haftungsmodell in Blockchain-Lösungen. Wenn eine DeFi-Plattform ein TEE verwendet und aufgrund eines Hardwarefehlers etwas schiefgeht, wer ist dann verantwortlich? Stellen Sie sich ein Szenario vor, in dem ein Intel-SGX-Fehler zum Durchsickern von Details geheimer Swap-Transaktionen führt, wodurch Benutzer Geld verlieren (z. B. durch Front-Running etc.). Die Benutzer haben den Sicherheitsversprechen der Plattform vertraut. Liegt der Fehler bei der Plattform oder bei Intel? Rechtlich gesehen könnten Benutzer gegen die Plattform vorgehen (die wiederum gegen Intel vorgehen müsste). Dies verkompliziert die Angelegenheit, da ein Technologieanbieter eines Drittanbieters (der CPU-Hersteller) tief in das Sicherheitsmodell integriert ist. Unternehmen, die TEEs einsetzen, müssen dies in Verträgen und Risikobewertungen berücksichtigen. Einige könnten Garantien oder Support von Hardwareherstellern verlangen, wenn sie deren TEEs in kritischen Infrastrukturen einsetzen.

Es gibt auch Zentralisierungsbedenken: Wenn die Sicherheit einer Blockchain von der Hardware eines einzelnen Unternehmens (Intel oder AMD) abhängt, könnten Regulierungsbehörden dies skeptisch betrachten. Könnte beispielsweise eine Regierung dieses Unternehmen vorladen oder zwingen, bestimmte Enklaven zu kompromittieren? Dies ist keine rein theoretische Sorge – man denke an Exportkontrollgesetze: Hochwertige Verschlüsselungshardware kann reguliert werden. Wenn ein großer Teil der Krypto-Infrastruktur auf TEEs angewiesen ist, ist es denkbar, dass Regierungen versuchen könnten, Backdoors einzuführen (obwohl es dafür keine Beweise gibt, zählt die Wahrnehmung). Einige Datenschutzbefürworter weisen Regulierungsbehörden darauf hin, dass TEEs das Vertrauen konzentrieren und die Behörden sie daher eher sorgfältig prüfen sollten. Umgekehrt könnten Regulierungsbehörden, die mehr Kontrolle wünschen, TEEs gegenüber mathematikbasiertem Datenschutz wie ZK bevorzugen, da bei TEEs zumindest die Vorstellung besteht, dass Strafverfolgungsbehörden bei absolutem Bedarf mit einer gerichtlichen Anordnung an den Hardwarehersteller herantreten könnten (z. B. um einen Master-Attestierungsschlüssel oder Ähnliches zu erhalten – nicht, dass dies einfach oder wahrscheinlich wäre, aber es ist ein Weg, der bei ZK nicht existiert). Daher kann die regulatorische Aufnahme geteilt sein: Datenschutzbehörden sind pro-TEE für die Compliance, während die Strafverfolgung vorsichtig optimistisch sein könnte, da TEEs nicht in dem Maße „im Dunkeln bleiben“ wie starke Verschlüsselung – es gibt einen theoretischen Hebel (die Hardware), an dem sie versuchen könnten zu ziehen.

Unternehmen müssen dies navigieren, indem sie sich möglicherweise um Zertifizierungen bemühen. Es gibt Sicherheitszertifizierungen wie FIPS 140 oder Common Criteria für Hardwaremodule. Derzeit verfügen SGX und andere über einige Zertifizierungen (zum Beispiel hatte SGX Common Criteria EAL-Zertifizierungen für bestimmte Anwendungen). Wenn eine Blockchain-Plattform darauf verweisen kann, dass die Enklaven-Technologie nach einem hohen Standard zertifiziert ist, fühlen sich Regulierungsbehörden und Partner möglicherweise wohler. Ein CBDC-Projekt könnte beispielsweise verlangen, dass jedes verwendete TEE FIPS-zertifiziert ist, damit sie der Zufallszahlengenerierung usw. vertrauen können. Dies führt zusätzliche Prozesse ein und beschränkt die Auswahl möglicherweise auf bestimmte Hardwareversionen.

Ökosystem- und Kostenüberlegungen​

Aus geschäftlicher Sicht könnte der Einsatz von TEEs die Kostenstruktur eines Blockchain-Betriebs beeinflussen. Knoten müssen über spezifische CPUs verfügen (die teurer oder weniger energieeffizient sein können). Dies könnte höhere Cloud-Hosting-Rechnungen oder Investitionsausgaben bedeuten. Wenn ein Projekt beispielsweise Intel Xeon mit SGX für alle Validatoren vorschreibt, ist das eine Einschränkung – Validatoren können nicht einfach jeder mit einem Raspberry Pi oder einem alten Laptop sein; sie benötigen diese spezielle Hardware. Dies kann zentralisieren, wer teilnehmen kann (was möglicherweise diejenigen bevorzugt, die sich High-End-Server leisten können oder Cloud-Anbieter nutzen, die SGX-VMs anbieten). In extremen Fällen könnte dies das Netzwerk dazu drängen, eher zugangsbeschränkt zu sein oder sich auf Cloud-Anbieter zu verlassen, was einen Abwägungsprozess bei der Dezentralisierung und ein geschäftliches Manko darstellt (das Netzwerk müsste möglicherweise Knotenanbieter subventionieren).

Andererseits könnten einige Unternehmen dies akzeptabel finden, weil sie bekannte Validatoren wollen oder eine Zulassungsliste haben (insbesondere in Unternehmenskonsortien). In öffentlichen Kryptonetzwerken hat dies jedoch zu Debatten geführt – z. B. als SGX erforderlich wurde, fragten die Leute: „Bedeutet das, dass nur noch große Rechenzentren Knoten betreiben werden?“ Das ist etwas, das die Stimmung in der Community und damit die Marktakzeptanz beeinflusst. Krypto-Puristen könnten beispielsweise eine Chain meiden, die TEEs erfordert, und sie als „weniger vertrauenswürdig“ oder zu zentralisiert bezeichnen. Daher müssen Projekte PR und Community-Aufklärung betreiben und klarmachen, wie die Vertrauensannahmen aussehen und warum es dennoch sicher ist. Wir haben gesehen, wie das Secret Network FUD adressiert hat, indem es die strenge Überwachung von Intel-Updates erklärte und darauf hinwies, dass Validatoren geslasht werden, wenn sie ihre Enklaven nicht aktualisieren usw. – im Grunde wurde eine soziale Vertrauensebene über das Hardware-Vertrauen gelegt.

Ein weiterer Aspekt sind Partnerschaften und Support. Das geschäftliche Ökosystem rund um TEEs umfasst große Tech-Unternehmen (Intel, AMD, ARM, Microsoft, Google usw.). Blockchain-Projekte, die TEEs nutzen, gehen oft Partnerschaften mit diesen ein (z. B. iExec mit Intel, das Secret Network mit Intel an Verbesserungen der Attestierung, Oasis mit Microsoft an vertraulicher KI usw.). Diese Partnerschaften können Finanzierung, technische Unterstützung und Glaubwürdigkeit bieten. Es ist ein strategischer Punkt: Die Ausrichtung auf die Confidential-Computing-Branche kann Türen öffnen (für Finanzierungen oder Unternehmenspiloten), bedeutet aber auch, dass sich ein Krypto-Projekt mit großen Konzernen abstimmt, was ideologische Auswirkungen in der Community hat.

Regulatorische Unsicherheiten​

Mit dem Wachstum von Blockchain-Anwendungen, die TEEs nutzen, könnten neue regulatorische Fragen auftauchen. Zum Beispiel:

• Datenjurisdiktion: Wenn Daten innerhalb eines TEE in einem bestimmten Land verarbeitet werden, gelten sie dann als „in diesem Land verarbeitet“ oder als nirgendwo (da sie verschlüsselt sind)? Einige Datenschutzgesetze verlangen, dass die Daten von Bürgern bestimmte Regionen nicht verlassen. TEEs könnten die Grenzen verwischen – man könnte eine Enklave in einer Cloud-Region haben, aber nur verschlüsselte Daten gehen hinein/hinaus. Regulierungsbehörden müssen möglicherweise klären, wie sie eine solche Verarbeitung betrachten.
• Exportkontrollen: Fortgeschrittene Verschlüsselungstechnologie kann Exportbeschränkungen unterliegen. TEEs beinhalten die Verschlüsselung von Arbeitsspeicher – historisch gesehen war dies kein Problem (da CPUs mit diesen Funktionen weltweit verkauft werden), aber falls sich das jemals ändern sollte, könnte dies die Lieferkette beeinträchtigen. Zudem könnten einige Länder die Nutzung ausländischer TEEs aus Gründen der nationalen Sicherheit verbieten oder davon abraten (z. B. hat China ein eigenes Äquivalent zu SGX, da sie Intel nicht vertrauen, und könnten SGX für sensible Anwendungen nicht zulassen).
• Rechtlicher Zwang: Ein Szenario: Könnte eine Regierung einen Knotenbetreiber per Vorladung zwingen, Daten aus einer Enklave zu extrahieren? Normalerweise können sie das nicht, da selbst der Betreiber nicht hineinsehen kann. Aber was, wenn sie Intel für einen bestimmten Attestierungsschlüssel vorladen? Das Design von Intel ist so ausgelegt, dass selbst sie den Speicher der Enklave nicht entschlüsseln können (sie geben Schlüssel an die CPU aus, die die Arbeit erledigt). Aber wenn eine Hintertür existierte oder eine spezielle Firmware von Intel signiert werden könnte, um den Speicher auszulesen, wäre das ein hypothetisches Szenario, das die Menschen beunruhigt. Rechtlich gesehen könnte ein Unternehmen wie Intel sich weigern, wenn es aufgefordert würde, seine Sicherheit zu untergraben (sie würden es wahrscheinlich tun, um das Vertrauen in ihr Produkt nicht zu zerstören). Allein die Möglichkeit könnte jedoch in regulatorischen Diskussionen über den rechtmäßigen Zugriff auftauchen. Unternehmen, die TEEs einsetzen, sollten über solche Entwicklungen auf dem Laufenden bleiben, obwohl derzeit kein öffentlicher Mechanismus für Intel/AMD existiert, um Enklavendaten zu extrahieren – genau das ist ja der Punkt von TEEs.

Marktdifferenzierung und neue Dienste​

Positiv für das Geschäft ist, dass TEEs neue Produkte und Dienstleistungen ermöglichen, die monetarisiert werden können. Zum Beispiel:

• Marktplätze für vertrauliche Daten: Wie iExec, das Ocean Protocol und andere festgestellt haben, besitzen Unternehmen wertvolle Daten, die sie monetarisieren könnten, wenn sie Garantien hätten, dass diese nicht durchsickern. TEEs ermöglichen das „Mieten von Daten“, wobei die Daten die Enklave nie verlassen, sondern nur die daraus gewonnenen Erkenntnisse. Dies könnte neue Einnahmequellen und Geschäftsmodelle erschließen. Wir sehen Start-ups im Web3-Bereich, die Unternehmen Dienstleistungen für vertrauliches Rechnen anbieten und im Grunde die Idee verkaufen: „Erhalten Sie Erkenntnisse aus der Blockchain oder unternehmensübergreifenden Daten, ohne etwas preiszugeben.“
• Enterprise DeFi: Finanzinstitute nennen oft den Mangel an Privatsphäre als Grund, sich nicht an DeFi oder öffentlichen Blockchains zu beteiligen. Wenn TEEs die Vertraulichkeit für ihre Positionen oder Trades garantieren können, könnten sie teilnehmen und so mehr Liquidität und Geschäft in das Ökosystem bringen. Projekte, die darauf abzielen (wie die geheimen Kredite von Secret oder das private AMM von Oasis mit Compliance-Kontrollen), positionieren sich, um institutionelle Nutzer anzuziehen. Wenn dies gelingt, kann dies ein bedeutender Markt sein (man stelle sich institutionelle AMM-Pools vor, in denen Identitäten und Beträge abgeschirmt sind, aber eine Enklave sicherstellt, dass Compliance-Prüfungen wie AML intern durchgeführt werden – das ist ein Produkt, das unter regulatorischer Sicherheit viel Geld in DeFi bringen könnte).
• Versicherung und Risikomanagement: Da TEEs bestimmte Risiken verringern (wie die Manipulation von Orakeln), könnten wir niedrigere Versicherungsprämien oder neue Versicherungsprodukte für Smart-Contract-Plattformen sehen. Umgekehrt führen TEEs neue Risiken ein (wie das technische Versagen von Enklaven), die selbst versicherbare Ereignisse sein könnten. Es gibt einen entstehenden Bereich der Krypto-Versicherung; es wird interessant sein zu sehen, wie sie mit TEE-abhängigen Systemen umgehen. Eine Plattform könnte damit werben, dass sie TEEs einsetzt, um das Risiko von Datenschutzverletzungen zu senken, was sie einfacher oder billiger versicherbar macht und ihr einen Wettbewerbsvorteil verschafft.

Zusammenfassend lässt sich sagen, dass es in der geschäftlichen und regulatorischen Landschaft von TEE-gestütztem Web3 darum geht, Vertrauen und Innovation in Einklang zu bringen. TEEs bieten einen Weg, Gesetze einzuhalten und Anwendungsfälle für Unternehmen zu erschließen (ein großes Plus für die Akzeptanz im Mainstream), bringen aber auch eine Abhängigkeit von Hardwareanbietern und Komplexitäten mit sich, die transparent verwaltet werden müssen. Stakeholder müssen sowohl mit Tech-Giganten (für den Support) als auch mit Regulierungsbehörden (für Klarheit und Sicherheit) zusammenarbeiten, um das Potenzial von TEEs in der Blockchain-Technologie voll auszuschöpfen. Wenn dies gut umgesetzt wird, könnten TEEs ein Eckpfeiler sein, der es der Blockchain ermöglicht, sich tief in Branchen zu integrieren, die mit sensiblen Daten arbeiten, und so die Reichweite von Web3 in Bereiche auszudehnen, die zuvor aufgrund von Datenschutzbedenken tabu waren.

Fazit​

Trusted Execution Environments haben sich als eine leistungsstarke Komponente im Web3-Instrumentarium herauskristallisiert und ermöglichen eine neue Klasse von dezentralen Anwendungen, die Vertraulichkeit und sichere Off-Chain-Berechnungen erfordern. Wir haben gesehen, dass TEEs wie Intel SGX, ARM TrustZone und AMD SEV eine hardware-isolierte „Safe Box“ für Berechnungen bieten, und diese Eigenschaft wurde für datenschutzfreundliche Smart Contracts, verifizierbare Oracles, skalierbare Off-Chain-Verarbeitung und mehr genutzt. Projekte über verschiedene Ökosysteme hinweg – von den privaten Kontrakten von Secret Network auf Cosmos über die vertraulichen ParaTimes von Oasis bis hin zur TEE-Cloud von Sanders auf Polkadot und dem Off-Chain-Marktplatz von iExec auf Ethereum – demonstrieren die vielfältigen Möglichkeiten, wie TEEs in Blockchain-Plattformen integriert werden.

Technisch gesehen bieten TEEs überzeugende Vorteile in Bezug auf Geschwindigkeit und starke Datenvertraulichkeit, bringen jedoch auch eigene Herausforderungen mit sich: die Notwendigkeit, Hardware-Anbietern zu vertrauen, potenzielle Seitenkanal-Schwachstellen sowie Hürden bei der Integration und Komponierbarkeit. Wir haben TEEs mit kryptografischen Alternativen (ZKPs, FHE, MPC) verglichen und festgestellt, dass jede ihre Nische hat: TEEs glänzen durch Leistung und Benutzerfreundlichkeit, während ZK und FHE maximale Vertrauenslosigkeit bei hohen Kosten bieten und MPC das Vertrauen unter den Teilnehmern verteilt. Tatsächlich sind viele wegweisende Lösungen hybrid und nutzen TEEs zusammen mit kryptografischen Methoden, um das Beste aus beiden Welten zu erhalten.

Die Akzeptanz von TEE-basierten Lösungen wächst stetig. Ethereum dApps nutzen TEEs für die Oracle-Sicherheit und private Berechnungen, Cosmos und Polkadot bieten native Unterstützung über spezialisierte Chains, und Bemühungen im Bereich der Enterprise-Blockchains setzen auf TEEs zur Einhaltung von Compliance-Vorgaben. Geschäftlich gesehen können TEEs eine Brücke zwischen dezentraler Technologie und Regulierung schlagen – sie ermöglichen den Umgang mit sensiblen Daten On-Chain unter den Schutzmaßnahmen von Hardware-Sicherheit, was die Tür für institutionelle Nutzung und neue Dienste öffnet. Gleichzeitig bedeutet die Nutzung von TEEs, sich auf neue Vertrauensparadigmen einzulassen und sicherzustellen, dass das Dezentralisierungs-Ethos der Blockchain nicht durch undurchsichtiges Silizium untergraben wird.

Zusammenfassend lässt sich sagen, dass Trusted Execution Environments eine entscheidende Rolle in der Evolution von Web3 spielen: Sie adressieren einige der dringlichsten Bedenken hinsichtlich Datenschutz und Skalierbarkeit, und obwohl sie kein Allheilmittel sind (und nicht ohne Kontroversen bleiben), erweitern sie die Möglichkeiten dezentraler Anwendungen erheblich. Da die Technologie reift – mit Verbesserungen in der Hardware-Sicherheit und Standards für die Attestierung – und da immer mehr Projekte ihren Wert unter Beweis stellen, können wir erwarten, dass TEEs (zusammen mit ergänzenden kryptografischen Technologien) zu einer Standardkomponente von Blockchain-Architekturen werden, die darauf abzielen, das volle Potenzial von Web3 auf sichere und vertrauenswürdige Weise zu erschließen. Die Zukunft hält wahrscheinlich schichtbasierte Lösungen bereit, bei denen Hardware und Kryptografie Hand in Hand arbeiten, um Systeme zu liefern, die sowohl performant als auch nachweislich sicher sind und gleichermaßen den Anforderungen von Nutzern, Entwicklern und Regulierungsbehörden gerecht werden.

Quellen: Die Informationen in diesem Bericht wurden aus einer Vielzahl aktueller Quellen zusammengetragen, darunter offizielle Projektdokumentationen und Blogs, Branchenanalysen und akademische Forschung, wie im gesamten Text zitiert. Zu den bemerkenswerten Referenzen gehören der Metaschool 2025 Leitfaden zu TEEs in Web3, Vergleiche von Sanders Network, technische Einblicke von ChainCatcher und anderen zu FHE / TEE / ZKP / MPC sowie Erklärungen zur regulatorischen Compliance von Binance Research und viele andere. Diese Quellen bieten weitere Details und werden Lesern empfohlen, die bestimmte Aspekte vertiefen möchten.

Öffentliche Blockchains bieten Transparenz und Integrität auf Kosten der Privatsphäre – jeder Transaktions- und Kontraktstatus ist für alle Teilnehmer einsehbar. Diese Offenheit schafft Probleme wie MEV-Angriffe (Miner Extractable Value), Copy-Trading und das Abfließen sensibler Geschäftslogik. Programmierbare Privatsphäre zielt darauf ab, diese Probleme zu lösen, indem Berechnungen auf privaten Daten ermöglicht werden, ohne die Daten selbst preiszugeben. Zwei aufstrebende kryptografische Paradigmen machen dies möglich: Virtual Machines für vollständig homomorphe Verschlüsselung (FHE-VM) und Zero-Knowledge (ZK)-Coprozessoren. Diese Ansätze ermöglichen Off-Chain- oder verschlüsselte Berechnungen mit On-Chain-Verifizierung, wodurch die Vertraulichkeit gewahrt bleibt, während die vertrauenslose Korrektheit erhalten bleibt. In diesem Bericht tauchen wir tief in FHE-VM- und ZK-Coprozessor-Architekturen ein, vergleichen ihre Kompromisse und untersuchen Anwendungsfälle in den Bereichen Finanzen, Identität, Gesundheitswesen, Datenmärkte und dezentrales maschinelles Lernen.

Virtual Machine für vollständig homomorphe Verschlüsselung (FHE-VM)​

Vollständig homomorphe Verschlüsselung (FHE) ermöglicht beliebige Berechnungen auf verschlüsselten Daten, ohne diese jemals entschlüsseln zu müssen. Eine FHE Virtual Machine integriert diese Fähigkeit in Blockchain Smart Contracts und ermöglicht so verschlüsselte Kontraktzustände und -logik. In einer FHE-fähigen Blockchain (oft als fhEVM für EVM-kompatible Designs bezeichnet) bleiben alle Eingaben, der Kontraktspeicher und die Ausgaben während der gesamten Ausführung verschlüsselt. Dies bedeutet, dass Validatoren Transaktionen verarbeiten und Zustände aktualisieren können, ohne sensible Werte zu erfahren, wodurch eine On-Chain-Ausführung mit Datenvertraulichkeit erreicht wird.

Architektur und Design der FHE-VM​

Eine typische FHE-VM erweitert eine Standard-Smart-Contract-Laufzeitumgebung (wie die Ethereum Virtual Machine) um native Unterstützung für verschlüsselte Datentypen und Operationen. Beispielsweise führt die FHEVM von Zama verschlüsselte Ganzzahlen (euint8, euint32 usw.), verschlüsselte Booleans (ebool) und sogar verschlüsselte Arrays als First-Class-Typen ein. Smart-Contract-Sprachen wie Solidity werden durch Bibliotheken oder neue Opcodes ergänzt, sodass Entwickler arithmetische Operationen (add, mul usw.), logische Operationen und Vergleiche direkt auf Ciphertexten durchführen können. Im Hintergrund rufen diese Operationen FHE-Primitive auf (z. B. unter Verwendung der TFHE-Bibliothek), um verschlüsselte Bits zu manipulieren und verschlüsselte Ergebnisse zu erzeugen.

Die verschlüsselte Zustandspeicherung wird unterstützt, sodass Kontraktvariablen im Blockchain-Status verschlüsselt bleiben. Der Ausführungsfluss ist typischerweise:

1. Client-seitige Verschlüsselung: Benutzer verschlüsseln ihre Eingaben lokal mit dem öffentlichen FHE-Schlüssel, bevor sie Transaktionen senden. Der Verschlüsselungsschlüssel ist öffentlich (für Verschlüsselung und Auswertung), während der Entschlüsselungsschlüssel geheim bleibt. In einigen Designs verwaltet jeder Benutzer seinen eigenen Schlüssel; in anderen wird ein einzelner globaler FHE-Schlüssel verwendet (unten besprochen).
2. On-Chain homomorphe Berechnung: Miner/Validatoren führen den Kontrakt mit verschlüsselten Opcodes aus. Sie führen dieselben deterministischen homomorphen Operationen auf den Ciphertexten durch, sodass ein Konsens über den verschlüsselten neuen Zustand erzielt werden kann. Entscheidend ist, dass Validatoren niemals Klartextdaten sehen – sie sehen nur „unverständlichen“ Ciphertext, können diesen aber dennoch konsistent verarbeiten.
3. Entschlüsselung (optional): Wenn ein Ergebnis offengelegt oder Off-Chain verwendet werden muss, kann eine autorisierte Partei mit dem privaten Schlüssel den Ausgabe-Ciphertext entschlüsseln. Andernfalls bleiben die Ergebnisse verschlüsselt und können als Eingaben für weitere Transaktionen verwendet werden (was fortlaufende Berechnungen auf persistentem verschlüsseltem Zustand ermöglicht).

Eine wichtige Designüberlegung ist das Key Management. Ein Ansatz sind benutzerspezifische Schlüssel, bei denen jeder Benutzer seinen geheimen Schlüssel hält und nur er die für ihn relevanten Ausgaben entschlüsseln kann. Dies maximiert die Privatsphäre (niemand sonst kann jemals Ihre Daten entschlüsseln), aber homomorphe Operationen können Daten, die unter verschiedenen Schlüsseln verschlüsselt sind, nicht ohne komplexe Multi-Key-Protokolle mischen. Ein anderer Ansatz, der von Zamas FHEVM verwendet wird, ist ein globaler FHE-Schlüssel: Ein einziger öffentlicher Schlüssel verschlüsselt alle Kontraktdaten, und eine verteilte Gruppe von Validatoren hält Anteile am Threshold-Entschlüsselungsschlüssel. Die öffentlichen Verschlüsselungs- und Auswertungsschlüssel werden On-Chain veröffentlicht, sodass jeder Daten für das Netzwerk verschlüsseln kann; der private Schlüssel wird unter den Validatoren aufgeteilt, die bei Bedarf gemeinsam unter einem Threshold-Schema entschlüsseln können. Um zu verhindern, dass Absprachen zwischen Validatoren die Privatsphäre gefährden, setzt Zama ein Threshold-FHE-Protokoll (basierend auf ihrer Noah’s Ark-Forschung) mit „Noise Flooding“ ein, um Teilentschlüsselungen sicher zu machen. Nur wenn ein ausreichendes Quorum von Validatoren kooperiert, kann ein Klartext wiederhergestellt werden, beispielsweise um eine Leseanfrage zu bedienen. Im Normalbetrieb sieht jedoch kein einzelner Knoten jemals Klartext – die Daten bleiben jederzeit auf der Chain verschlüsselt.

Die Zugriffskontrolle ist eine weitere entscheidende Komponente. FHE-VM-Implementierungen enthalten feinkörnige Kontrollen, um zu verwalten, wer (falls überhaupt jemand) Entschlüsselungen auslösen oder auf bestimmte verschlüsselte Felder zugreifen kann. Beispielsweise unterstützt die fhEVM von Cypher Access Control Lists (ACLs) auf Ciphertexten, was es Entwicklern ermöglicht, festzulegen, welche Adressen oder Kontrakte mit bestimmten Daten interagieren oder diese neu verschlüsseln dürfen. Einige Frameworks unterstützen die Neuverschlüsselung (Re-encryption): die Fähigkeit, einen verschlüsselten Wert von dem Schlüssel eines Benutzers auf den eines anderen zu übertragen, ohne den Klartext offenzulegen. Dies ist nützlich für Dinge wie Datenmarktplätze, auf denen ein Dateneigentümer einen Datensatz mit seinem Schlüssel verschlüsseln und ihn beim Kauf auf den Schlüssel des Käufers neu verschlüsseln kann – alles On-Chain, ohne jemals öffentlich zu entschlüsseln.

Sicherstellung von Korrektheit und Privatsphäre​

Man könnte fragen: Wenn alle Daten verschlüsselt sind, wie setzen wir die Korrektheit der Kontraktlogik durch? Wie kann die Chain ungültige Operationen verhindern, wenn sie die Werte nicht „sehen“ kann? FHE allein liefert keinen Beweis für die Korrektheit – Validatoren können die homomorphen Schritte ausführen, aber sie können nicht von Natur aus feststellen, ob die verschlüsselte Eingabe eines Benutzers gültig war oder ob ein bedingter Zweig genommen werden sollte usw., ohne zu entschlüsseln. Zero-Knowledge-Proofs (ZKPs) können FHE ergänzen, um diese Lücke zu schließen. In einer FHE-VM müssen Benutzer in der Regel einen ZK-Beweis vorlegen, der bestimmte Klartextbedingungen bestätigt, wann immer dies erforderlich ist. Zamas Design verwendet beispielsweise einen ZK Proof of Plaintext Knowledge (ZKPoK), der jede verschlüsselte Eingabe begleitet. Dies beweist, dass der Benutzer den Klartext kennt, der seinem Ciphertext entspricht, und dass dieser die erwarteten Kriterien erfüllt, ohne den Klartext selbst offenzulegen. Solche „zertifizierten Ciphertexte“ verhindern, dass ein böswilliger Benutzer eine fehlerhafte Verschlüsselung oder einen Wert außerhalb des zulässigen Bereichs einreicht. Ähnlich kann der Benutzer bei Operationen, die eine Entscheidung erfordern (z. B. sicherstellen, dass Kontostand ≥ Auszahlungsbetrag), einen ZK-Beweis liefern, dass diese Bedingung auf den Klartexten zutrifft, bevor die verschlüsselte Operation ausgeführt wird. Auf diese Weise entschlüsselt oder sieht die Chain die Werte nicht, gewinnt aber die Gewissheit, dass die verschlüsselten Transaktionen den Regeln folgen.

Ein anderer Ansatz in FHE-Rollups besteht darin, eine Off-Chain-Validierung mit ZKPs durchzuführen. Fhenix (ein L2-Rollup, das FHE verwendet) entscheidet sich für ein optimistisches Modell, bei dem eine separate Netzwerkkomponente namens Threshold Service Network verschlüsselte Ergebnisse entschlüsseln oder verifizieren kann, und jede fehlerhafte Berechnung mit einem Fraud-Proof angefochten werden kann. Im Allgemeinen stellt die Kombination von FHE + ZK oder Fraud-Proofs sicher, dass die verschlüsselte Ausführung vertrauenslos (trustless) bleibt. Validatoren entschlüsseln entweder kollektiv nur bei Autorisierung oder sie verifizieren Beweise, dass jeder verschlüsselte Zustandsübergang gültig war, ohne Klartext sehen zu müssen.

Performance-Überlegungen: FHE-Operationen sind rechenintensiv – viele Größenordnungen langsamer als normale Arithmetik. Beispielsweise kostet eine einfache 64-Bit-Addition auf Ethereum etwa 3 Gas, während eine Addition auf einer verschlüsselten 64-Bit-Ganzzahl (euint64) unter Zamas FHEVM etwa 188.000 Gas kostet. Selbst eine 8-Bit-Addition kann rund 94k Gas kosten. Dieser enorme Overhead bedeutet, dass eine einfache Implementierung auf bestehenden Knoten unpraktisch langsam und kostspielig wäre. FHE-VM-Projekte gehen dies mit optimierten kryptografischen Bibliotheken (wie Zamas TFHE-rs-Bibliothek für binäres Gate-Bootstrapping) und kundenspezifischen EVM-Modifikationen für die Performance an. Beispielsweise fügt der modifizierte Geth-Client von Cypher neue Opcodes hinzu und optimiert die Ausführung homomorpher Instruktionen in C++/Assembly, um den Overhead zu minimieren. Dennoch erfordert das Erreichen eines nutzbaren Durchsatzes eine Beschleunigung. Laufende Arbeiten umfassen den Einsatz von GPUs, FPGAs und sogar spezialisierten photonischen Chips, um FHE-Berechnungen zu beschleunigen. Zama berichtet, dass sich ihre FHE-Performance seit 2024 verhundertfacht hat und strebt mit GPU/FPGA-Beschleunigung Tausende von TPS an. Dedizierte FHE-Coprozessor-Server (wie der LightLocker Node von Optalysys) können an Validator-Knoten angeschlossen werden, um verschlüsselte Operationen auf Hardware auszulagern und so über 100 verschlüsselte ERC-20-Transfers pro Sekunde und Knoten zu unterstützen. Da sich Hardware und Algorithmen verbessern, wird sich die Lücke zwischen FHE und herkömmlicher Berechnung verringern, sodass private Kontrakte praxistaugliche Geschwindigkeiten erreichen.

Kompatibilität: Ein Hauptziel von FHE-VM-Designs ist es, mit bestehenden Entwicklungs-Workflows kompatibel zu bleiben. Die fhEVM-Implementierungen von Cypher und Zama ermöglichen es Entwicklern, Kontrakte in Solidity mit minimalen Änderungen zu schreiben – unter Verwendung einer Bibliothek zur Deklaration verschlüsselter Typen und Operationen. Der Rest der Ethereum-Toolchain (Remix, Hardhat usw.) kann weiterhin verwendet werden, da die zugrunde liegenden Modifikationen hauptsächlich auf Client-/Knotenebene stattfinden. Dies senkt die Eintrittsbarriere: Entwickler müssen keine Kryptografie-Experten sein, um einen vertraulichen Smart Contract zu schreiben. Beispielsweise kann eine einfache Addition zweier Zahlen als euint32 c = a + b; geschrieben werden, und die FHEVM übernimmt die verschlüsselungsspezifischen Details im Hintergrund. Die Kontrakte können sogar mit normalen Kontrakten interagieren – z. B. könnte ein verschlüsselter Kontrakt ein entschlüsseltes Ergebnis an einen Standardkontrakt ausgeben, was eine Mischung aus privaten und öffentlichen Teilen in einem Ökosystem ermöglicht.

Aktuelle FHE-VM-Projekte: Mehrere Projekte leisten Pionierarbeit in diesem Bereich. Zama (ein in Paris ansässiges FHE-Startup) entwickelte das grundlegende FHEVM-Konzept und die Bibliotheken (TFHE-rs und eine fhevm-solidity-Bibliothek). Sie beabsichtigen nicht, eine eigene Chain zu starten, sondern stellen anderen die Infrastruktur zur Verfügung. Inco ist eine L1-Blockchain (aufgebaut auf dem Cosmos SDK mit Evmos), die Zamas FHEVM integriert hat, um eine modulare vertrauliche Chain zu schaffen. Ihre Testnets (genannt Gentry und Paillier) demonstrieren verschlüsselte ERC-20-Transfers und andere private DeFi-Primitive. Fhenix ist ein Ethereum Layer-2 Optimistic Rollup, das FHE für die Privatsphäre nutzt. Man entschied sich für einen optimistischen (Fraud-Proof) Ansatz anstelle eines ZK-Rollups aufgrund der hohen Kosten, die FHE und ZK zusammen für jeden Block verursachen würden. Fhenix verwendet dieselbe TFHE-rs-Bibliothek (mit einigen Modifikationen) und führt ein Threshold Service Network ein, um Entschlüsselungen dezentral zu handhaben. Es gibt auch unabhängige Teams wie Fhenix (jetzt umbenannt) und Startups, die MPC + FHE-Hybride erforschen. Darüber hinaus baut Cypher (von Z1 Labs) ein Layer-3-Netzwerk mit Fokus auf KI und Privatsphäre auf, das eine fhEVM mit Funktionen wie Secret Stores und Unterstützung für Federated Learning nutzt. Das Ökosystem ist noch jung, wächst aber rasant, angetrieben durch signifikante Finanzierungen – so wurde Zama bis 2025 mit über 130 Millionen US-Dollar eingeworbenem Kapital zu einem „Unicorn“, um die FHE-Technologie voranzutreiben.

Zusammenfassend lässt sich sagen, dass eine FHE-VM privatsphärenschützende Smart Contracts ermöglicht, indem sie die gesamte Logik auf verschlüsselten Daten On-Chain ausführt. Dieses Paradigma gewährleistet maximale Vertraulichkeit – nichts Sensibles wird jemals in Transaktionen oder Zuständen offengelegt –, während der bestehende Blockchain-Konsens für die Integrität genutzt wird. Die Kosten dafür sind eine erhöhte Rechenlast für Validatoren und Komplexität bei der Schlüsselverwaltung und der Integration von Beweisen. Als Nächstes untersuchen wir ein alternatives Paradigma, das die Berechnung vollständig Off-Chain auslagert und die Chain nur zur Verifizierung nutzt: den Zero-Knowledge-Coprozessor.

Zero-Knowledge-Coprozessoren (ZK-Coprocessors)​

Ein ZK-Coprozessor ist ein neues Blockchain-Architekturmuster, bei dem aufwendige Berechnungen Off-Chain durchgeführt werden und ein prägnanter (succinct) Zero-Knowledge-Proof ihrer Korrektheit On-Chain verifiziert wird. Dies ermöglicht es Smart Contracts, eine weitaus größere Rechenleistung und Datenmenge zu nutzen, als eine On-Chain-Ausführung zulassen würde, ohne dabei die Vertrauenslosigkeit (Trustlessness) zu opfern. Der Begriff Coprozessor wird in Analogie zu Hardware-Coprozessoren verwendet (wie ein Mathematik-Coprozessor oder eine GPU), die spezialisierte Aufgaben für eine CPU übernehmen. Hier delegiert die „CPU“ der Blockchain (die native VM wie die EVM) bestimmte Aufgaben an ein Zero-Knowledge-Proof-System, das als kryptografischer Coprozessor fungiert. Der ZK-Coprozessor liefert ein Ergebnis und einen Beweis dafür zurück, dass das Ergebnis korrekt berechnet wurde, den der On-Chain-Contract verifizieren und anschließend verwenden kann.

Architektur und Workflow​

In einem typischen Setup identifiziert ein dApp-Entwickler Teile seiner Anwendungslogik, die für eine On-Chain-Ausführung zu teuer oder zu komplex sind (z. B. umfangreiche Berechnungen über historische Daten, schwere Algorithmen, ML-Modell-Inferenz usw.). Er implementiert diese Teile als ein Off-Chain-Programm (in einer Hochsprache oder einer Schaltungs-DSL), das einen Zero-Knowledge-Proof seiner Ausführung erstellen kann. Die On-Chain-Komponente ist ein Verifier-Smart-Contract, der Beweise prüft und die Ergebnisse für den Rest des Systems verfügbar macht. Der Ablauf lässt sich wie folgt zusammenfassen:

1. Anfrage (Request) – Der On-Chain-Contract löst eine Anfrage für eine bestimmte Berechnung aus, die Off-Chain durchgeführt werden soll. Dies kann durch eine Benutzertransaktion oder durch den Aufruf der Schnittstelle des ZK-Coprozessors durch einen Contract initiiert werden. Beispielsweise könnte ein DeFi-Contract „proveInterestRate(currentState)“ aufrufen oder ein Benutzer fragt „queryHistoricalData(query)“ ab.
2. Off-Chain-Ausführung & Beweiserstellung (Off-Chain Execution & Proving) – Ein Off-Chain-Dienst (der je nach Design ein dezentrales Netzwerk von Provern oder ein vertrauenswürdiger Dienst sein kann) nimmt die Anfrage auf. Er sammelt alle erforderlichen Daten (On-Chain-Status, Off-Chain-Inputs usw.) und führt die Berechnung in einer speziellen Zero-Knowledge Virtual Machine (ZKVM) oder Schaltung (Circuit) aus. Während der Ausführung wird ein Proof-Trace generiert. Am Ende erstellt der Dienst einen prägnanten Beweis (z. B. einen SNARK oder STARK), der bescheinigt, dass „die Berechnung der Funktion F mit der Eingabe X das Ergebnis Y liefert“, und optional die Datenintegrität bestätigt (mehr dazu unten).
3. On-Chain-Verifizierung (On-Chain Verification) – Der Beweis und das Ergebnis werden an die Blockchain zurückgegeben (oft über eine Callback-Funktion). Der Verifier-Contract prüft die Gültigkeit des Beweises mithilfe effizienter kryptografischer Verifizierung (Pairing-Checks usw.). Wenn er gültig ist, kann der Contract dem Output Y als korrekt vertrauen. Das Ergebnis kann im Status gespeichert, als Event ausgegeben oder in die weitere Contract-Logik eingespeist werden. Wenn der Beweis ungültig ist oder nicht innerhalb einer bestimmten Zeit erbracht wird, kann die Anfrage als fehlgeschlagen betrachtet werden (und es greift potenziell eine Fallback- oder Timeout-Logik).

Abbildung 1: Architektur eines ZK-Coprozessors (Beispiel RISC Zero Bonsai). Off-Chain läuft ein Programm auf einer ZKVM mit Eingaben aus dem Smart-Contract-Aufruf. Ein Ausführungsbeweis wird über einen Relay-Contract On-Chain zurückgegeben, der einen Callback mit den verifizierten Ergebnissen aufruft.

Entscheidend ist, dass die On-Chain-Gas-Kosten für die Verifizierung konstant sind (oder nur sehr langsam wachsen), unabhängig davon, wie komplex die Off-Chain-Berechnung war. Die Verifizierung eines prägnanten Beweises kann in der Größenordnung von einigen hunderttausend Gas kosten (ein Bruchteil eines Ethereum-Blocks), aber dieser Beweis könnte Millionen von Off-Chain durchgeführten Rechenschritten repräsentieren. Wie ein Entwickler einmal scherzte: „Möchten Sie eine digitale Signatur beweisen? ~$15. Möchten Sie eine Million Signaturen beweisen? Ebenfalls ~$15.“. Diese Skalierbarkeit ist ein riesiger Gewinn: dApps können komplexe Funktionalitäten (Big-Data-Analysen, aufwendige Finanzmodelle usw.) anbieten, ohne die Blockchain zu verstopfen.

Die Hauptkomponenten eines ZK-Coprozessor-Systems sind:

• Umgebung zur Beweiserstellung (Proof Generation Environment): Dies kann eine Allzweck-ZKVM (die beliebige Programme ausführen kann) oder maßgeschneiderte Schaltungen sein, die auf spezifische Berechnungen zugeschnitten sind. Die Ansätze variieren:

  • Einige Projekte verwenden handgefertigte Schaltungen (handcrafted circuits) für jede unterstützte Abfrage oder Funktion (um die Effizienz für diese Funktion zu maximieren).
  • Andere bieten eine domänenspezifische Sprache (DSL) oder eine eingebettete DSL an, die Entwickler verwenden, um ihre Off-Chain-Logik zu schreiben, welche dann in Schaltungen kompiliert wird (ein Kompromiss zwischen Benutzerfreundlichkeit und Leistung).
  • Der flexibelste Ansatz ist eine ZKVM: eine virtuelle Maschine (oft basierend auf RISC-Architekturen), auf der Programme in Standardsprachen (Rust, C usw.) geschrieben und automatisch bewiesen werden können. Dies opfert Leistung (die Simulation einer CPU in einer Schaltung verursacht Overhead) für eine maximale Entwicklererfahrung.

• Datenzugriff und Integrität (Data Access and Integrity): Eine besondere Herausforderung besteht darin, die Off-Chain-Berechnung mit den richtigen Daten zu versorgen, insbesondere wenn diese Daten auf der Blockchain liegen (vergangene Blöcke, Contract-Zustände usw.). Eine naive Lösung wäre, dass der Prover von einem Archivknoten liest und ihm vertraut – aber das führt Vertrauensannahmen ein. ZK-Coprozessoren beweisen stattdessen in der Regel, dass alle verwendeten On-Chain-Daten tatsächlich authentisch waren, indem sie eine Verknüpfung zu Merkle-Beweisen oder State-Commitments herstellen. Zum Beispiel könnte das Abfrageprogramm eine Blocknummer und einen Merkle-Beweis eines Speicherplatzes oder einer Transaktion entgegennehmen, und die Schaltung verifiziert diesen Beweis gegen einen bekannten Block-Header-Hash. Es existieren drei Muster:

  1. Inline-Daten: Die benötigten Daten werden On-Chain bereitgestellt (als Eingabe für den Verifier), damit sie direkt geprüft werden können. Dies ist bei großen Datenmengen sehr kostspielig und untergräbt den eigentlichen Zweck.
  2. Vertrauen in ein Oracle: Ein Oracle-Dienst liefert die Daten an den Beweis und bürgt dafür. Dies ist einfacher, führt aber wieder Vertrauen in einen Dritten ein.
  3. Datenaufnahme via ZK beweisen: Beweise für die Aufnahme von Daten in die Historie der Chain werden direkt in die Zero-Knowledge-Schaltung integriert. Dies nutzt die Tatsache aus, dass jeder Ethereum-Block-Header den gesamten vorherigen Zustand (über die State Root) und die Transaktionshistorie festschreibt. Durch die Verifizierung von Merkle-Patricia-Beweisen der Daten innerhalb der Schaltung garantiert der resultierende Beweis dem Contract, dass „diese Berechnung echte Blockchain-Daten aus Block N verwendet hat“, ohne dass zusätzliches Vertrauen erforderlich ist.

  Der dritte Ansatz ist der vertrauensloseste und wird von fortschrittlichen ZK-Coprozessoren wie Axiom und Xpansion verwendet (er erhöht zwar die Beweiskosten, ist aber aus Sicherheitsgründen vorzuziehen). Das System von Axiom beispielsweise modelliert die Blockstruktur, den State Trie und den Transaction Trie von Ethereum innerhalb seiner Schaltungen, sodass es Aussagen beweisen kann wie „das Konto X hatte in Block N den Kontostand Y“ oder „eine Transaktion mit bestimmten Eigenschaften fand in Block N statt“. Es nutzt die Tatsache aus, dass man ausgehend von einem aktuellen vertrauenswürdigen Block-Hash rekursiv die Aufnahme historischer Daten beweisen kann, ohne einer externen Partei vertrauen zu müssen.

• Verifier-Contract: Dieser On-Chain-Contract enthält den Verifizierungsschlüssel und die Logik zum Akzeptieren oder Ablehnen von Beweisen. Bei SNARKs wie Groth16 oder PLONK führt der Verifier einige elliptische Kurven-Pairings aus; bei STARKs führt er Hash-Berechnungen durch. Leistungsoptimierungen wie Aggregation und Rekursion können die On-Chain-Last minimieren. Beispielsweise verwendet Bonsai von RISC Zero einen STARK-zu-SNARK-Wrapper: Es führt Off-Chain eine STARK-basierte VM für hohe Geschwindigkeit aus, generiert dann aber einen kleinen SNARK-Beweis, der die Gültigkeit des STARK bestätigt. Dies schrumpft die Beweisgröße von hunderten Kilobytes auf einige hundert Bytes, was die On-Chain-Verifizierung machbar und günstig macht. Der Solidity-Verifier prüft dann nur noch den SNARK (was eine Operation mit konstanter Zeit ist).

In Bezug auf das Deployment können ZK-Coprozessoren als Layer-2-ähnliche Netzwerke oder als reine Off-Chain-Dienste fungieren. Einige, wie Axiom, begannen als spezialisierter Dienst für Ethereum (mit Unterstützung von Paradigm), bei dem Entwickler Abfragen an das Prover-Netzwerk von Axiom senden und Beweise On-Chain erhalten. Der Slogan von Axiom lautete, Ethereum-Contracts „vertrauenslosen Zugriff auf alle On-Chain-Daten und beliebig ausdrucksstarke Berechnungen darüber“ zu ermöglichen. Es fungiert effektiv als Abfrage-Oracle, bei dem die Antworten durch ZKPs anstatt durch Vertrauen verifiziert werden. Andere, wie Bonsai von RISC Zero, bieten eine offenere Plattform an: Jeder Entwickler kann ein Programm hochladen (kompiliert für eine RISC-V-kompatible ZKVM) und den Beweisdienst von Bonsai über einen Relay-Contract nutzen. Das Relay-Muster, wie in Abbildung 1 dargestellt, umfasst einen Contract, der Anfragen und Antworten vermittelt: Der dApp-Contract ruft das Relay auf, um einen Beweis anzufordern, der Off-Chain-Dienst hört dies ab (z. B. über ein Event oder einen direkten Aufruf), berechnet den Beweis und das Relay ruft anschließend eine Callback-Funktion auf dem dApp-Contract mit dem Ergebnis und dem Beweis auf. Dieses asynchrone Modell ist notwendig, da die Beweiserstellung je nach Komplexität Sekunden bis Minuten dauern kann. Dies führt eine Latenz ein (und die Annahme der Lebendigkeit, dass der Prover antwortet), während FHE-VM-Berechnungen synchron innerhalb eines Blocks stattfinden. Die Gestaltung der Anwendung für diesen asynchronen Workflow (ähnlich wie bei Oracle-Antworten) ist Teil der Nutzung eines ZK-Coprozessors.

Bekannte ZK-Coprozessor-Projekte​

• Axiom: Axiom ist ein auf Ethereum zugeschnittener ZK-Coprozessor, der sich ursprünglich auf den Beweis von Abfragen historischer On-Chain-Daten konzentrierte. Er verwendet das Halo2-Proof-Framework (ein Plonk-ähnlicher SNARK), um Beweise zu erstellen, die die kryptografischen Strukturen von Ethereum einbeziehen. Im System von Axiom kann ein Entwickler Dinge abfragen wie „wie war der Zustand von Contract X in Block N?“ oder eine Berechnung über alle Transaktionen in einem Bereich durchführen. Unter der Haube mussten die Schaltungen von Axiom die State/Trie-Logik von Ethereum implementieren und sogar Operationen auf elliptischen Kurven sowie SNARK-Verifizierungen innerhalb der Schaltung durchführen, um Rekursion zu unterstützen. Trail of Bits stellte in einem Audit die Komplexität der Halo2-Schaltungen von Axiom fest, die ganze Blöcke und Zustände modellieren. Nach dem Audit generalisierte Axiom seine Technologie zu einer OpenVM, die es ermöglicht, beliebigen Rust-Code mit derselben Halo2-basierten Infrastruktur zu beweisen. (Dies spiegelt den Trend wider, von domänenspezifischen Schaltungen zu einem allgemeineren ZKVM-Ansatz überzugehen.) Das Axiom-Team demonstrierte ZK-Abfragen, die Ethereum nativ nicht durchführen kann, und ermöglichte so einen zustandslosen Zugriff auf alle historischen Daten mit kryptografischer Integrität. Sie betonten auch die Sicherheit, indem sie Bugs in unzureichend eingeschränkten Schaltungen (under-constrained circuits) fanden und behoben und die Korrektheit (Soundness) sicherstellten. Während das ursprüngliche Produkt von Axiom während ihrer Neuausrichtung eingestellt wurde, bleibt ihr Ansatz ein Meilenstein für ZK-Coprozessoren.

• RISC Zero Bonsai: RISC Zero ist eine ZKVM, die auf der RISC-V-Architektur basiert. Ihre zkVM kann beliebige Programme ausführen (geschrieben in Rust, C++ und anderen Sprachen, die für RISC-V kompiliert wurden) und einen STARK-Beweis der Ausführung erstellen. Bonsai ist der Cloud-Dienst von RISC Zero, der diese Beweiserstellung auf Abfrage bereitstellt und als Coprozessor für Smart Contracts fungiert. Um ihn zu nutzen, schreibt ein Entwickler ein Programm (z. B. eine Funktion, die komplexe Mathematik ausführt oder eine Off-Chain-API-Antwort verifiziert), lädt es in den Bonsai-Dienst hoch und stellt einen entsprechenden Verifier-Contract bereit. Wenn der Contract diese Berechnung benötigt, ruft er das Bonsai-Relay auf, welches die Beweiserstellung auslöst und das Ergebnis per Callback zurückgibt. Ein demonstriertes Anwendungsbeispiel war die Off-Chain-Governance-Berechnung: RISC Zero zeigte eine DAO, die Bonsai nutzte, um Stimmen auszuzählen und komplexe Abstimmungsmetriken Off-Chain zu berechnen und dann einen Beweis zu posten, sodass der On-Chain-Governor-Contract dem Ergebnis mit minimalen Gas-Kosten vertrauen konnte. Die Technologie von RISC Zero betont, dass Entwickler vertraute Programmierparadigmen nutzen können – zum Beispiel das Schreiben einer Rust-Funktion zur Berechnung von Werten –, während die schwere Arbeit der Schaltungserstellung von der zkVM erledigt wird. Da Beweise jedoch groß sein können, implementierten sie, wie bereits erwähnt, eine SNARK-Kompression für die On-Chain-Verifizierung. Im August 2023 verifizierten sie erfolgreich RISC-Zero-Beweise im Sepolia-Testnet von Ethereum, was etwa 300k Gas pro Beweis kostete. Dies öffnet die Tür für Ethereum-dApps, Bonsai schon heute als Skalierungs- und Datenschutzlösung zu nutzen. (Bonsai befindet sich noch in der Alpha-Phase, ist nicht produktionsreif und verwendet ein temporäres SNARK-Setup ohne Zeremonie.)

• Andere: Es gibt zahlreiche weitere Akteure und Forschungsinitiativen. Expansion/Xpansion verwendet einen Ansatz mit eingebetteter DSL, bei dem Entwickler Abfragen über On-Chain-Daten in einer spezialisierten Sprache schreiben können und das System die Beweiserstellung intern handhabt. Cairo von StarkWare und die zkEVM von Polygon sind eher allgemeine ZK-Rollup-VMs, aber ihre Technologie könnte für coprozessorähnliche Zwecke umfunktioniert werden, indem Beweise innerhalb von L1-Contracts verifiziert werden. Wir sehen auch Projekte im Bereich ZKML (ZK Machine Learning), die effektiv als Coprozessoren fungieren, um ML-Modell-Inferenzen oder Trainingsergebnisse On-Chain zu verifizieren. Ein ZKML-Setup kann beispielsweise beweisen, dass „eine neuronale Netzwerkinferenz auf privaten Eingaben die Klassifizierung X ergeben hat“, ohne die Eingaben offenzulegen oder die Berechnung On-Chain durchzuführen. Dies sind Spezialfälle des Coprozessor-Konzepts angewendet auf KI.

Vertrauensannahmen: ZK-Coprozessoren verlassen sich auf die Korrektheit (Soundness) der kryptografischen Beweise. Wenn das Beweissystem sicher ist (und jedes Trusted Setup ehrlich durchgeführt wurde), garantiert ein akzeptierter Beweis, dass die Berechnung korrekt war. Es ist kein zusätzliches Vertrauen in den Prover erforderlich – selbst ein bösartiger Prover kann den Verifier nicht von einer falschen Aussage überzeugen. Es gibt jedoch eine Lebendigkeitsannahme (Liveness Assumption): Jemand muss die Off-Chain-Berechnung tatsächlich durchführen und den Beweis erbringen. In der Praxis könnte dies ein dezentrales Netzwerk (mit Anreizen oder Gebühren für die Arbeit) oder ein einzelner Dienstbetreiber sein. Wenn niemand den Beweis liefert, bleibt die On-Chain-Anfrage möglicherweise ungelöst. Ein weiterer subtiler Vertrauensaspekt ist die Datenverfügbarkeit für Off-Chain-Eingaben, die nicht auf der Blockchain liegen. Wenn die Berechnung von privaten oder externen Daten abhängt, kann der Verifier nicht wissen, ob diese Daten ehrlich bereitgestellt wurden, es sei denn, es werden zusätzliche Maßnahmen (wie Data Commitments oder Oracle-Signaturen) ergriffen. Für reine On-Chain-Datenberechnungen gewährleisten die beschriebenen Mechanismen jedoch eine Vertrauenslosigkeit, die der Chain selbst entspricht (Axiom argumentierte, dass ihre Beweise für historische Abfragen eine „kryptografisch zur Sicherheit von Ethereum äquivalente“ Sicherheit bieten).

Datenschutz (Privacy): Zero-Knowledge-Proofs unterstützen von Natur aus den Datenschutz – der Prover kann Eingaben verborgen halten, während er Aussagen darüber beweist. Im Kontext eines Coprozessors bedeutet dies, dass ein Beweis es einem Contract ermöglichen kann, ein Ergebnis zu verwenden, das aus privaten Daten abgeleitet wurde. Ein Beweis könnte beispielsweise zeigen: „Kredit-Score des Nutzers > 700, daher Kredit genehmigen“, ohne den tatsächlichen Score oder die Rohdaten offenzulegen. Bei Axiom lag der Fokus eher auf öffentlich bekannten Daten (Blockchain-Historie), daher stand Datenschutz dort nicht im Mittelpunkt. Die zkVM von RISC Zero könnte jedoch verwendet werden, um Behauptungen über geheime Daten zu beweisen, die von einem Benutzer bereitgestellt werden: Die Daten bleiben Off-Chain und nur das benötigte Ergebnis gelangt On-Chain. Es ist anzumerken, dass ein ZK-Proof im Gegensatz zu FHE normalerweise keine dauerhafte Vertraulichkeit des Zustands bietet – es ist ein einmaliger Beweis. Wenn ein Workflow die Aufrechterhaltung eines geheimen Zustands über mehrere Transaktionen hinweg erfordert, könnte man dies so aufbauen, dass der Contract ein Commitment zum Zustand speichert und jeder Beweis einen gültigen Zustandsübergang vom alten zum neuen Commitment zeigt, wobei die Geheimnisse verborgen bleiben. Dies ist im Wesentlichen die Funktionsweise von ZK-Rollups für private Transaktionen (wie Aztec oder Zcash). ZK-Coprozessoren können also vollständig private Zustandsmaschinen ermöglichen, aber die Implementierung ist nicht trivial; oft werden sie für einmalige Berechnungen verwendet, bei denen entweder der Input oder der Output (oder beides) nach Bedarf privat sein können.

Entwicklererfahrung: Die Nutzung eines ZK-Coprozessors erfordert in der Regel das Erlernen neuer Werkzeuge. Das Schreiben maßgeschneiderter Schaltungen (Option (1) oben) ist sehr komplex und wird meist nur für eng begrenzte Zwecke getan. Höherwertige Optionen wie DSLs oder ZKVMs erleichtern das Leben, verursachen aber dennoch Overhead: Der Entwickler muss Off-Chain-Code schreiben und bereitstellen sowie die Interaktion verwalten. Im Gegensatz zur FHE-VM, bei der die Verschlüsselung größtenteils im Hintergrund abläuft und der Entwickler normalen Smart-Contract-Code schreibt, muss der Entwickler hier seine Logik aufteilen und für den Off-Chain-Teil möglicherweise in einer anderen Sprache (Rust etc.) schreiben. Initiativen wie die DSLs Noir, Leo, Circom oder der Ansatz von RISC Zero verbessern jedoch rasant die Zugänglichkeit. RISC Zero bietet beispielsweise Templates und eine Foundry-Integration an, sodass ein Entwickler seinen Off-Chain-Code lokal simulieren (auf Korrektheit prüfen) und ihn dann nahtlos über den Bonsai-Callback in Solidity-Tests einbinden kann. Mit der Zeit ist mit Entwicklungs-Frameworks zu rechnen, die abstrahieren, ob ein Logikbaustein per ZK-Proof oder On-Chain ausgeführt wird – der Compiler oder die Tools könnten dies basierend auf den Kosten entscheiden.

FHE-VM vs. ZK-Coprozessor: Vergleich​

Sowohl FHE-VMs als auch ZK-Coprozessoren ermöglichen eine Form von „Berechnung auf privaten Daten mit On-Chain-Garantie“, unterscheiden sich jedoch grundlegend in ihrer Architektur. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen:

Aspekt	FHE-VM (Verschlüsselte On-Chain-Ausführung)	ZK-Coprozessor (Off-Chain-Beweisführung)
Wo die Berechnung stattfindet	Direkt On-Chain (alle Knoten führen homomorphe Operationen auf Chiffretexten aus).	Off-Chain (ein Prover oder ein Netzwerk führt das Programm aus; nur ein Beweis wird On-Chain verifiziert).
Datenvertraulichkeit	Vollständige Verschlüsselung: Daten bleiben On-Chain jederzeit verschlüsselt; Validatoren sehen niemals den Klartext. Nur Inhaber von Entschlüsselungsschlüsseln können Ergebnisse entschlüsseln.	Zero-Knowledge: Die privaten Eingaben des Provers werden On-Chain niemals offengelegt; der Beweis enthüllt keine Geheimnisse außer dem, was in den öffentlichen Ausgaben steht. Alle Daten, die sich auf den On-Chain-Status auswirken müssen, müssen jedoch im Output oder Commitment kodiert sein. Geheimnisse bleiben standardmäßig Off-Chain.
Vertrauensmodell	Vertrauen in Konsens-Ausführung und Kryptografie: Wenn die Mehrheit der Validatoren dem Protokoll folgt, ist die verschlüsselte Ausführung deterministisch und korrekt. Kein externes Vertrauen für die Korrektheit der Berechnung nötig (alle Knoten berechnen sie neu). Für den Datenschutz muss der Sicherheit des FHE-Schemas vertraut werden (meist basierend auf Lattice-Hardness). In einigen Designs auch Vertrauen darauf, dass keine Kollusion von ausreichend Validatoren stattfindet, um Threshold-Keys zu missbrauchen.	Vertrauen in die Sicherheit des Beweissystems (Soundness von SNARK/STARK). Wenn der Beweis verifiziert wird, ist das Ergebnis mit kryptografischer Sicherheit korrekt. Off-Chain-Prover können die Mathematik nicht austricksen. Es gibt eine Lebendigkeitsannahme für Prover, die Arbeit tatsächlich zu erledigen. Bei Verwendung eines Trusted Setups (z. B. SNARK SRS) muss darauf vertraut werden, dass dieses ehrlich erstellt wurde, oder es müssen transparente/setup-lose Systeme verwendet werden.
On-Chain-Kosten und Skalierbarkeit	Hohe Kosten pro Transaktion: Homomorphe Operationen sind extrem rechenintensiv und jeder Knoten muss sie ausführen. Die Gas-Kosten sind hoch (z. B. 100k+ Gas für eine einfache 8-Bit-Addition). Komplexe Contracts sind dadurch begrenzt, was jeder Validator in einem Block berechnen kann. Der Durchsatz ist viel geringer als bei normalen Smart Contracts, sofern keine spezialisierte Hardware eingesetzt wird. Skalierbarkeit wird durch schnellere Kryptografie und Hardwarebeschleunigung verbessert, aber grundsätzlich erhöht jede Operation die Last der Chain.	Geringe Verifizierungskosten: Das Verifizieren eines prägnanten Beweises ist effizient und hat eine konstante Größe, sodass das On-Chain-Gas moderat ist (einige hunderttausend Gas für Berechnungen beliebiger Größe). Dies entkoppelt die Komplexität von On-Chain-Ressourcenlimits – große Berechnungen verursachen keine zusätzlichen On-Chain-Kosten. Somit skaliert es in Bezug auf die On-Chain-Last. Off-Chain kann die Beweiszeit erheblich sein (Minuten oder mehr für riesige Aufgaben) und leistungsstarke Maschinen erfordern, aber dies verlangsamt die Blockchain nicht direkt. Der Gesamtdurchsatz kann hoch sein, solange Beweise rechtzeitig generiert werden können (potenzielle parallele Prover-Netzwerke).
Latenz	Ergebnisse sind sofort in derselben Transaktion/demselben Block verfügbar, da die Berechnung während der Ausführung erfolgt. Keine zusätzlichen Round-Trips – synchroner Betrieb. Längere Blockverarbeitungszeiten könnten jedoch die Blockchain-Latenz erhöhen, wenn FHE-Operationen langsam sind.	Von Natur aus asynchron. Erfordert typischerweise eine Transaktion zur Anfrage und eine spätere Transaktion (oder einen Callback), um den Beweis/das Ergebnis zu liefern. Dies führt zu Verzögerungen (je nach Beweiskomplexität und Hardware möglicherweise Sekunden bis Stunden). Nicht geeignet für sofortige Finalität einer einzelnen Transaktion – eher wie ein asynchrones Job-Modell.
Datenschutzgarantien	Stark: Alles (Eingaben, Ausgaben, Zwischenzustände) kann On-Chain verschlüsselt bleiben. Man kann einen langlebigen verschlüsselten Zustand haben, den mehrere Transaktionen aktualisieren, ohne ihn jemals offenzulegen. Nur autorisierte Entschlüsselungsaktionen (falls vorhanden) geben Ergebnisse preis, und diese können über Schlüssel/ACLs gesteuert werden. Seitenkanal-Aspekte wie Gasverbrauch oder Event-Logs müssen jedoch so verwaltet werden, dass sie keine Muster verraten (fhEVM-Designs streben eine datenunabhängige Ausführung mit konstantem Gas für Operationen an, um Leaks zu vermeiden).	Selektiv: Der Beweis offenbart alles, was in den öffentlichen Ausgaben steht oder zur Verifizierung notwendig ist (z. B. ein Commitment zum Anfangszustand). Designer können sicherstellen, dass nur das beabsichtigte Ergebnis preisgegeben wird und alle anderen Eingaben Zero-Knowledge-verborgen bleiben. Aber im Gegensatz zu FHE speichert die Blockchain normalerweise nicht den verborgenen Zustand – Datenschutz wird dadurch erreicht, dass Daten vollständig Off-Chain gehalten werden. Wenn ein persistenter privater Zustand benötigt wird, kann der Contract ein kryptografisches Commitment dazu speichern (Zustandsaktualisierungen offenbaren dann jedes Mal ein neues Commitment). Der Datenschutz ist darauf begrenzt, was man zu beweisen wählt; man hat die Flexibilität, z. B. zu beweisen, dass ein Schwellenwert erreicht wurde, ohne exakte Werte offenzulegen.

| Durchsetzung der Integrität | Konstruktionsbedingt berechnen alle Validatoren den nächsten Zustand homomorph neu. Wenn also ein bösartiger Akteur ein falsches Chiffretext-Ergebnis liefert, werden andere eine Diskrepanz feststellen – der Konsens schlägt fehl, sofern nicht alle das gleiche Ergebnis erhalten. Somit wird die Integrität durch redundante Ausführung erzwungen (wie bei einer normalen Blockchain, nur auf verschlüsselten Daten). Zusätzliche ZK-Proofs werden häufig verwendet, um Geschäftsregeln durchzusetzen (z. B. dass ein Benutzer keine Einschränkung verletzt hat), da Validatoren Klartextbedingungen nicht direkt prüfen können. | Die Integrität wird durch den Verifier-Contract erzwungen, der den ZK-Proof prüft. Solange der Proof verifiziert wird, ist garantiert, dass das Ergebnis mit einer gültigen Ausführung des Off-Chain-Programms konsistent ist. Für die Korrektheit ist keine Honest-Majority-Annahme erforderlich – selbst ein einziger ehrlicher Verifier (der Contract-Code selbst) genügt. Der On-Chain-Contract wird einfach jeden falschen oder fehlenden Proof ablehnen (ähnlich wie er eine ungültige Signatur ablehnen würde). Eine Überlegung: Wenn der Prover abbricht oder sich verzögert, benötigt der Contract unter Umständen eine Fallback-Logik (oder Benutzer müssen es später erneut versuchen), aber er wird keine falschen Ergebnisse akzeptieren. | | Entwicklererfahrung | Vorteile: Es können weitgehend vertraute Smart-Contract-Sprachen (Solidity usw.) mit Erweiterungen verwendet werden. Die Vertraulichkeit wird von der Plattform verwaltet – Entwickler kümmern sich hauptsächlich darum, was verschlüsselt werden soll und wer die Schlüssel hält. Die Komposition von verschlüsselten und normalen Verträgen ist möglich, wodurch die Komponierbarkeit von DeFi erhalten bleibt (nur mit verschlüsselten Variablen). Nachteile: FHE-Einschränkungen müssen verstanden werden – z. B. keine direkten bedingten Sprünge auf geheimen Daten ohne spezielle Handhabung, begrenzte Schaltkreistiefe (obwohl Bootstrapping in TFHE beliebige Berechnungslängen auf Kosten der Zeit ermöglicht). Das Debuggen verschlüsselter Logik kann schwierig sein, da Laufzeitwerte ohne den Schlüssel nicht einfach eingesehen werden können. Zudem erhöhen Schlüsselmanagement und Berechtigungen die Komplexität des Contract-Designs. | Vorteile: Potenziell kann jede Programmiersprache für den Off-Chain-Teil verwendet werden (insbesondere mit einer zkVM). Bestehende Bibliotheken/Code können im Off-Chain-Programm genutzt werden (mit Vorbehalten hinsichtlich der ZK-Kompatibilität). Bei Verwendung einer allgemeinen zkVM benötigt der Entwickler keine speziellen Kryptographie-Kenntnisse – er schreibt normalen Code und erhält einen Proof. Zudem können für rechenintensive Aufgaben Bibliotheken (z. B. Machine-Learning-Code) verwendet werden, die niemals on-chain laufen würden. Nachteile: Entwickler müssen die Off-Chain-Infrastruktur orchestrieren oder einen Proving-Service nutzen. Die Handhabung asynchroner Workflows und deren Integration in die On-Chain-Logik erfordert mehr Designaufwand (z. B. Speichern eines schwebenden Zustands, Warten auf Callback). Das Schreiben effizienter Schaltkreise oder zkVM-Code erfordert möglicherweise das Erlernen neuer Einschränkungen (z. B. keine Fließkommazahlen, Verwendung von Festkommazahlen oder speziellen Primitiven; Vermeidung starker Verzweigungen, die die Proving-Zeit aufblähen; Optimierung der Constraint-Anzahl). Zudem besteht die Last, mit Proof-Fehlern, Timeouts usw. umzugehen, was in regulärem Solidity keine Rolle spielt. Das Ökosystem der Tools wächst, aber es ist für viele ein neues Paradigma. |

Beide Ansätze werden aktiv verbessert, und wir sehen sogar eine Konvergenz: Wie erwähnt, werden ZKPs innerhalb von FHE-VMs für bestimmte Prüfungen verwendet, und umgekehrt schlagen einige Forscher vor, FHE zu verwenden, um Prover-Inputs in ZK privat zu halten (damit ein Cloud-Prover Ihre geheimen Daten nicht sieht). Es ist denkbar, dass zukünftige Systeme beide kombinieren – z. B. FHE off-chain ausführen und dann die Korrektheit dessen on-chain beweisen, oder FHE on-chain nutzen, aber ZK-Proofs für Light-Clients verwenden, um zu zeigen, dass die verschlüsselten Operationen korrekt durchgeführt wurden. Jede Technik hat ihre Stärken: FHE-VMs bieten kontinuierliche Privatsphäre und Echtzeit-Interaktion auf Kosten hoher Rechenleistung, während ZK-Coprozessoren Skalierbarkeit und Flexibilität auf Kosten von Latenz und Komplexität bieten.

Anwendungsfälle und Auswirkungen​

Der Einzug programmierbarer Privatsphäre eröffnet eine Fülle neuer Blockchain-Anwendungen über verschiedene Branchen hinweg. Im Folgenden untersuchen wir, wie FHE-VMs und ZK-Coprozessoren (oder Hybride) verschiedene Bereiche durch privatsphäre-schützende Smart Contracts und eine sichere Datenökonomie stärken können.

Vertrauliches DeFi und Finanzwesen​

Im dezentralen Finanzwesen kann Privatsphäre Front-Running mildern, Handelsstrategien schützen und regulatorische Anforderungen erfüllen, ohne auf Transparenz zu verzichten, wo sie benötigt wird. Confidential DeFi könnte es Benutzern ermöglichen, mit Protokollen zu interagieren, ohne ihre Positionen der Welt preiszugeben.

• Private Transaktionen und verborgene Guthaben: Mit FHE können vertrauliche Token-Transfers (verschlüsselte ERC-20-Guthaben und Transaktionen) oder Shielded Pools auf einer Blockchain L1 implementiert werden. Kein Beobachter kann sehen, wie viele Token Sie halten oder transferiert haben, was das Risiko gezielter Angriffe auf Basis von Beständen eliminiert. ZK-Proofs können sicherstellen, dass Guthaben synchron bleiben und kein Double-Spending auftritt (ähnlich wie bei Zcash, aber auf Smart-Contract-Plattformen). Ein Beispiel ist ein vertraulicher AMM (Automated Market Maker), bei dem Poolreserven und Trades on-chain verschlüsselt sind. Arbitrageure oder Front-Runner können den Pool nicht ausnutzen, da sie die Preis-Slippage erst nach Abschluss des Trades beobachten können, was den MEV reduziert. Erst nach einer gewissen Verzögerung oder über einen zugriffsbeschränkten Mechanismus könnten einige Daten für Prüfzwecke offengelegt werden.

• MEV-resitente Auktionen und Handel: Miner und Bots nutzen die Transparenz von Transaktionen aus, um Trades per Front-Running zu manipulieren. Mit Verschlüsselung könnte man einen verschlüsselten Mempool oder Batch-Auktionen einführen, bei denen Aufträge als Chiffretext eingereicht werden. Erst nachdem die Auktion abgeschlossen ist, werden die Trades entschlüsselt. Dieses Konzept, manchmal als Fair Order Flow bezeichnet, kann durch Threshold-Entschlüsselung (mehrere Validatoren entschlüsseln gemeinsam den Batch) oder durch den Nachweis von Auktionsergebnissen via ZK ohne Offenlegung einzelner Gebote erreicht werden. Beispielsweise könnte ein ZK-Coprozessor einen Batch versiegelter Gebote off-chain entgegennehmen, den Auktionspreis berechnen und nur diesen Preis sowie die Gewinner mit Proofs ausgeben. Dies wahrt die Fairness und die Privatsphäre der unterlegenen Gebote.

• Vertrauliche Kreditvergabe und Derivate: Bei der DeFi-Kreditvergabe möchten Benutzer möglicherweise weder die Größe ihrer Kredite noch ihre Sicherheiten preisgeben (da dies die Marktstimmung beeinflussen oder Ausnutzung provozieren kann). Eine FHE-VM kann ein verschlüsseltes Kreditbuch führen, in dem alle Kreditdetails verschlüsselt sind. Die Smart-Contract-Logik kann dennoch Regeln wie Liquidationsbedingungen durchsetzen, indem sie auf verschlüsselten Gesundheitsfaktoren operiert. Wenn die Besicherungsquote eines Kredits unter einen Schwellenwert fällt, kann der Contract (mithilfe von ZK-Proofs) diesen zur Liquidation markieren, ohne jemals exakte Werte preiszugeben – er könnte lediglich ein Klartext-Flag für "Ja/Nein" erzeugen. Ähnlich könnten geheime Derivat- oder Optionspositionen on-chain verwaltet werden, wobei nur aggregierte Risikokennzahlen offengelegt werden. Dies könnte Copy-Trading verhindern und proprietäre Strategien schützen, was die Beteiligung institutioneller Akteure fördert.

• Konforme Privatsphäre: Nicht alle Finanzkontexte erfordern totale Anonymität; manchmal ist eine selektive Offenlegung für die Regulierung erforderlich. Mit diesen Werkzeugen können wir eine regulierte Privatsphäre erreichen: Trades sind beispielsweise für die Öffentlichkeit privat, aber eine regulierte Börse kann bestimmte Eigenschaften entschlüsseln oder Proofs darüber erhalten. Man könnte via ZK beweisen, dass „dieser Trade keine auf der schwarzen Liste stehende Adresse beinhaltete und beide Parteien KYC-verifiziert sind“, ohne Identitäten gegenüber der Chain offenzulegen. Dieses Gleichgewicht könnte Anti-Geldwäsche-Regeln (AML) erfüllen, während Benutzeridentitäten und Positionen für alle anderen vertraulich bleiben. FHE könnte es einem On-Chain-Compliance-Officer-Contract ermöglichen, verschlüsselte Transaktionen nach Risikosignalen zu scannen (mit einem Entschlüsselungsschlüssel, der beispielsweise nur per Gerichtsbeschluss zugänglich ist).

Digitale Identität und persönliche Daten​

Identitätssysteme werden erheblich von On-Chain-Privatsphäre-Technologien profitieren. Derzeit ist es aufgrund von Datenschutzgesetzen und der Zurückhaltung der Nutzer unpraktisch, persönliche Anmeldedaten oder Attribute in ein öffentliches Ledger einzutragen. Mit FHE und ZK kann eine selbstbestimmte Identität (SSI) privatsphäre-schonend realisiert werden:

• Zero-Knowledge Credentials: Mithilfe von ZK-Proofs (die bereits in einigen Identitätsprojekten üblich sind) kann ein Benutzer Aussagen beweisen wie „Ich bin über 18“, „Ich besitze einen gültigen Führerschein“ oder „Mein Einkommen liegt über 50.000 $ (für das Kredit-Scoring)“, ohne weitere persönliche Informationen preiszugeben. ZK-Coprozessoren können dies verbessern, indem sie komplexere Prüfungen off-chain durchführen, z. B. den Nachweis, dass der Kredit-Score eines Benutzers über einem Schwellenwert liegt, indem eine private Kreditdatenbank abgefragt wird (ähnlich wie Axiom), und nur ein Ja/Nein an die Blockchain ausgegeben wird.

• Vertrauliches KYC in DeFi: Stellen Sie sich ein DeFi-Protokoll vor, das gesetzlich verpflichtet ist, das KYC seiner Nutzer sicherzustellen. Mit einer FHE-VM können die Anmeldedaten eines Benutzers verschlüsselt on-chain gespeichert (oder über eine DID referenziert) werden, und ein Smart Contract kann eine FHE-Berechnung durchführen, um zu verifizieren, dass die KYC-Informationen den Anforderungen entsprechen. Beispielsweise könnte ein Contract homomorph prüfen, ob Name und Sozialversicherungsnummer in einem verschlüsselten Benutzerprofil mit einer Liste sanktionierter Personen (ebenfalls verschlüsselt) übereinstimmen oder ob das Land des Benutzers nicht eingeschränkt ist. Der Contract würde nur ein verschlüsseltes „Bestanden/Nicht bestanden“ erhalten, das von den Netzwerk-Validatoren per Threshold-Entschlüsselung in ein Boolesches Flag umgewandelt werden kann. Nur die Tatsache, ob der Benutzer zugelassen ist oder nicht, wird offengelegt, wodurch die Vertraulichkeit personenbezogener Daten gewahrt bleibt und die DSGVO-Prinzipien eingehalten werden. Diese selektive Offenlegung gewährleistet Compliance und Privatsphäre.

• Attributbasierter Zugriff und selektive Offenlegung: Benutzer könnten eine Reihe von verifizierbaren Credentials (Alter, Staatsbürgerschaft, Fähigkeiten usw.) als verschlüsselte Attribute besitzen. Sie können bestimmte dApps autorisieren, Berechnungen darauf auszuführen, ohne alles offenzulegen. Beispielsweise könnte eine dezentrale Rekrutierungs-dApp Kandidaten filtern, indem sie Suchvorgänge auf verschlüsselten Lebensläufen durchführt (mittels FHE) – z. B. Jahre an Erfahrung zählen, Zertifizierungen prüfen – und nur bei einer Übereinstimmung den Kandidaten off-chain kontaktieren. Die privaten Details des Kandidaten bleiben verschlüsselt, sofern er sich nicht zur Offenlegung entscheidet. ZK-Proofs ermöglichen es Benutzern zudem, selektiv zu beweisen, dass sie eine Kombination von Attributen besitzen (z. B. über 21 und in einer bestimmten Postleitzahl ansässig), ohne die tatsächlichen Werte zu verraten.

• Mehrparteien-Identitätsprüfung: Manchmal muss die Identität eines Benutzers von mehreren Parteien überprüft werden (z. B. Hintergrundprüfung durch Firma A, Bonitätsprüfung durch Firma B). Mit homomorphen und ZK-Tools könnte jeder Verifizierer einen verschlüsselten Score oder eine Genehmigung beisteuern, und ein Smart Contract kann diese zu einer endgültigen Entscheidung aggregieren, ohne die einzelnen Beiträge offenzulegen. Beispielsweise liefern drei Agenturen verschlüsselte „Bestanden/Nicht bestanden“-Bits, und der Contract gibt eine Genehmigung aus, wenn alle drei positiv sind – der Benutzer oder die vertrauende Partei sieht nur das Endergebnis, nicht aber, welche spezifische Agentur ihn eventuell abgelehnt hat. Dies wahrt die Privatsphäre des Datensatzes des Benutzers bei jeder Agentur und kann Voreingenommenheit oder Stigmatisierung reduzieren.

Gesundheitswesen und sensibler Datenaustausch​

Gesundheitsdaten sind hochsensibel und reguliert, doch die Kombination von Daten aus mehreren Quellen kann einen enormen Wert freisetzen (für Forschung, Versicherungen, personalisierte Medizin). Blockchain könnte eine Vertrauensebene für den Datenaustausch bieten, wenn die Privatsphäre gewahrt bleibt. Vertrauliche Smart Contracts könnten neue Gesundheitsdaten-Ökosysteme ermöglichen:

• Sicherer medizinischer Datenaustausch: Patienten könnten Referenzen zu ihren Krankenakten in verschlüsselter Form on-chain speichern. Ein FHE-fähiger Contract könnte es einer Forschungseinrichtung ermöglichen, Analysen auf einer Kohorte von Patientendaten durchzuführen, ohne diese zu entschlüsseln. Beispielsweise könnte ein Contract die durchschnittliche Wirksamkeit eines Medikaments über verschlüsselte Patientenergebnisse berechnen. Nur aggregierte statistische Ergebnisse werden entschlüsselt ausgegeben (und vielleicht nur, wenn eine Mindestanzahl von Patienten enthalten ist, um eine Re-Identifizierung zu verhindern). Patienten könnten Mikrozahlungen für die Bereitstellung ihrer verschlüsselten Daten für die Forschung erhalten, in dem Wissen, dass ihre Privatsphäre gewahrt bleibt, da selbst die Blockchain und die Forscher nur Chiffretext oder aggregierte Proofs sehen. Dies fördert einen Datenmarktplatz für das Gesundheitswesen, der die Privatsphäre respektiert.

• Privatsphäre-schonende Versicherungsansprüche: Die Bearbeitung von Krankenversicherungsansprüchen könnte über Smart Contracts automatisiert werden, die Bedingungen auf medizinischen Daten verifizieren, ohne die Daten dem Versicherer offenzulegen. Ein Anspruch könnte einen verschlüsselten Diagnosecode und verschlüsselte Behandlungskosten enthalten; der Contract prüft mittels FHE die Policenregeln (z. B. Deckung, Selbstbeteiligung) auf diesen verschlüsselten Daten. Er könnte eine Genehmigung und einen Zahlungsbetrag ausgeben, ohne dem Versicherer jemals die tatsächliche Diagnose auf der Blockchain preiszugeben (nur Patient und Arzt besaßen den Schlüssel). ZK-Proofs könnten verwendet werden, um zu zeigen, dass die Daten des Patienten aus den Unterlagen eines zertifizierten Krankenhauses stammen (unter Verwendung von Tools wie Axiom), ohne den Datensatz selbst offenzulegen. Dies schützt die Privatsphäre der Patienten und beugt Betrug vor.

• Berechnungen auf Genom- und persönlichen Daten: Genomdaten sind extrem sensibel (sie sind buchstäblich der DNA-Bauplan eines Menschen). Die Analyse von Genomen kann jedoch wertvolle gesundheitliche Erkenntnisse liefern. Unternehmen könnten FHE-VMs nutzen, um Berechnungen auf verschlüsselten Genomen durchzuführen, die von Benutzern hochgeladen wurden. Ein Smart Contract könnte beispielsweise ein Gen-Umwelt-Risikomodell auf verschlüsselten Genomdaten und verschlüsselten Umweltdaten (etwa von Wearables) ausführen und einen Risikoscore ausgeben, den nur der Benutzer entschlüsseln kann. Die Logik ist im Contract kodiert und läuft homomorph ab, sodass die Genomdaten niemals im Klartext erscheinen. Auf diese Weise erhalten Nutzer Erkenntnisse, ohne Unternehmen rohe DNA-Daten zu geben – was sowohl Datenschutz- als auch Dateneigentumsbedenken mindert.

• Epidemiologie und öffentliche Gesundheit: In Situationen wie Pandemien ist der Datenaustausch für die Modellierung der Krankheitsausbreitung lebenswichtig, aber Datenschutzgesetze können dies behindern. ZK-Coprozessoren könnten es Gesundheitsbehörden ermöglichen, Anfragen wie „Wie viele Personen in Region X wurden in den letzten 24 Stunden positiv getestet?“ über Proofs an ein Netzwerk von Krankenhausdaten zu stellen. Jedes Krankenhaus bewahrt Patientendaten off-chain auf, kann aber dem Contract der Behörde die Anzahl der Positivfälle beweisen, ohne die Identität der Personen preiszugeben. Ähnlich könnte eine Kontaktverfolgung durch den Abgleich verschlüsselter Standortverläufe erfolgen: Contracts können Überschneidungen verschlüsselter Standortverläufe von Patienten berechnen, um Hotspots zu identifizieren, und nur die Hotspot-Standorte ausgeben (und vielleicht eine verschlüsselte Liste betroffener IDs, die nur das Gesundheitsamt entschlüsseln kann). Die rohen Standortverläufe von Einzelpersonen bleiben privat.

Datenmarktplätze und Zusammenarbeit​

Die Fähigkeit, Berechnungen auf Daten durchzuführen, ohne sie offenzulegen, eröffnet neue Geschäftsmodelle rund um den Datenaustausch. Einheiten können an Berechnungen zusammenarbeiten, in dem Wissen, dass ihre proprietären Daten nicht exponiert werden:

• Sichere Datenmarktplätze: Verkäufer können Daten in verschlüsselter Form auf einem Blockchain-Marktplatz zur Verfügung stellen. Käufer können bezahlen, um spezifische Analysen oder Machine-Learning-Modelle über einen Smart Contract auf dem verschlüsselten Datensatz auszuführen, und erhalten entweder das trainierte Modell oder aggregierte Ergebnisse. Die Rohdaten des Verkäufers werden niemals dem Käufer oder der Öffentlichkeit offengelegt – der Käufer erhält möglicherweise nur ein Modell (das dennoch Informationen über Gewichte lecken könnte, was jedoch durch Techniken wie Differential Privacy oder Steuerung der Ausgabegranularität gemildert werden kann). ZK-Proofs können dem Käufer garantieren, dass die Berechnung korrekt über dem versprochenen Datensatz durchgeführt wurde. Dieses Szenario fördert den Datenaustausch: Ein Unternehmen könnte beispielsweise Nutzerverhaltensdaten monetarisieren, indem es zugelassenen Algorithmen erlaubt, darauf unter Verschlüsselung zu laufen, ohne die Daten selbst preiszugeben.

• Föderiertes Lernen & Dezentrale KI: Beim dezentralen maschinellen Lernen möchten mehrere Parteien (z. B. verschiedene Unternehmen oder Geräte) gemeinsam ein Modell auf ihren kombinierten Daten trainieren, ohne Daten untereinander auszutauschen. FHE-VMs glänzen hier: Sie ermöglichen föderiertes Lernen, bei dem die Modell-Updates jeder Partei homomorph durch einen Contract aggregiert werden. Da die Updates verschlüsselt sind, erfährt kein Teilnehmer die Beiträge der anderen. Der Contract könnte sogar Teile der Trainingsschleife (wie Gradientenverfahren-Schritte) on-chain unter Verschlüsselung durchführen und ein aktualisiertes Modell erzeugen, das nur autorisierte Parteien entschlüsseln können. ZK kann dies ergänzen, indem bewiesen wird, dass das Update jeder Partei gemäß dem Trainingsalgorithmus berechnet wurde (was verhindert, dass ein bösartiger Teilnehmer das Modell vergiftet). Dies bedeutet, dass ein globales Modell mit voller Prüfbarkeit on-chain trainiert werden kann, während die Trainingsdaten jedes Mitwirkenden privat bleiben. Zu den Anwendungsfällen gehören das gemeinsame Training von Betrugserkennungsmodellen über Banken hinweg oder die Verbesserung von KI-Assistenten mit Daten vieler Nutzer ohne Zentralisierung der Rohdaten.

• Organisationsübergreifende Analysen: Stellen Sie sich zwei Unternehmen vor, die für eine Partnerschaftskampagne ihre Schnittmenge an Kunden finden wollen, ohne sich gegenseitig ihre gesamten Kundenlisten offenzulegen. Sie könnten jeweils ihre Kunden-ID-Listen verschlüsseln und ein Commitment hochladen. Ein FHE-fähiger Contract kann die Schnittmenge auf den verschlüsselten Mengen berechnen (unter Verwendung von Techniken wie Private Set Intersection via FHE). Das Ergebnis könnte eine verschlüsselte Liste gemeinsamer Kunden-IDs sein, die nur ein gegenseitig vertrauenswürdiger Dritter (oder die Kunden selbst über einen bestimmten Mechanismus) entschlüsseln kann. Alternativ ein ZK-Ansatz: Eine Partei beweist der anderen in Zero-Knowledge, dass „wir N gemeinsame Kunden haben und hier ist eine Verschlüsselung dieser IDs“, zusammen mit einem Proof, dass die Verschlüsselung tatsächlich den gemeinsamen Einträgen entspricht. Auf diese Weise können sie eine Kampagne für diese N Kunden durchführen, ohne jemals ihre vollständigen Listen im Klartext ausgetauscht zu haben. Ähnliche Szenarien: Berechnung von Lieferketten-Metriken über Wettbewerber hinweg, ohne Details einzelner Lieferanten preiszugeben, oder Banken, die Kreditinformationen abgleichen, ohne vollständige Kundendaten zu teilen.

• Sichere Multi-Party Computation (MPC) auf der Blockchain: FHE und ZK bringen MPC-Konzepte im Wesentlichen on-chain. Komplexe Geschäftslogik, die mehrere Organisationen umspannt, kann in einem Smart Contract so kodiert werden, dass die Eingaben jeder Organisation geheim geteilt oder verschlüsselt sind. Der Contract (als MPC-Moderator) erzeugt Ergebnisse wie Gewinnbeteiligungen, Kostenkalkulationen oder gemeinsame Risikobewertungen, denen jeder vertrauen kann. Angenommen, mehrere Energieunternehmen möchten einen Marktplatz für den Stromhandel abrechnen. Sie könnten ihre verschlüsselten Gebote und Angebote in eine Smart-Contract-Auktion einspeisen; der Contract berechnet die Clearingpreise und Zuteilungen auf den verschlüsselten Geboten und gibt die Zuteilung und Kosten jedes Unternehmens nur an dieses Unternehmen aus (via Verschlüsselung mit dessen öffentlichem Schlüssel). Kein Unternehmen sieht die Gebote der anderen, was Wettbewerbsinformationen schützt, aber das Auktionsergebnis ist fair und überprüfbar. Diese Kombination aus Blockchain-Transparenz und MPC-Privatsphäre könnte Konsortien und Unternehmenskonsortien revolutionieren, die sich derzeit auf vertrauenswürdige Dritte verlassen.

Dezentrales maschinelles Lernen (ZKML und FHE-ML)​

Maschinelles Lernen verifizierbar und privat auf Blockchains zu bringen, ist ein aufstrebendes Feld:

• Verifizierbare ML-Inferenz: Mithilfe von ZK-Proofs kann man beweisen, dass „ein Machine-Learning-Modell f bei Eingabe x das Ergebnis y liefert“, ohne entweder x (falls es private Daten sind) oder die internen Abläufe von f (falls die Modellgewichte proprietär sind) preiszugeben. Dies ist entscheidend für KI-Dienste auf der Blockchain – z. B. ein dezentrales KI-Orakel, das Vorhersagen oder Klassifizierungen liefert. Ein ZK-Coprozessor kann das Modell off-chain ausführen (da Modelle groß und teuer in der Auswertung sein können) und einen Proof des Ergebnisses posten. Beispielsweise könnte ein Orakel die Aussage beweisen: „Das bereitgestellte Satellitenbild zeigt eine Baumbedeckung von mindestens 50 %“, um einen Carbon-Credit-Vertrag zu unterstützen, ohne das Satellitenbild oder möglicherweise sogar das Modell preiszugeben. Dies ist als ZKML bekannt, und Projekte arbeiten an der Optimierung schaltkreisfreundlicher neuronaler Netze. Es gewährleistet die Integrität von KI-Ausgaben in Smart Contracts und kann die Vertraulichkeit von Eingabedaten und Modellparametern wahren.

• Training mit Privatsphäre und Prüfbarkeit: Das Training eines ML-Modells ist noch rechenintensiver, aber falls erreichbar, würde es Blockchain-basierte Modell-Marktplätze ermöglichen. Mehrere Datenanbieter könnten zum Training eines Modells unter FHE beitragen, sodass der Trainingsalgorithmus auf verschlüsselten Daten läuft. Das Ergebnis könnte ein verschlüsseltes Modell sein, das nur der Käufer entschlüsseln kann. Während des Trainings könnten periodisch ZK-Proofs geliefert werden, um zu beweisen, dass das Training dem Protokoll folgt (um zu verhindern, dass ein böswilliger Trainer beispielsweise eine Backdoor einbaut). Während ein vollständiges On-Chain-ML-Training angesichts der Kosten noch in weiter Ferne liegt, könnte ein hybrider Ansatz Off-Chain-Berechnungen mit ZK-Proofs für kritische Teile nutzen. Man könnte sich einen dezentralen Kaggle-ähnlichen Wettbewerb vorstellen, bei dem Teilnehmer Modelle auf privaten Datensätzen trainieren und ZK-Proofs der Modellgenauigkeit auf verschlüsselten Testdaten einreichen, um einen Gewinner zu ermitteln – alles ohne die Datensätze oder die Testdaten offenzulegen.

• Personalisierte KI und Dateneigentum: Mit diesen Technologien könnten Benutzer Eigentümer ihrer persönlichen Daten bleiben und dennoch von KI profitieren. Beispielsweise könnte das mobile Gerät eines Benutzers FHE verwenden, um seine Nutzungsdaten zu verschlüsseln und an einen Analyse-Contract zu senden, der ein personalisiertes KI-Modell (wie ein Empfehlungsmodell) nur für diesen Benutzer berechnet. Das Modell ist verschlüsselt, und nur das Gerät des Benutzers kann es lokal entschlüsseln und verwenden. Die Plattform (vielleicht ein soziales Netzwerk) sieht niemals die Rohdaten oder das Modell, aber der Benutzer erhält den KI-Vorteil. Wenn die Plattform aggregierte Erkenntnisse wünscht, könnte sie ZK-Proofs bestimmter aggregierter Muster vom Contract anfordern, ohne auf individuelle Daten zuzugreifen.

Zusätzliche Bereiche​

• Gaming: On-Chain-Spiele haben oft Schwierigkeiten, geheime Informationen zu verbergen (z. B. verdeckte Kartenblätter, Fog-of-War in Strategiespielen). FHE kann Hidden-State-Spiele ermöglichen, bei denen die Spiellogik auf einem verschlüsselten Zustand läuft. Beispielsweise könnte ein Poker-Contract verschlüsselte Karten mischen und austeilen; Spieler erhalten Entschlüsselungen ihrer eigenen Karten, aber der Contract und andere sehen nur Chiffretext. Die Wettlogik kann ZK-Proofs verwenden, um sicherzustellen, dass ein Spieler bei einer Aktion nicht blufft (oder um das gewinnende Blatt am Ende auf nachweislich faire Weise zu enthüllen). Ebenso können Zufalls-Seeds für das NFT-Minting oder Spielergebnisse generiert und als fair bewiesen werden, ohne den Seed offenzulegen (was Manipulation verhindert). Dies kann das Blockchain-Gaming erheblich verbessern, da es dieselbe Dynamik wie traditionelle Spiele unterstützen kann.

• Wahlen und Governance: DAOs könnten Privatsphäre-Technologie für geheime On-Chain-Abstimmungen nutzen, um Stimmenkauf und Druckausübung zu eliminieren. Eine FHE-VM könnte verschlüsselt abgegebene Stimmen auszählen, und nur die Endergebnisse werden entschlüsselt. ZK-Proofs können sicherstellen, dass jede Stimme gültig war (von einem berechtigten Wähler stammt, der nicht doppelt abgestimmt hat), ohne offenzulegen, wer wofür gestimmt hat. Dies bietet Verifizierbarkeit (jeder kann die Proofs und die Auszählung prüfen) bei gleichzeitiger Wahrung des Wahlgeheimnisses – entscheidend für eine unvoreingenommene Governance.

• Sichere Lieferkette und IoT: In Lieferketten möchten Partner möglicherweise den Nachweis bestimmter Eigenschaften (Herkunft, Qualitätsmetriken) erbringen, ohne Wettbewerbern alle Details offenzulegen. Beispielsweise könnte ein IoT-Sensor an einer Lebensmittellieferung kontinuierlich verschlüsselte Temperaturdaten an eine Blockchain senden. Ein Contract könnte mittels FHE prüfen, ob die Temperatur während des gesamten Transports in einem sicheren Bereich blieb. Wenn ein Schwellenwert überschritten wurde, kann er einen Alarm oder eine Strafe auslösen, muss aber nicht das gesamte Temperaturprotokoll öffentlich machen – vielleicht nur einen Proof oder einen aggregierten Wert wie das „90. Perzentil der Temperatur“. Dies schafft Vertrauen in die Automatisierung der Lieferkette unter Wahrung der Vertraulichkeit von Prozessdaten.

Jeder dieser Anwendungsfälle nutzt die Kernfähigkeit: Daten berechnen oder verifizieren, ohne die Daten offenzulegen. Diese Fähigkeit kann die Art und Weise, wie wir mit sensiblen Informationen in dezentralen Systemen umgehen, grundlegend verändern. Sie verringert den Kompromiss zwischen Transparenz und Privatsphäre, der die Blockchain-Adoption in Bereichen, die mit privaten Daten arbeiten, bisher eingeschränkt hat.

Fazit​

Die Blockchain-Technologie tritt in eine neue Ära der programmierbaren Privatsphäre ein, in der Vertraulichkeit von Daten und die Funktionalität von Smart Contracts Hand in Hand gehen. Die Paradigmen der FHE-VM und ZK-Koprozessoren sind zwar technisch verschieden, streben jedoch beide danach, den Umfang von Blockchain-Anwendungen zu erweitern, indem sie entkoppeln, was wir berechnen können und was wir preisgeben müssen.

Fully Homomorphic Encryption Virtual Machines halten Berechnungen On-Chain und verschlüsselt, wodurch Dezentralisierung und Komponierbarkeit gewahrt bleiben, jedoch Fortschritte bei der Effizienz erforderlich sind. Zero-Knowledge-Koprozessoren verlagern rechenintensive Aufgaben Off-Chain und ermöglichen nahezu unbegrenzte Berechnungen unter kryptografischen Garantien. Sie beweisen bereits ihren Wert bei der Skalierung und Verbesserung von Ethereum. Die Wahl zwischen ihnen (und hybriden Ansätzen) hängt vom Anwendungsfall ab: Wenn eine Echtzeit-Interaktion mit privatem Status erforderlich ist, könnte ein FHE-Ansatz geeigneter sein; wenn extrem komplexe Berechnungen oder die Integration in bestehenden Code erforderlich sind, könnte ein ZK-Koprozessor die richtige Wahl sein. In vielen Fällen ergänzen sie sich – tatsächlich sehen wir, wie ZK-Proofs die FHE-Integrität stärken und FHE potenziell ZK unterstützt, indem es private Daten für Prover verarbeitet.

Für Entwickler werden diese Technologien neue Design-Patterns einführen. Wir werden in verschlüsselten Variablen und Proof-Verifizierung als erstklassige Elemente der dApp-Architektur denken. Das Tooling entwickelt sich rasant weiter: High-Level-Sprachen und SDKs abstrahieren kryptografische Details (z. B. machen die Bibliotheken von Zama FHE-Typen so einfach wie native Typen oder die Vorlagen von RISC Zero für Proof-Anfragen). In wenigen Jahren könnte sich das Schreiben eines vertraulichen Smart Contracts fast so unkompliziert anfühlen wie das eines regulären, nur eben mit standardmäßig „integrierter“ Privatsphäre.

Die Auswirkungen auf die Datenwirtschaft sind tiefgreifend. Einzelpersonen und Unternehmen werden eher bereit sein, Daten oder Logik On-Chain zu bringen, wenn sie deren Sichtbarkeit kontrollieren können. Dies kann die Zusammenarbeit zwischen Organisationen, neue Finanzprodukte und KI-Modelle ermöglichen, die zuvor aufgrund von Datenschutzbedenken nicht realisierbar waren. Auch Regulierungsbehörden könnten diese Techniken begrüßen, da sie Compliance-Prüfungen und Audits mit kryptografischen Mitteln ermöglichen (z. B. den Nachweis, dass Steuern korrekt On-Chain gezahlt wurden, ohne alle Transaktionen offenlegen zu müssen).

Wir befinden uns noch in der Anfangsphase – aktuelle FHE-VM-Prototypen haben Leistungsgrenzen, und ZK-Proofs können, obwohl sie viel schneller als früher sind, immer noch ein Flaschenhals für extrem komplexe Aufgaben sein. Aber kontinuierliche Forschungs- und Entwicklungsanstrengungen (einschließlich spezialisierter Hardware, wie Unternehmen wie Optalysys zeigen, die die optische FHE-Beschleunigung vorantreiben) bauen diese Barrieren schnell ab. Die Investitionen, die in diesen Bereich fließen (z. B. der Einhorn-Status von Zama, die Investition von Paradigm in Axiom), unterstreichen die starke Überzeugung, dass Datenschutzfunktionen für das Web3 ebenso grundlegend sein werden wie Transparenz für das Web1/2.

In Zusammenfassung lässt sich sagen, dass programmierbare Privatsphäre über FHE-VMs und ZK-Koprozessoren eine neue Klasse von dApps einläutet, die vertrauenslos, dezentralisiert und vertraulich sind. Von DeFi-Trades, die keine Details preisgeben, über Gesundheitsforschung, die Patientendaten schützt, bis hin zu Machine-Learning-Modellen, die weltweit trainiert werden, ohne Rohdaten offenzulegen – die Möglichkeiten sind enorm. Da diese Technologien reifen, werden Blockchain-Plattformen nicht mehr den Kompromiss zwischen Nutzen und Datenschutz erzwingen und so eine breitere Akzeptanz in Branchen ermöglichen, die Vertraulichkeit erfordern. Die Zukunft von Web3 ist eine, in der *Nutzer und Organisationen sicher mit sensiblen Daten On-Chain transagieren und rechnen können, im Wissen, dass die Blockchain die Integrität verifiziert und gleichzeitig ihre Geheimnisse schützt*.

Quellen: Die Informationen in diesem Bericht stammen aus technischen Dokumentationen und aktuellen Forschungsblogs führender Projekte in diesem Bereich, darunter die FHEVM-Dokumentation von Cypher und Zama, detaillierte Analysen von Trail of Bits zu den Schaltkreisen von Axiom, Entwicklerleitfäden und Blog-Posts von RISC Zero sowie Branchenartikel, die Anwendungsfälle vertraulicher Blockchain-Technologie hervorheben. Diese Quellen und weitere wurden durchgehend zitiert, um weiterführende Lektüre und Belege für die beschriebenen Architekturen und Anwendungen bereitzustellen.

Eines der Kernversprechen der Blockchain-Technologie wie Ethereum ist ein gewisses Maß an Anonymität. Teilnehmer, bekannt als Validatoren, sollen hinter einem Schleier kryptografischer Pseudonyme agieren, um ihre reale Identität und damit ihre Sicherheit zu schützen.

Eine aktuelle Forschungsarbeit mit dem Titel „Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue“ von Forschern der ETH Zürich und anderer Institutionen enthüllt jedoch einen kritischen Fehler in dieser Annahme. Sie demonstrieren eine einfache, kostengünstige Methode, um den öffentlichen Bezeichner eines Validators direkt mit der IP-Adresse der Maschine zu verknüpfen, auf der er läuft.

Kurz gesagt, Ethereum-Validatoren sind bei weitem nicht so anonym, wie viele glauben. Die Ergebnisse waren so bedeutend, dass die Forscher von der Ethereum Foundation eine Bug Bounty erhielten, was die Schwere des Datenlecks anerkannte.

Wie die Schwachstelle funktioniert: Ein Fehler im Gossip​

Um die Schwachstelle zu verstehen, benötigen wir zunächst ein grundlegendes Bild davon, wie Ethereum-Validatoren kommunizieren. Das Netzwerk besteht aus über einer Million Validatoren, die ständig über den Zustand der Kette „abstimmen“. Diese Abstimmungen werden als Attestierungen bezeichnet und über ein Peer-to-Peer-Netzwerk ($P2P$-Netzwerk) an alle anderen Knoten übertragen.

Bei so vielen Validatoren würde die Übertragung jeder Abstimmung an alle anderen das Netzwerk sofort überlasten. Um dies zu lösen, implementierten die Designer von Ethereum eine clevere Skalierungslösung: Das Netzwerk ist in 64 verschiedene Kommunikationskanäle, bekannt als Subnetze, unterteilt.

• Standardmäßig abonniert jeder Knoten (der Computer, auf dem die Validator-Software läuft) nur zwei dieser 64 Subnetze. Seine Hauptaufgabe ist es, alle Nachrichten, die er auf diesen beiden Kanälen sieht, gewissenhaft weiterzuleiten.
• Wenn ein Validator eine Abstimmung abgeben muss, wird seine Attestierung zufällig einem der 64 Subnetze zur Übertragung zugewiesen.

Hier liegt die Schwachstelle. Stellen Sie sich einen Knoten vor, dessen Aufgabe es ist, den Datenverkehr für die Kanäle 12 und 13 zu verwalten. Den ganzen Tag leitet er treu Nachrichten nur von diesen beiden Kanälen weiter. Doch dann sendet er Ihnen plötzlich eine Nachricht, die zu Kanal 45 gehört.

Das ist ein starker Hinweis. Warum sollte ein Knoten eine Nachricht von einem Kanal verarbeiten, für den er nicht zuständig ist? Die logischste Schlussfolgerung ist, dass der Knoten selbst diese Nachricht generiert hat. Dies impliziert, dass der Validator, der die Attestierung für Kanal 45 erstellt hat, auf genau dieser Maschine läuft.

Die Forscher nutzten genau dieses Prinzip aus. Indem sie eigene Abhörknoten einrichteten, überwachten sie die Subnetze, von denen ihre Peers Attestierungen sendeten. Wenn ein Peer eine Nachricht von einem Subnetz sendete, das er nicht offiziell abonniert hatte, konnten sie mit hoher Sicherheit ableiten, dass der Peer den ursprünglichen Validator hostete.

Die Methode erwies sich als schockierend effektiv. Mit nur vier Knoten über drei Tage lokalisierte das Team erfolgreich die IP-Adressen von über 161.000 Validatoren, was mehr als 15 % des gesamten Ethereum-Netzwerks entspricht.

Warum das wichtig ist: Die Risiken der Enttarnung​

Die Preisgabe der IP-Adresse eines Validators ist keine triviale Angelegenheit. Sie öffnet die Tür für gezielte Angriffe, die einzelne Betreiber und die Gesundheit des Ethereum-Netzwerks insgesamt bedrohen.

1. Gezielte Angriffe und Belohnungsdiebstahl Ethereum kündigt einige Minuten im Voraus an, welcher Validator den nächsten Block vorschlagen soll. Ein Angreifer, der die IP-Adresse dieses Validators kennt, kann einen Denial-of-Service (DDoS)-Angriff starten, ihn mit Datenverkehr überfluten und offline schalten. Wenn der Validator sein Vier-Sekunden-Fenster zum Vorschlagen des Blocks verpasst, geht die Gelegenheit an den nächsten Validator in der Reihe über. Wenn der Angreifer dieser nächste Validator ist, kann er dann die Blockbelohnungen und wertvollen Transaktionsgebühren (MEV) beanspruchen, die dem Opfer zugestanden hätten.

2. Bedrohungen der Netzwerk-Verfügbarkeit und -Sicherheit Ein gut ausgestatteter Angreifer könnte diese „Sniping“-Angriffe wiederholt durchführen, wodurch die gesamte Blockchain verlangsamt oder zum Stillstand gebracht werden könnte (ein Liveness-Angriff oder Verfügbarkeitsangriff). In einem schwerwiegenderen Szenario könnte ein Angreifer diese Informationen nutzen, um ausgeklügelte Netzwerk-Partitionierungsangriffe zu starten, die potenziell dazu führen könnten, dass verschiedene Teile des Netzwerks über die Historie der Kette uneinig sind und somit deren Integrität gefährdet wird (ein Safety-Angriff oder Sicherheitsangriff).

3. Eine zentralisierte Realität enthüllen Die Forschung beleuchtete auch einige unbequeme Wahrheiten über die Dezentralisierung des Netzwerks:

• Extreme Konzentration: Das Team fand Peers, die eine erstaunliche Anzahl von Validatoren hosteten, darunter eine IP-Adresse, die über 19.000 betrieb. Der Ausfall einer einzelnen Maschine könnte einen überproportionalen Einfluss auf das Netzwerk haben.
• Abhängigkeit von Cloud-Diensten: Rund 90 % der lokalisierten Validatoren laufen auf Cloud-Anbietern wie AWS und Hetzner, nicht auf den Computern von Solo-Home-Stakern. Dies stellt einen erheblichen Zentralisierungspunkt dar.
• Versteckte Abhängigkeiten: Viele große Staking-Pools behaupten, ihre Betreiber seien unabhängig. Die Forschung fand jedoch Fälle, in denen Validatoren aus verschiedenen, konkurrierenden Pools auf derselben physischen Maschine liefen, was versteckte systemische Risiken birgt.

Gegenmaßnahmen: Wie können sich Validatoren schützen?​

Glücklicherweise gibt es Möglichkeiten, sich gegen diese Enttarnungstechnik zu verteidigen. Die Forscher schlugen mehrere Gegenmaßnahmen vor:

• Mehr Rauschen erzeugen: Ein Validator kann sich entscheiden, mehr als zwei Subnetze – oder sogar alle 64 – zu abonnieren. Dies erschwert es einem Beobachter erheblich, zwischen weitergeleiteten und selbst generierten Nachrichten zu unterscheiden.
• Mehrere Knoten verwenden: Ein Betreiber kann die Validator-Aufgaben auf verschiedene Maschinen mit unterschiedlichen IPs aufteilen. Zum Beispiel könnte ein Knoten Attestierungen verwalten, während ein separater, privater Knoten nur zum Vorschlagen von Blöcken mit hohem Wert verwendet wird.
• Privates Peering: Validatoren können vertrauenswürdige, private Verbindungen mit anderen Knoten herstellen, um ihre Nachrichten weiterzuleiten und so ihren wahren Ursprung innerhalb einer kleinen, vertrauenswürdigen Gruppe zu verschleiern.
• Anonyme Broadcasting-Protokolle: Fortgeschrittenere Lösungen wie Dandelion, das den Ursprung einer Nachricht verschleiert, indem es sie über einen zufälligen „Stamm“ leitet, bevor sie weit verbreitet wird, könnten implementiert werden.

Fazit​

Diese Forschung veranschaulicht eindringlich den inhärenten Kompromiss zwischen Leistung und Datenschutz in verteilten Systemen. In seinem Bestreben zu skalieren, hat Ethereums $P2P$-Netzwerk ein Design angenommen, das die Anonymität seiner kritischsten Teilnehmer beeinträchtigt.

Indem die Forscher diese Schwachstelle ans Licht brachten, haben sie der Ethereum-Community das Wissen und die Werkzeuge an die Hand gegeben, die zur Behebung erforderlich sind. Ihre Arbeit ist ein entscheidender Schritt zum Aufbau eines robusteren, sichereren und wirklich dezentralen Netzwerks für die Zukunft.

Die Blockchain-Branche steht 2024 an einem kritischen Wendepunkt. Während der globale Markt für Blockchain-Technologie bis 2030 voraussichtlich 469,49 Milliarden US-Dollar erreichen wird, bleibt der Datenschutz eine grundlegende Herausforderung. Trusted Execution Environments (TEEs) haben sich als potenzielle Lösung herauskristallisiert, wobei der TEE-Markt voraussichtlich von 1,2 Milliarden US-Dollar im Jahr 2023 auf 3,8 Milliarden US-Dollar bis 2028 wachsen wird. Aber löst dieser hardwarebasierte Ansatz das Datenschutzparadoxon der Blockchain wirklich, oder birgt er neue Risiken?

Die Hardware-Grundlage: Das Versprechen von TEE verstehen​

Eine Trusted Execution Environment funktioniert wie ein Banktresor in Ihrem Computer – jedoch mit einem entscheidenden Unterschied. Während ein Banktresor lediglich Vermögenswerte speichert, schafft ein TEE eine isolierte Berechnungsumgebung, in der sensible Operationen vollständig abgeschirmt vom restlichen System ausgeführt werden können, selbst wenn dieses System kompromittiert ist.

Der Markt wird derzeit von drei Schlüsselimplementierungen dominiert:

1. Intel SGX (Software Guard Extensions)

   • Marktanteil: 45 % der Server-TEE-Implementierungen
   • Leistung: Bis zu 40 % Overhead für verschlüsselte Operationen
   • Sicherheitsmerkmale: Speicherverschlüsselung, Remote Attestation
   • Bemerkenswerte Nutzer: Microsoft Azure Confidential Computing, Fortanix

2. ARM TrustZone

   • Marktanteil: 80 % der mobilen TEE-Implementierungen
   • Leistung: <5 % Overhead für die meisten Operationen
   • Sicherheitsmerkmale: Sicherer Start, biometrischer Schutz
   • Schlüsselanwendungen: Mobile Zahlungen, DRM, sichere Authentifizierung

3. AMD SEV (Secure Encrypted Virtualization)

   • Marktanteil: 25 % der Server-TEE-Implementierungen
   • Leistung: 2-7 % Overhead für VM-Verschlüsselung
   • Sicherheitsmerkmale: VM-Speicherverschlüsselung, Schutz von verschachtelten Seitentabellen
   • Bemerkenswerte Nutzer: Google Cloud Confidential Computing, AWS Nitro Enclaves

Auswirkungen in der Praxis: Die Daten sprechen für sich​

Betrachten wir drei Schlüsselanwendungen, in denen TEE die Blockchain bereits transformiert:

1. MEV-Schutz: Die Flashbots-Fallstudie​

Die Implementierung von TEE durch Flashbots hat bemerkenswerte Ergebnisse gezeigt:

• Vor-TEE (2022):

  • Durchschnittliche tägliche MEV-Extraktion: 7,1 Mio. US-Dollar
  • Zentralisierte Extraktoren: 85 % des MEV
  • Benutzerverluste durch Sandwich-Angriffe: 3,2 Mio. US-Dollar täglich

• Nach-TEE (2023):

  • Durchschnittliche tägliche MEV-Extraktion: 4,3 Mio. US-Dollar (-39 %)
  • Demokratisierte Extraktion: Keine einzelne Entität >15 % des MEV
  • Benutzerverluste durch Sandwich-Angriffe: 0,8 Mio. US-Dollar täglich (-75 %)

Laut Phil Daian, Mitbegründer von Flashbots: „TEE hat die MEV-Landschaft grundlegend verändert. Wir sehen einen demokratischeren, effizienteren Markt mit deutlich geringerem Benutzerschaden.“

2. Skalierungslösungen: Scrolls Durchbruch​

Scrolls hybrider Ansatz, der TEE mit Zero-Knowledge-Proofs kombiniert, hat beeindruckende Metriken erzielt:

• Transaktionsdurchsatz: 3.000 TPS (im Vergleich zu Ethereums 15 TPS)
• Kosten pro Transaktion: 0,05 US-Dollar (vs. 2-20 US-Dollar im Ethereum-Mainnet)
• Validierungszeit: 15 Sekunden (vs. Minuten für reine ZK-Lösungen)
• Sicherheitsgarantie: 99,99 % mit doppelter Verifizierung (TEE + ZK)

Dr. Sarah Wang, Blockchain-Forscherin an der UC Berkeley, bemerkt: „Scrolls Implementierung zeigt, wie TEE kryptografische Lösungen ergänzen kann, anstatt sie zu ersetzen. Die Leistungssteigerungen sind erheblich, ohne die Sicherheit zu beeinträchtigen.“

3. Privates DeFi: Neue Anwendungen​

Mehrere DeFi-Protokolle nutzen jetzt TEE für private Transaktionen:

• Secret Network (unter Verwendung von Intel SGX):
  • Über 500.000 private Transaktionen verarbeitet
  • 150 Mio. US-Dollar an privaten Token-Transfers
  • 95 % Reduzierung von Front-Running

Die technische Realität: Herausforderungen und Lösungen​

Minderung von Seitenkanalangriffen​

Jüngste Forschungsergebnisse haben sowohl Schwachstellen als auch Lösungen aufgezeigt:

1. Angriffe durch Leistungsanalyse (Power Analysis Attacks)

   • Schwachstelle: 85 % Erfolgsrate bei der Schlüsselgewinnung
   • Lösung: Intels neuestes SGX-Update reduziert die Erfolgsrate auf <0,1 %
   • Kosten: 2 % zusätzlicher Leistungs-Overhead

2. Cache-Timing-Angriffe (Cache Timing Attacks)

   • Schwachstelle: 70 % Erfolgsrate bei der Datenextraktion
   • Lösung: AMDs Cache-Partitionierungs-Technologie
   • Auswirkung: Reduziert die Angriffsfläche um 99 %

Analyse des Zentralisierungsrisikos​

Die Hardware-Abhängigkeit birgt spezifische Risiken:

• Marktanteil der Hardware-Anbieter (2023):
  • Intel: 45 %
  • AMD: 25 %
  • ARM: 20 %
  • Andere: 10 %

Um Zentralisierungsbedenken zu begegnen, implementieren Projekte wie Scroll eine Multi-Vendor-TEE-Verifizierung:

• Erforderliche Zustimmung von 2+ verschiedenen Anbieter-TEEs
• Kreuzvalidierung mit Nicht-TEE-Lösungen
• Open-Source-Verifizierungstools

Marktanalyse und Zukunftsprognosen​

Die TEE-Einführung in der Blockchain zeigt ein starkes Wachstum:

• Aktuelle Implementierungskosten:

  • Server-grade TEE-Hardware: 2.000-5.000 US-Dollar
  • Integrationskosten: 50.000-100.000 US-Dollar
  • Wartung: 5.000 US-Dollar/Monat

• Prognostizierte Kostenreduzierung: 2024: -15 % 2025: -30 % 2026: -50 %

Branchenexperten prognostizieren drei Schlüsselentwicklungen bis 2025:

1. Hardware-Evolution

   • Neue TEE-spezifische Prozessoren
   • Reduzierter Leistungs-Overhead (<1 %)
   • Verbesserter Seitenkanalschutz

2. Marktkonsolidierung

   • Entstehung von Standards
   • Plattformübergreifende Kompatibilität
   • Vereinfachte Entwicklertools

3. Anwendungserweiterung

   • Private Smart-Contract-Plattformen
   • Dezentrale Identitätslösungen
   • Cross-Chain-Datenschutzprotokolle

Der Weg nach vorn​

Obwohl TEE überzeugende Lösungen bietet, erfordert der Erfolg die Bearbeitung mehrerer Schlüsselbereiche:

1. Standardentwicklung

   • Bildung von Branchenarbeitsgruppen
   • Offene Protokolle für herstellerübergreifende Kompatibilität
   • Sicherheitszertifizierungsrahmen

2. Entwickler-Ökosystem

   • Neue Tools und SDKs
   • Schulungs- und Zertifizierungsprogramme
   • Referenzimplementierungen

3. Hardware-Innovation

   • TEE-Architekturen der nächsten Generation
   • Reduzierte Kosten und Energieverbrauch
   • Verbesserte Sicherheitsfunktionen

Wettbewerbslandschaft​

TEE steht im Wettbewerb mit anderen Datenschutzlösungen:

Lösung	Leistung	Sicherheit	Dezentralisierung	Kosten
TEE	Hoch	Mittel-Hoch	Mittel	Mittel
MPC	Mittel	Hoch	Hoch	Hoch
FHE	Niedrig	Hoch	Hoch	Sehr Hoch
ZK Proofs	Mittel-Hoch	Hoch	Hoch	Hoch

Das Fazit​

TEE stellt einen pragmatischen Ansatz für den Blockchain-Datenschutz dar, der sofortige Leistungsvorteile bietet und gleichzeitig daran arbeitet, Zentralisierungsbedenken zu begegnen. Die schnelle Akzeptanz der Technologie durch große Projekte wie Flashbots und Scroll, kombiniert mit messbaren Verbesserungen bei Sicherheit und Effizienz, deutet darauf hin, dass TEE eine entscheidende Rolle in der Entwicklung der Blockchain spielen wird.

Der Erfolg ist jedoch nicht garantiert. Die nächsten 24 Monate werden entscheidend sein, da sich die Branche mit Hardware-Abhängigkeiten, Standardisierungsbemühungen und der allgegenwärtigen Herausforderung von Seitenkanalangriffen auseinandersetzt. Für Blockchain-Entwickler und Unternehmen ist es entscheidend, die Stärken und Grenzen von TEE zu verstehen und es als Teil einer umfassenden Datenschutzstrategie zu implementieren, anstatt als Patentlösung.