Trusted Execution Environments (TEEs) im Web3-Ökosystem: Ein tiefer Einblick

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 hinsichtlich Vertraulichkeit und Integrität schützt. Praktisch gesehen fungiert eine TEE als isolierte „Enklave“ innerhalb der CPU – eine Art Black Box, in der sensible Berechnungen abgeschirmt vom restlichen System ausgeführt werden können. Code, der innerhalb einer TEE-Enklave läuft, ist so geschützt, dass selbst ein kompromittiertes Betriebssystem oder ein Hypervisor die Daten oder den Code der Enklave nicht lesen oder manipulieren kann. Zu den wichtigsten Sicherheitsmerkmalen von TEEs gehören:

• Isolation: Der Speicher der Enklave ist von anderen Prozessen und sogar vom OS-Kernel isoliert. Selbst wenn ein Angreifer volle Administratorrechte auf der Maschine erlangt, kann er den Enklavenspeicher 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 Laufzeitzustands wird erkannt, wodurch kompromittierte Ergebnisse verhindert werden.
• Vertraulichkeit: Daten innerhalb der Enklave bleiben im Speicher verschlüsselt und werden nur zur Verwendung innerhalb der CPU entschlüsselt, sodass geheime Daten nicht im Klartext an die Außenwelt gelangen.
• Remote Attestierung: Die TEE kann kryptografische Nachweise (Attestierungen) erbringen, 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. erwarteten Code auf echter Hardware ausführt), bevor sie sie mit geheimen Daten versorgen.

Konzeptdiagramm einer Trusted Execution Environment als sichere Enklaven-„Black Box“ für die Ausführung von Smart Contracts. Verschlüsselte Eingaben (Daten und Vertrags-Code) 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 alle außerhalb der TEE vertraulich bleiben.

Im Hintergrund 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 (in die Hardware eingebrannt oder von einem sicheren Co-Prozessor verwaltet), um Daten im laufenden Betrieb zu verschlüsseln/entschlüsseln. Jeder Versuch externer Software, den Enklavenspeicher zu lesen, erhält nur verschlüsselte Bytes. Dieser einzigartige Schutz auf CPU-Ebene ermöglicht es selbst Code auf Benutzerebene, private Speicherbereiche (Enklaven) zu definieren, die privilegierte Malware oder sogar ein bösartiger Systemadministrator nicht ausspionieren 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 sichere Elemente oder Hardware-Sicherheitsmodule.

Wichtige Hardware-Implementierungen: Es gibt mehrere Hardware-TEE-Technologien, jede mit unterschiedlichen Architekturen, aber einem ä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 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 und aus der Enklave zu übertragen. SGX bietet eine starke Isolation für Enklaven und unterstützt die Remote-Attestierung über den Attestation Service (IAS) von Intel. Viele Blockchain-Projekte – insbesondere Secret Network und Oasis Network – bauten datenschutzfreundliche Smart-Contract-Funktionalitäten auf SGX-Enklaven auf. 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 Speicher und Peripheriegeräte hat, während die Normal World das reguläre Betriebssystem und Anwendungen ausführt. Der Wechsel zwischen den Welten wird 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. Im 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 können. TrustZone-Enklaven sind jedoch typischerweise grobkörniger (auf OS- oder VM-Ebene) und in aktuellen Web3-Projekten nicht so weit verbreitet 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, um kryptografische Schlüssel zu verwalten und Speicherverschlüsselung durchzuführen, sodass der Speicher einer VM selbst für den Host-Hypervisor vertraulich bleibt. Dies macht SEV gut geeignet für Cloud- oder Server-Anwendungsfälle: Zum Beispiel könnte ein Blockchain-Node oder ein Off-Chain-Worker innerhalb einer vollständig verschlüsselten VM laufen und seine Daten vor einem bösartigen Cloud-Anbieter schützen. Das Design von SEV bedeutet weniger Entwicklungsaufwand für die Code-Partitionierung (Sie können 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 sich auf einen zentralisierten Dienst verlassen zu müssen. SEV ist hochrelevant für den TEE-Einsatz in Cloud-basierter Blockchain-Infrastruktur.

Weitere 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 sichere Enklaven-Chips in Mobilgeräten (wie Apples Secure Enclave, obwohl diese typischerweise nicht für beliebigen Code offen sind). Jede TEE hat ihr eigenes Entwicklungsmodell und ihre eigenen Vertrauensannahmen, aber alle teilen die Kernidee der hardware-isolierten sicheren Ausführung.

2. Anwendungen von TEEs in Web3

Trusted Execution Environments sind zu einem leistungsstarken Werkzeug geworden, um einige der größten Herausforderungen von Web3 zu bewältigen. Durch die Bereitstellung einer sicheren, privaten Berechnungsebene ermöglichen TEEs neue Möglichkeiten für Blockchain-Anwendungen in den Bereichen Datenschutz, Skalierbarkeit, Oracle-Sicherheit und Integrität. Im Folgenden untersuchen wir die wichtigsten Anwendungsbereiche:

Datenschutzfreundliche Smart Contracts

Eine der prominentesten 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 Finanztransaktionen, geheime Abstimmungen, Verarbeitung personenbezogener Daten). TEEs bieten eine Lösung, indem sie als datenschutzfreundliche 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, innerhalb der Enklave verarbeitet werden, wo sie für die Außenwelt verschlüsselt bleiben, und dann kann die Enklave ein verschlüsseltes oder gehashtes Ergebnis zurück an die Kette ausgeben. Nur autorisierte Parteien mit dem Entschlüsselungsschlüssel (oder die Vertragslogik selbst) können auf das Klartext-Ergebnis zugreifen. Zum Beispiel verwendet das Secret Network Intel SGX in seinen Konsens-Nodes, um CosmWasm-Smart Contracts auf verschlüsselten Eingaben auszuführen, sodass Dinge wie Kontostände, Transaktionsbeträge oder der Vertragsstatus vor der Öffentlichkeit verborgen bleiben können, während sie dennoch in Berechnungen nutzbar sind. Dies hat geheime DeFi-Anwendungen ermöglicht – z. B. private Token-Swaps, bei denen die Beträge vertraulich sind, oder geheime Auktionen, bei denen Gebote verschlüsselt sind und erst nach Auktionsende offengelegt werden. Ein weiteres Beispiel ist Oasis Networks Parcel und vertrauliches ParaTime, das die Tokenisierung von Daten und deren Verwendung in Smart Contracts unter Vertraulichkeitsbeschränkungen ermöglicht, wodurch Anwendungsfälle wie Kredit-Scoring oder medizinische Daten auf der Blockchain mit Datenschutz-Compliance ermöglicht werden.

Datenschutzfreundliche Smart Contracts über 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 halten. Zum Beispiel könnte eine Bank einen TEE-fähigen Vertrag verwenden, um Kreditanträge oder Handelsabrechnungen abzuwickeln, 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 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, wobei nur verschlüsselte Ausgaben die Enklave verlassen, was den Aufsichtsbehörden die Gewissheit gibt, dass Daten geschützt sind.

Über die Vertraulichkeit hinaus tragen TEEs auch dazu bei, die Fairness in Smart Contracts durchzusetzen. Zum Beispiel könnte eine dezentrale Börse ihre Matching-Engine innerhalb einer TEE betreiben, um zu verhindern, dass Miner oder Validatoren ausstehende Aufträge sehen und Trades unfair vorwegnehmen (Front-Running). Zusammenfassend bringen TEEs eine dringend benötigte Datenschutzschicht in Web3 und ermöglichen Anwendungen wie vertrauliches DeFi, private Abstimmungen/Governance und Unternehmensverträge, die zuvor auf öffentlichen Ledgern undurchführbar waren.

Skalierbarkeit und Off-Chain-Berechnung

Eine weitere entscheidende Rolle von TEEs ist die Verbesserung der Blockchain-Skalierbarkeit, indem rechenintensive Aufgaben Off-Chain in eine sichere Umgebung ausgelagert werden. Blockchains kämpfen mit komplexen oder rechenintensiven Aufgaben aufgrund von Leistungsgrenzen und Kosten der On-Chain-Ausführung. TEE-fähige Off-Chain-Berechnungen ermöglichen es, diese Aufgaben außerhalb der Hauptkette durchzuführen (wodurch kein Block-Gas verbraucht oder der On-Chain-Durchsatz verlangsamt wird), während gleichzeitig Vertrauensgarantien hinsichtlich der Korrektheit der Ergebnisse erhalten bleiben. Im Grunde kann eine TEE als verifizierbarer Off-Chain-Rechenbeschleuniger für Web3 dienen.

Zum Beispiel verwendet die iExec-Plattform TEEs, um einen dezentralen Cloud-Computing-Marktplatz zu schaffen, auf dem Entwickler Berechnungen Off-Chain ausführen und Ergebnisse erhalten können, denen die Blockchain vertraut. Eine dApp kann eine Berechnung (z. B. eine komplexe KI-Modellinferenz oder eine Big-Data-Analyse) von iExec-Worker-Nodes anfordern. Diese Worker-Nodes führen die Aufgabe innerhalb einer SGX-Enklave aus und erzeugen ein Ergebnis zusammen mit einer Attestierung, dass der korrekte Code in einer echten Enklave ausgeführt wurde. Das Ergebnis wird dann On-Chain zurückgegeben, und der Smart Contract kann die Attestierung der Enklave überprüfen, bevor er die Ausgabe akzeptiert. Diese Architektur ermöglicht die Verarbeitung hoher Arbeitslasten Off-Chain, ohne das Vertrauen zu opfern, und steigert so effektiv den Durchsatz. Die Integration des iExec Orchestrator mit Chainlink demonstriert dies: Ein Chainlink-Oracle ruft externe Daten ab, übergibt dann eine komplexe Berechnung an die TEE-Worker von iExec (z. B. Aggregation oder Bewertung der Daten), und schließlich wird das sichere Ergebnis On-Chain geliefert. Anwendungsfälle umfassen Dinge wie dezentrale Versicherungsberechnungen (wie iExec demonstrierte), bei denen viele Daten Off-Chain und kostengünstig verarbeitet werden können, wobei nur das Endergebnis an die Blockchain geht.

TEE-basierte Off-Chain-Berechnungen untermauern auch einige Layer-2-Skalierungslösungen. Oasis Labs' früher Prototyp Ekiden (der Vorläufer des Oasis Network) verwendete SGX-Enklaven, um die Transaktionsausführung Off-Chain parallel auszuführen und dann nur Zustands-Roots an die Hauptkette zu übergeben, was effektiv Rollup-Ideen ähnelt, aber Hardware-Vertrauen nutzt. 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 Sanders Networks kommendes Op-Succinct L2, das TEEs und zkSNARKs kombiniert: TEEs führen Transaktionen privat und schnell aus, und dann werden ZK-Proofs generiert, um die Korrektheit dieser Ausführungen gegenüber Ethereum zu beweisen. Dieser hybride Ansatz nutzt die TEE-Geschwindigkeit und die ZK-Verifizierbarkeit 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-Anweisungen verwenden, nur mit Isolation), sodass sie für komplexe Logik um Größenordnungen schneller sind als rein kryptografische Alternativen wie homomorphe Verschlüsselung oder Zero-Knowledge-Proofs. Durch die Auslagerung von Aufgaben an Enklaven können Blockchains komplexere Anwendungen (wie maschinelles Lernen, Bild-/Audioverarbeitung, große Analysen) verarbeiten, die On-Chain unpraktisch wären. Die Ergebnisse werden mit einer Attestierung zurückgegeben, die der On-Chain-Vertrag oder Benutzer als von einer vertrauenswürdigen Enklave stammend verifizieren können, wodurch die Datenintegrität und Korrektheit erhalten bleibt. Dieses Modell wird oft als „verifizierbare Off-Chain-Berechnung“ bezeichnet, und TEEs sind ein Eckpfeiler vieler solcher Designs (z. B. verwendet Hyperledger Avalons Trusted Compute Framework, entwickelt von Intel, iExec und anderen, TEEs, um EVM-Bytecode Off-Chain mit einem On-Chain veröffentlichten Korrektheitsnachweis auszuführen).

Sichere Oracles und Datenintegrität

Oracles verbinden Blockchains mit realen Daten, führen aber Vertrauensherausforderungen ein: Wie kann ein Smart Contract darauf vertrauen, dass ein Off-Chain-Datenfeed korrekt und unverfälscht ist? TEEs bieten eine Lösung, indem sie als sichere Sandbox für Oracle-Nodes dienen. Ein TEE-basiertes Oracle-Node kann Daten von externen Quellen (APIs, Webdienste) abrufen und diese innerhalb einer Enklave verarbeiten, die garantiert, dass die Daten weder vom Node-Betreiber noch von Malware auf dem Node manipuliert wurden. Die Enklave kann dann die Wahrheit der von ihr 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 die Attestierung der Enklave zu brechen (was die Blockchain erkennen wird).

Ein bemerkenswertes Beispiel ist Town Crier, ein an der Cornell University 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 an einen Vertrag zusammen mit einem Nachweis (einer Enklaven-Signatur), dass die Daten direkt von der Quelle stammten und nicht gefälscht wurden. Chainlink erkannte den Wert dessen 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: Zum Beispiel beinhalten Chainlinks DECO und Fair Sequencing Services TEEs, um Datenvertraulichkeit und faire Reihenfolge sicherzustellen. Wie in einer Analyse festgestellt wurde, „revolutionierte TEE die Oracle-Sicherheit, indem es eine manipulationssichere Umgebung für die Datenverarbeitung bereitstellte... selbst die Node-Betreiber können die Daten während der Verarbeitung nicht manipulieren“. Dies ist besonders entscheidend für hochwertige Finanzdaten-Feeds (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, sensible oder proprietäre Daten zu verarbeiten, die nicht im Klartext auf einer Blockchain veröffentlicht werden könnten. Zum Beispiel könnte ein Oracle-Netzwerk Enklaven verwenden, um private Daten (wie vertrauliche Aktienauftragsbücher oder persönliche Gesundheitsdaten) zu aggregieren und nur abgeleitete Ergebnisse oder validierte Nachweise an die Blockchain zu übermitteln, 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 ist für die Tokenisierung von Real World Assets (RWA), Kredit-Scoring, Versicherungen und andere datenintensive On-Chain-Dienste.

Zum Thema Cross-Chain-Bridges verbessern TEEs ebenfalls die Integrität. Bridges verlassen sich oft auf eine Reihe von Validatoren oder eine Multi-Sig, um Assets zu verwahren und Übertragungen zwischen Ketten 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 vor Manipulationen schützen. Selbst wenn das Betriebssystem eines Validators kompromittiert ist, sollte der Angreifer nicht in der Lage sein, private Schlüssel zu extrahieren oder Nachrichten aus der Enklave zu fälschen. TEEs können erzwingen, dass Bridge-Transaktionen genau gemäß den Protokollregeln verarbeitet werden, wodurch das Risiko verringert wird, dass menschliche Bediener oder Malware betrügerische Übertragungen einschleusen. Darüber hinaus können TEEs atomare Swaps und Cross-Chain-Transaktionen in einer sicheren Enklave ermöglichen, die entweder beide Seiten abschließt oder sauber abbricht, wodurch Szenarien verhindert werden, in denen Gelder aufgrund von Störungen stecken bleiben. Mehrere Bridge-Projekte und Konsortien haben TEE-basierte Sicherheit erforscht, um die Plage der Bridge-Hacks der letzten Jahre zu mildern.

Datenintegrität und Verifizierbarkeit Off-Chain

In allen 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 Attestierung) und sicherstellen kann, dass der Code ohne Störungen 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, vorausgesetzt, die Attestierung ist korrekt. Diese Integritätsgarantie ist der Grund, warum TEEs manchmal als „Vertrauensanker“ für Off-Chain-Daten und -Berechnungen bezeichnet werden.

Es ist jedoch zu beachten, 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 die Attestierung gefälscht wird, könnte die Integrität fehlschlagen. Dennoch erschweren TEEs (wenn sie auf dem neuesten Stand gehalten werden) in der Praxis bestimmte Angriffe erheblich. Zum Beispiel könnte eine DeFi-Kreditplattform eine TEE verwenden, um Kreditscores aus den privaten Daten eines Benutzers Off-Chain zu berechnen, und der Smart Contract würde den Score nur akzeptieren, wenn er von einer gültigen Enklaven-Attestierung begleitet wird. Auf diese Weise weiß der Vertrag, dass der Score vom genehmigten Algorithmus auf echten Daten berechnet wurde, anstatt dem Benutzer oder einem Oracle blind zu vertrauen.

TEEs spielen auch eine Rolle in aufkommenden dezentralen Identitäts- (DID) und Authentifizierungssystemen. 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 preisgegeben werden. Zum Beispiel könnte eine TEE auf einem mobilen Gerät die biometrische Authentifizierung handhaben und eine Blockchain-Transaktion signieren, wenn die biometrische Überprüfung erfolgreich ist, alles ohne die Biometrie des Benutzers preiszugeben. Dies bietet sowohl Sicherheit als auch Datenschutz im Identitätsmanagement – eine wesentliche Komponente, wenn Web3 Dinge wie Pässe, Zertifikate oder KYC-Daten auf benutzerautonome Weise handhaben soll.

Zusammenfassend dienen TEEs als vielseitiges Werkzeug in Web3: Sie ermöglichen Vertraulichkeit für On-Chain-Logik, erlauben Skalierung durch sichere Off-Chain-Berechnungen, schützen die Integrität von Oracles und Bridges und eröffnen neue Anwendungsbereiche (von privater Identität bis hin zu konformer Datenfreigabe). Als Nächstes werden wir uns spezifische Projekte ansehen, die diese Fähigkeiten nutzen.

3. Bemerkenswerte Web3-Projekte, die TEEs nutzen

Eine Reihe führender Blockchain-Projekte haben ihre Kernangebote um Trusted Execution Environments herum aufgebaut. Im Folgenden tauchen wir in einige bemerkenswerte ein und untersuchen, wie jedes die TEE-Technologie nutzt und welchen einzigartigen Wert es hinzufügt:

Secret Network

Secret Network ist eine Layer-1-Blockchain (auf Basis des Cosmos SDK), die Pionierarbeit bei datenschutzfreundlichen Smart Contracts mittels TEEs geleistet hat. Alle Validator-Nodes im Secret Network betreiben Intel SGX-Enklaven, die den Smart-Contract-Code ausführen, sodass der Vertragsstatus sowie Eingaben/Ausgaben selbst für die Node-Betreiber verschlüsselt bleiben. Dies macht Secret zu einer der ersten Privacy-First Smart Contract-Plattformen – Datenschutz ist kein optionales Add-on, sondern eine Standardfunktion des Netzwerks auf Protokollebene.

Im Modell von Secret Network übermitteln Benutzer verschlüsselte Transaktionen, die Validatoren zur Ausführung in ihre SGX-Enklave laden. Die Enklave entschlüsselt die Eingaben, führt den Vertrag (geschrieben in einer modifizierten CosmWasm-Laufzeitumgebung) aus und erzeugt verschlüsselte Ausgaben, die in die Blockchain geschrieben werden. Nur Benutzer mit dem korrekten Viewing Key (oder der Vertrag selbst mit seinem internen Schlüssel) können die tatsächlichen Daten entschlüsseln und einsehen. Dies ermöglicht 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, wodurch Front-Running gemindert und Handelsstrategien geschützt werden. Liquiditätsanbieter und Händler können agieren, ohne jeden ihrer Schritte an Wettbewerber zu senden.
• Geheime Auktionen: Auktionsverträge, bei denen Gebote bis zum Auktionsende geheim gehalten werden, um strategisches Verhalten basierend auf den Geboten anderer zu verhindern.
• Private Abstimmung und Governance: Token-Inhaber können über Vorschläge abstimmen, ohne ihre Stimmabgabe preiszugeben, während die Auszählung weiterhin verifiziert werden kann – was eine faire, einschüchterungsfreie Governance gewährleistet.
• Datenmarktplätze: Sensible Datensätze können transaktiert und in Berechnungen verwendet werden, ohne die Rohdaten Käufern oder Nodes preiszugeben.

Secret Network integriert TEEs im Wesentlichen auf Protokollebene, um ein einzigartiges Wertversprechen zu schaffen: Es bietet programmierbaren Datenschutz. Zu den Herausforderungen, die sie angehen, gehören die Koordination der Enklaven-Attestierung über einen dezentralen Validatoren-Satz hinweg und die Verwaltung der Schlüsselverteilung, damit Verträge Eingaben entschlüsseln können, während sie diese vor Validatoren geheim halten. Nach allen Berichten hat Secret die Machbarkeit TEE-gestützter Vertraulichkeit auf einer öffentlichen Blockchain bewiesen und sich als führend in diesem Bereich etabliert.

Oasis Network

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

Die Nutzung von TEEs durch Oasis konzentriert sich auf vertrauliche Berechnungen in großem Maßstab. Durch die Isolation der rechenintensiven Aufgaben in parallelisierbaren ParaTimes (die auf vielen Nodes laufen können) erreichen sie einen hohen Durchsatz, und durch die Verwendung von TEEs innerhalb dieser ParaTime-Nodes stellen sie sicher, dass die Berechnungen sensible Daten enthalten können, ohne diese preiszugeben. Zum Beispiel 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 Node verschlüsselt (da sie in der Enklave verarbeitet werden), und nur der Score wird ausgegeben. Währenddessen zeichnet der Oasis-Konsens lediglich den Nachweis auf, dass die Berechnung korrekt erfolgte.

Technisch gesehen hat Oasis zusätzliche Sicherheitsebenen über das reine SGX hinaus hinzugefügt. Sie implementierten einen „geschichteten Vertrauensanker“: unter Verwendung von Intels SGX Quoting Enclave und einem benutzerdefinierten, leichtgewichtigen Kernel, um die Hardware-Vertrauenswürdigkeit zu überprüfen und die Systemaufrufe der Enklave zu isolieren (sandboxing). Dies reduziert die Angriffsfläche (durch Filtern, welche OS-Aufrufe Enklaven tätigen können) und schützt vor bestimmten bekannten SGX-Angriffen. Oasis führte auch Funktionen wie dauerhafte Enklaven (damit Enklaven ihren Zustand über Neustarts hinweg beibehalten können) und sichere Protokollierung ein, um Rollback-Angriffe zu mindern (bei denen ein Node versuchen könnte, einen alten Enklaven-Zustand erneut abzuspielen). Diese Innovationen wurden in ihren technischen Papieren beschrieben und sind ein Grund, warum Oasis als forschungsgetriebenes Projekt im Bereich TEE-basierter Blockchain-Berechnungen angesehen wird.

Aus Ökosystem-Perspektive hat sich Oasis für Dinge wie privates DeFi (das Banken die Teilnahme ermöglicht, ohne Kundendaten preiszugeben) und Datentokenisierung (wo Einzelpersonen oder Unternehmen Daten vertraulich an KI-Modelle weitergeben und über die Blockchain entschädigt werden können) positioniert. Sie haben auch mit Unternehmen an Pilotprojekten zusammengearbeitet (zum Beispiel mit BMW zum Thema Datenschutz und mit anderen zum Austausch 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 wichtigen 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 hochleistungsfähige Rechenservices bereitzustellen. Es ist eine Parachain auf Polkadot, was bedeutet, dass es von Polkadots Sicherheit und Interoperabilität profitiert, aber es führt seine eigene neuartige Laufzeitumgebung für Off-Chain-Berechnungen in sicheren Enklaven ein.

Die Kernidee von Sanders ist es, ein großes Netzwerk von Worker-Nodes (genannt Sanders-Miner) zu unterhalten, die Aufgaben innerhalb von TEEs (bisher speziell Intel SGX) ausführen und verifizierbare Ergebnisse produzieren. Diese Aufgaben können von der Ausführung von Smart-Contract-Segmenten bis hin zu allgemeinen Berechnungen reichen, die von Benutzern angefordert werden. Da die Worker in SGX laufen, stellt Sanders sicher, 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 sie nicht einsehen oder manipulieren kann.

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

• Web3-Analysen und KI: Ein Projekt könnte Benutzerdaten analysieren oder KI-Algorithmen in Sanders-Enklaven ausführen, sodass Rohdaten der Benutzer verschlüsselt bleiben (Datenschutz), während nur aggregierte Erkenntnisse die Enklave verlassen.
• Game-Backends und Metaverse: Sanders kann intensive Spiellogik oder Simulationen virtueller Welten Off-Chain verarbeiten, indem es nur Commitments oder Hashes an die Blockchain sendet, was ein reichhaltigeres Gameplay ohne Vertrauen in einen einzelnen Server ermöglicht.
• On-Chain-Dienste: Sanders hat eine Off-Chain-Berechnungsplattform namens Sanders Cloud aufgebaut. Zum Beispiel kann sie als Backend für Bots, dezentrale Webdienste oder sogar ein Off-Chain-Orderbuch dienen, das Trades mit TEE-Attestierung an einen DEX-Smart Contract veröffentlicht.

Sanders betont, dass es vertrauliche Berechnungen horizontal skalieren kann: Mehr Kapazität benötigt? Fügen Sie weitere TEE-Worker-Nodes hinzu. Dies unterscheidet sich von einer einzelnen Blockchain, bei der die Rechenkapazität durch 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 integriert sich in Polkadots Konsens (z. B. Staking und Slashing für schlechte Ergebnisse) und erforscht sogar eine Kombination von TEE mit Zero-Knowledge-Proofs (wie erwähnt, verwendet ihr kommendes L2 TEE, um die Ausführung zu beschleunigen und ZKP, um sie prägnant auf Ethereum zu verifizieren). Dieser hybride Ansatz hilft, das Risiko einer einzelnen TEE-Kompromittierung zu mindern, indem er kryptografische Verifizierung hinzufügt.

Zusammenfassend nutzt Sanders Network TEEs, um eine dezentrale, vertrauliche Cloud für Web3 bereitzustellen, die Off-Chain-Berechnungen mit Sicherheitsgarantien ermöglicht. Dies eröffnet eine Klasse von Blockchain-Anwendungen, die sowohl hohe Rechenleistung als auch Datenvertraulichkeit benötigen und die Lücke zwischen On-Chain- und Off-Chain-Welten schließen.

iExec

iExec ist ein dezentraler Marktplatz für Cloud-Computing-Ressourcen, der auf Ethereum aufgebaut ist. Im Gegensatz zu den drei vorherigen (die eigene Chains oder Parachains sind) operiert iExec als Layer-2- oder Off-Chain-Netzwerk, das mit Ethereum-Smart Contracts koordiniert. TEEs (insbesondere Intel SGX) sind ein Eckpfeiler von iExecs Ansatz, Vertrauen in Off-Chain-Berechnungen herzustellen.

Das iExec-Netzwerk besteht aus Worker-Nodes, die von verschiedenen Anbietern bereitgestellt werden. Diese Worker können von Benutzern (dApp-Entwicklern, Datenanbietern usw.) angeforderte Aufgaben ausführen. Um sicherzustellen, dass diese Off-Chain-Berechnungen vertrauenswürdig sind, führte iExec ein Framework namens „Trusted Off-Chain Computing“ ein: 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 Node ausgeführt wurde. iExec hat sich mit Intel zusammengetan, um diese vertrauenswürdige Computing-Funktion einzuführen, und ist sogar dem Confidential Computing Consortium beigetreten, um Standards voranzutreiben. Ihr Konsensprotokoll, genannt 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 kann die Attestierung einer einzelnen Enklave ausreichen, wenn der Code deterministisch ist und das Vertrauen in SGX hoch ist; für eine höhere Sicherheit kann iExec Aufgaben über mehrere TEEs replizieren und einen Konsens oder eine Mehrheitsentscheidung 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-Node könnte Rohdaten abrufen und 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ückzugeben. Dies erweitert die Möglichkeiten von Oracles über das bloße Weiterleiten von Daten hinaus – sie können nun berechnete Dienste (wie das Aufrufen eines KI-Modells oder das Aggregieren vieler Quellen) anbieten, wobei TEE die Ehrlichkeit gewährleistet.
• KI und DePIN (Dezentrales Physisches Infrastrukturnetzwerk): iExec positioniert sich als Vertrauensschicht für dezentrale KI-Anwendungen. Zum Beispiel kann eine dApp, die ein Machine-Learning-Modell verwendet, das Modell in einer Enklave ausführen, um sowohl das Modell (wenn es proprietär ist) als auch die eingegebenen Benutzerdaten zu schützen. Im Kontext von DePIN (wie verteilten IoT-Netzwerken) können TEEs auf Edge-Geräten verwendet werden, um Sensorwerte und Berechnungen auf diesen Werten zu vertrauen.
• Sichere Datenmonetarisierung: Datenanbieter können ihre Datensätze auf dem iExec-Marktplatz in verschlüsselter Form zur Verfügung stellen. Käufer können ihre Algorithmen zur Ausführung auf den Daten innerhalb einer TEE senden (sodass die Rohdaten des Datenanbieters niemals offengelegt werden, ihr geistiges Eigentum geschützt wird und die Details des Algorithmus ebenfalls 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, oft als sicherer Datenaustausch bezeichnet, wird durch die Vertraulichkeit von TEEs ermöglicht.

Insgesamt stellt iExec die Verbindung zwischen Ethereum-Smart Contracts und sicherer Off-Chain-Ausführung her. Es demonstriert, wie TEE-„Worker“ vernetzt werden können, um eine dezentrale Cloud zu bilden, komplett mit einem Marktplatz (der iExecs RLC-Token zur Zahlung verwendet) und Konsensmechanismen. Durch die Leitung der Trusted Compute-Arbeitsgruppe der Enterprise Ethereum Alliance und die Mitwirkung an Standards (wie Hyperledger Avalon) treibt iExec auch die breitere Akzeptanz von TEEs in Unternehmens-Blockchain-Szenarien voran.

Andere Projekte und Ökosysteme

Über die vier oben genannten hinaus gibt es noch einige weitere Projekte, die erwähnenswert sind:

• Integritee – eine weitere Polkadot-Parachain, ähnlich wie Sanders (tatsächlich entstand sie aus der TEE-Arbeit der Energy Web Foundation). Integritee nutzt TEEs, um „Parachain-as-a-Service“ für Unternehmen zu schaffen, indem es On-Chain- und Off-Chain-Enklaven-Verarbeitung kombiniert.
• Automata Network – ein Middleware-Protokoll für Web3-Datenschutz, das TEEs für private Transaktionen, anonyme Abstimmungen und MEV-resistente Transaktionsverarbeitung nutzt. Automata läuft als Off-Chain-Netzwerk und bietet Dienste wie ein privates RPC-Relay an und wurde erwähnt, TEEs für Dinge wie geschützte Identität und gaslose private Transaktionen zu verwenden.
• Hyperledger Sawtooth (PoET) – im Unternehmensbereich führte Sawtooth einen Konsensalgorithmus namens Proof of Elapsed Time ein, der auf SGX basierte. Jeder Validator betreibt eine Enklave, die eine zufällige Zeit wartet und einen Nachweis erzeugt; derjenige mit der kürzesten Wartezeit „gewinnt“ den Block, eine faire Lotterie, die von SGX durchgesetzt wird. Obwohl Sawtooth kein Web3-Projekt im eigentlichen Sinne ist (eher eine Unternehmens-Blockchain), ist es eine kreative Nutzung von TEEs für den Konsens.
• Unternehmens-/Konsortialketten – Viele Blockchain-Lösungen für Unternehmen (z. B. ConsenSys Quorum, IBM Blockchain) integrieren TEEs, um vertrauliche Konsortialtransaktionen zu ermöglichen, bei denen nur autorisierte Nodes bestimmte Daten sehen. Zum Beispiel verwendet der Trusted Compute Framework (TCF)-Entwurf 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 untermauern sogar Konsensalgorithmen. Als Nächstes betrachten wir die umfassenderen Vorteile und Herausforderungen der Verwendung von TEEs in dezentralen Umgebungen.

4. Vorteile und Herausforderungen von TEEs in dezentralen Umgebungen

Die Einführung von Trusted Execution Environments in Blockchain-Systemen bringt erhebliche technische Vorteile sowie bemerkenswerte Herausforderungen und Kompromisse mit sich. Wir werden beide Seiten untersuchen: was TEEs dezentralen Anwendungen bieten und welche Probleme oder Risiken sich aus ihrer Verwendung ergeben.

Vorteile und technische Stärken

• Starke Sicherheit & Datenschutz: Der größte Vorteil sind die Garantien für Vertraulichkeit und Integrität. TEEs ermöglichen die Ausführung von sensiblem Code mit der Gewissheit, dass er nicht von externer Malware ausspioniert oder verändert wird. Dies schafft ein Vertrauensniveau in Off-Chain-Berechnungen, das zuvor nicht verfügbar war. Für die Blockchain bedeutet dies, dass private Daten genutzt werden können (wodurch die Funktionalität von dApps verbessert wird), ohne die Sicherheit zu opfern. Selbst in nicht vertrauenswürdigen Umgebungen (Cloud-Server, von Dritten betriebene Validator-Nodes) schützen TEEs Geheimnisse. Dies ist besonders vorteilhaft für die Verwaltung privater Schlüssel, Benutzerdaten und proprietärer Algorithmen innerhalb von Krypto-Systemen. Zum Beispiel könnte eine Hardware-Wallet oder ein Cloud-Signaturdienst eine TEE verwenden, um Blockchain-Transaktionen intern zu signieren, sodass der private Schlüssel niemals im Klartext offengelegt wird, was Komfort mit Sicherheit verbindet.

• Nahezu native Leistung: Im Gegensatz zu rein kryptografischen Ansätzen zur sicheren Berechnung (wie ZK-Proofs oder homomorphe Verschlüsselung) ist der TEE-Overhead relativ gering. Code läuft direkt auf der CPU, sodass eine Berechnung innerhalb einer Enklave ungefähr so schnell ist wie außerhalb (mit etwas Overhead für Enklaven-Übergänge und Speicherverschlüsselung, typischerweise einstellige prozentuale Verlangsamungen bei SGX). Dies bedeutet, dass TEEs rechenintensive Aufgaben effizient bewältigen können, was Anwendungsfälle (wie Echtzeit-Datenfeeds, komplexe Smart Contracts, maschinelles Lernen) ermöglicht, die bei kryptografischen Protokollen um Größenordnungen langsamer wären. Die geringe Latenz von Enklaven macht sie dort geeignet, wo eine schnelle Reaktion erforderlich ist (z. B. Hochfrequenz-Handelsbots, die durch TEEs gesichert sind, oder interaktive Anwendungen und Spiele, bei denen die Benutzererfahrung unter hohen Verzögerungen leiden würde).

• Verbesserte Skalierbarkeit (durch Auslagerung): Indem TEEs es ermöglichen, rechenintensive Berechnungen sicher Off-Chain durchzuführen, helfen sie, Überlastungen und Gaskosten auf Hauptketten zu reduzieren. Sie ermöglichen Layer-2-Designs und Seitenprotokolle, 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 On-Chain) kann den Durchsatz und die Skalierbarkeit dezentraler Anwendungen drastisch verbessern. Zum Beispiel könnte eine DEX das Matchmaking in einer TEE Off-Chain durchführen und nur die gematchten Trades On-Chain veröffentlichen, wodurch der Durchsatz erhöht und das On-Chain-Gas reduziert wird.

• Bessere Benutzererfahrung & Funktionalität: Mit TEEs können dApps Funktionen wie Vertraulichkeit oder komplexe Analysen anbieten, die mehr Benutzer (einschließlich Institutionen) anziehen. TEEs ermöglichen auch gaslose oder Meta-Transaktionen, indem sie diese sicher Off-Chain ausführen und dann Ergebnisse übermitteln, wie in Automatas Verwendung von TEEs zur Reduzierung des Gasverbrauchs für private Transaktionen festgestellt. Darüber hinaus kann das Speichern sensibler Zustände Off-Chain in einer Enklave die On-Chain veröffentlichten Daten reduzieren, was gut für den Datenschutz der Benutzer und die Netzwerkeffizienz ist (weniger On-Chain-Daten zum Speichern/Verifizieren).

• Kompatibilität mit anderen Technologien: Interessanterweise können TEEs andere Technologien ergänzen (nicht streng genommen ein Vorteil, der TEEs allein innewohnt, sondern in Kombination). Sie können als Bindeglied dienen, das hybride Lösungen zusammenhält: z. B. das Ausführen eines Programms in einer Enklave und gleichzeitig das Generieren eines ZK-Proofs seiner Ausführung, wobei die Enklave bei Teilen des Beweisprozesses hilft, 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 TEE liegt darin, andere zu unterstützen, nicht sie zu ersetzen“).

Vertrauensannahmen und Sicherheitslücken

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

• Hardware-Vertrauen und Zentralisierung: Durch die Verwendung von TEEs vertraut man zwangsläufig dem Siliziumhersteller und der Sicherheit seines Hardware-Designs und seiner Lieferkette. Die Verwendung von Intel SGX bedeutet beispielsweise, darauf zu vertrauen, dass Intel keine Hintertüren hat, dass die Fertigung sicher ist und dass der Mikrocode der CPU die Enklaven-Isolation korrekt implementiert. Dies ist ein stärker zentralisiertes Vertrauensmodell im Vergleich zur reinen Kryptografie (die auf mathematischen Annahmen basiert, die unter allen Benutzern verteilt sind). Darüber hinaus basiert die Attestierung für SGX historisch auf der Kontaktaufnahme mit Intels Attestation Service, was bedeutet, dass Enklaven weltweit betroffen sein könnten, wenn Intel offline ginge oder beschließen würde, Schlüssel zu widerrufen. Diese Abhängigkeit von der Infrastruktur eines einzelnen Unternehmens wirft Bedenken auf: Es könnte ein Single Point of Failure sein oder sogar Ziel staatlicher Regulierung (z. B. könnten US-Exportkontrollen theoretisch einschränken, wer starke TEEs verwenden darf). AMD SEV mildert dies, indem es eine dezentralere Attestierung ermöglicht (VM-Besitzer können ihre VMs attestieren), vertraut aber immer noch dem Chip und der Firmware von AMD. Das Zentralisierungsrisiko wird oft als etwas der Dezentralisierung der Blockchain Entgegengesetztes angeführt. Projekte wie Keystone (Open-Source-TEE) und andere erforschen Wege, die Abhängigkeit von proprietären Black Boxes zu reduzieren, aber diese sind noch nicht Mainstream.

• Seitenkanal- und andere Schwachstellen: Eine TEE ist kein Allheilmittel; sie kann durch indirekte Mittel angegriffen werden. Seitenkanalangriffe nutzen die Tatsache aus, dass selbst wenn der direkte Speicherzugriff blockiert ist, der Betrieb einer Enklave das System subtil beeinflussen könnte (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-Leckage) über Plundervolt (Spannungsfehlerinjektion über privilegierte Anweisungen) bis hin zu SGAxe (Extrahieren von Attestierungsschlüsseln) und anderen. Diese ausgeklügelten Angriffe zeigen, dass TEEs kompromittiert werden können, ohne kryptografische Schutzmaßnahmen brechen zu müssen – stattdessen durch Ausnutzung mikroarchitektonischer Verhaltensweisen oder Implementierungsfehler. 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. kann das Entkapseln des Chips, das Abgreifen von Bussen usw. die meisten kommerziellen TEEs überwinden).

  Die Reaktionen der Anbieter auf Seitenkanal-Entdeckungen waren Mikrocode-Patches und Enklaven-SDK-Updates, um bekannte Lecks zu mindern (manchmal auf Kosten der Leistung). Aber es bleibt ein Katz-und-Maus-Spiel. Für Web3 bedeutet dies, dass, wenn jemand einen neuen Seitenkanal auf SGX findet, ein „sicherer“ DeFi-Vertrag, der in SGX läuft, potenziell ausgenutzt werden könnte (z. B. um geheime Daten preiszugeben 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 dagegen zu stärken (z. B. durch das Design von Enklaven-Code mit konstanten Zeitoperationen, die Vermeidung von geheimnisabhängigen Speicherzugriffsmustern und die Verwendung von Techniken wie Oblivious RAM). Einige Projekte ergänzen TEEs auch mit sekundären Prüfungen – z. B. durch Kombination mit ZK-Proofs oder durch das Ausführen mehrerer Enklaven auf verschiedenen Hardware-Anbietern, um das Risiko eines einzelnen Chip-Kompromisses zu reduzieren.

• Leistungs- und Ressourcenbeschränkungen: Obwohl TEEs für CPU-gebundene Aufgaben mit nahezu nativer Geschwindigkeit laufen, bringen sie einige Overheads und Grenzen mit sich. Das Umschalten in eine Enklave (ein ECALL) und aus ihr heraus (OCALL) ist mit Kosten verbunden, ebenso wie die Ver-/Entschlüsselung von Speicherseiten. Dies kann die Leistung bei sehr häufigen Enklaven-Grenzüberschreitungen beeinträchtigen. Enklaven haben oft auch Speichergrößenbeschränkungen. Zum Beispiel hatte frühes SGX einen begrenzten Enclave Page Cache, und wenn Enklaven mehr Speicher verwendeten, mussten Seiten (mit Verschlüsselung) ausgelagert werden, was die Leistung massiv verlangsamte. Selbst neuere TEEs erlauben oft nicht die einfache Nutzung des gesamten System-RAMs – es gibt einen sicheren Speicherbereich, der möglicherweise begrenzt ist. Dies bedeutet, dass sehr große Berechnungen oder Datensätze schwierig vollständig innerhalb einer TEE zu handhaben sein könnten. 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 den Speicher optimieren und möglicherweise Workloads aufteilen.

• Komplexität von Attestierung und Schlüsselverwaltung: Die Verwendung von TEEs in einer dezentralen Umgebung erfordert robuste Attestierungs-Workflows: Jeder Node muss anderen beweisen, dass er eine authentische Enklave mit erwartetem Code ausführt. Das Einrichten dieser On-Chain-Attestierungsprüfung kann komplex sein. Es beinhaltet normalerweise das Hardcodieren des öffentlichen Attestierungsschlüssels oder Zertifikats des Anbieters in das Protokoll und das Schreiben von Verifizierungslogik in Smart Contracts oder Off-Chain-Clients. Dies führt zu Overhead im Protokolldesign, und Änderungen (wie Intel, das sein Attestierungs-Signaturschlüsselformat von EPID auf DCAP ändert) können Wartungsaufwand verursachen. Zusätzlich 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 in der Enklaven-Schlüsselverwaltung könnten die Sicherheit untergraben (z. B. wenn eine Enklave versehentlich einen Entschlüsselungsschlüssel durch einen Fehler preisgibt, brechen alle ihre Vertraulichkeitsversprechen zusammen). Best Practices beinhalten die Verwendung der Sealing-APIs der TEE, um Schlüssel sicher zu speichern und Schlüssel bei Bedarf zu rotieren, aber auch dies erfordert eine sorgfältige Entwicklung durch die Entwickler.

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

Kompatibilität und Ökosystem-Einschränkungen

• Begrenzte Kompatibilität mit anderen Verträgen: Auf einer öffentlichen Smart-Contract-Plattform wie Ethereum können Verträge andere Verträge leicht aufrufen, und der gesamte Zustand ist offen, was DeFi-Geld-Legos und eine reichhaltige Komposition ermöglicht. In einem TEE-basierten Vertragsmodell kann der private Zustand nicht frei geteilt oder komponiert werden, ohne die Vertraulichkeit zu verletzen. Wenn zum Beispiel Vertrag A in einer Enklave mit Vertrag B interagieren muss und beide geheime Daten enthalten, wie arbeiten sie dann zusammen? Entweder müssen sie ein komplexes sicheres Mehrparteienprotokoll durchführen (was die Einfachheit von TEEs teilweise aufhebt) oder sie werden zu einer Enklave kombiniert (was die Modularität reduziert). Dies ist eine Herausforderung, der sich Secret Network und andere stellen müssen: Cross-Contract-Aufrufe mit Datenschutz sind nicht trivial. Einige Lösungen beinhalten, dass eine einzelne Enklave die Ausführung mehrerer Verträge handhabt, sodass sie intern gemeinsame Geheimnisse verwalten kann, aber das kann das System monolithischer machen. Daher ist die Kompatibilität privater Verträge begrenzter als die öffentlicher, oder erfordert neue Designmuster. Ähnlich erfordert die Integration von TEE-basierten Modulen in bestehende Blockchain-dApps ein sorgfältiges Interface-Design – oft wird nur das Ergebnis einer Enklave On-Chain veröffentlicht, was ein Snark oder ein Hash sein könnte, und andere Verträge können nur diese begrenzten Informationen verwenden. Dies ist sicherlich ein Kompromiss; Projekte wie Secret bieten Viewing Keys und erlauben das Teilen von Geheimnissen nach dem Need-to-know-Prinzip, aber es ist nicht so nahtlos wie die normale On-Chain-Kompatibilität.

• Standardisierung und Interoperabilität: Das TEE-Ökosystem verfügt derzeit nicht über einheitliche Standards über verschiedene Anbieter hinweg. Intel SGX, AMD SEV, ARM TrustZone haben alle unterschiedliche Programmiermodelle und Attestierungsmethoden. Diese Fragmentierung bedeutet, dass eine für SGX-Enklaven geschriebene dApp nicht trivial 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-Nodes (z. B. Validatoren auf Mobilgeräten) unterstützen möchten, würde dies zusätzliche Entwicklung und möglicherweise 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 so weit. Der Mangel an Standards wirkt sich auch auf die Entwickler-Tools aus – man mag das SGX SDK als ausgereift empfinden, muss sich dann aber an eine andere TEE mit einem anderen SDK anpassen. Diese Interoperabilitätsherausforderung kann die Akzeptanz verlangsamen und die Kosten erhöhen.

• Entwickler-Lernkurve: Das Erstellen von Anwendungen, die innerhalb von TEEs laufen, erfordert spezialisiertes Wissen, das viele Blockchain-Entwickler möglicherweise nicht besitzen. Oft sind Low-Level-C/C++-Programmierung (für SGX/TrustZone) oder Kenntnisse über Speichersicherheit und seitenkanalresistente Codierung erforderlich. Das Debuggen von Enklaven-Code ist bekanntermaßen schwierig (man kann aus Sicherheitsgründen während der Ausführung nicht einfach in eine Enklave hineinsehen!). Obwohl Frameworks und höhere Programmiersprachen (wie die Verwendung von Rust durch Oasis für ihre vertrauliche Laufzeitumgebung oder sogar Tools zum Ausführen von WebAssembly in Enklaven) existieren, ist die Entwicklererfahrung immer noch rauer als bei der typischen Smart-Contract-Entwicklung oder Off-Chain-Web2-Entwicklung. Diese steile Lernkurve und unreife Tools können Entwickler abschrecken oder zu Fehlern führen, wenn sie nicht sorgfältig gehandhabt werden. Es gibt auch den Aspekt, dass Hardware zum Testen benötigt wird – das Ausführen von SGX-Code erfordert eine SGX-fähige CPU oder einen Emulator (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 knapper macht als beispielsweise in der etablierten 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). Es gibt auch Overhead im Betrieb: Firmware auf dem neuesten Stand halten (für Sicherheitspatches), Attestierungsnetzwerke verwalten usw., was kleine Projekte als belastend empfinden könnten. Wenn jeder Node eine bestimmte CPU haben muss, könnte dies den potenziellen Validatoren-Pool reduzieren (nicht jeder hat die erforderliche Hardware), wodurch die Dezentralisierung beeinträchtigt und möglicherweise eine höhere Nutzung von Cloud-Hosting verursacht wird.

Zusammenfassend lässt sich sagen, dass TEEs zwar leistungsstarke Funktionen freischalten, aber auch Vertrauenskompromisse (Hardware-Vertrauen vs. Mathematik-Vertrauen), potenzielle Sicherheitslücken (insbesondere Seitenkanäle) und Integrationshürden in einem dezentralen Kontext mit sich bringen. Projekte, die TEEs verwenden, müssen diese Probleme sorgfältig umgehen – indem sie eine tiefgehende Verteidigung einsetzen (nicht davon ausgehen, dass die TEE unzerbrechlich ist), die vertrauenswürdige Computing-Basis minimal halten und transparent über die Vertrauensannahmen gegenüber den Benutzern sind (damit klar ist, dass man beispielsweise zusätzlich zum Blockchain-Konsens der Hardware von Intel vertraut).

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

Trusted Execution Environments sind ein Ansatz, um Datenschutz und Sicherheit in Web3 zu erreichen, aber es gibt andere wichtige Techniken, darunter Zero-Knowledge Proofs (ZKPs), Fully Homomorphic Encryption (FHE) und Secure Multi-Party Computation (MPC). Jede dieser Technologien hat 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 Kompromisse in Bezug auf Leistung, Vertrauen und Entwicklerfreundlichkeit zu vergleichen:

Um die Alternativen kurz zu definieren:

• ZKPs: Kryptografische Beweise (wie zk-SNARKs, zk-STARKs), die es einer Partei ermöglichen, anderen zu beweisen, dass eine Aussage wahr ist (z. B. „Ich kenne ein Geheimnis, das diese Berechnung erfüllt“), ohne preiszugeben, warum sie wahr ist (indem die geheime Eingabe verborgen bleibt). In der Blockchain werden ZKPs für private Transaktionen (z. B. Zcash, Aztec) und für die Skalierbarkeit (Rollups, die Beweise für die korrekte Ausführung veröffentlichen) verwendet. Sie gewährleisten starken Datenschutz (es werden keine geheimen Daten preisgegeben, nur Beweise) und Integrität, die durch Mathematik garantiert wird, aber die Generierung dieser Beweise kann rechnerisch aufwendig sein, und die Schaltkreise müssen sorgfältig entworfen werden.
• FHE: Verschlüsselungsschema, das beliebige Berechnungen auf verschlüsselten Daten ermöglicht, sodass das Ergebnis nach der Entschlüsselung mit dem Ergebnis der Berechnung auf Klartextdaten übereinstimmt. Theoretisch bietet FHE ultimative Privatsphäre – Daten bleiben jederzeit verschlüsselt – und man muss niemandem die Rohdaten anvertrauen. Aber FHE ist für allgemeine Berechnungen extrem langsam (obwohl es sich durch Forschung verbessert); es wird aufgrund der Leistung immer noch hauptsächlich experimentell oder spezialisiert eingesetzt.
• MPC: Protokolle, bei denen mehrere Parteien gemeinsam eine Funktion über ihre privaten Eingaben berechnen, ohne diese Eingaben einander preiszugeben. Es beinhaltet oft die Geheimnisverteilung von Daten unter den Parteien und die Durchführung kryptografischer Operationen, sodass die Ausgabe korrekt ist, aber individuelle Eingaben verborgen bleiben. MPC kann Vertrauen verteilen (kein einzelner Punkt sieht alle Daten) und kann für bestimmte Operationen effizient sein, verursacht aber typischerweise einen Kommunikations- und Koordinations-Overhead und kann für große Netzwerke komplex zu implementieren sein.

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

Technologie	Vertrauensmodell	Leistung	Datenschutz	Entwicklerfreundlichkeit
TEE (Intel SGX, etc.)	Vertrauen in den Hardwarehersteller (in einigen Fällen zentralisierter Attestierungsserver). Geht davon aus, 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 Verfügbarkeit TEE-fähiger Nodes.	Daten sind im Klartext innerhalb der Enklave, aber für die Außenwelt verschlüsselt. Starke Vertraulichkeit, wenn die Hardware hält, aber wenn die Enklave verletzt wird, sind Geheimnisse exponiert (kein zusätzlicher mathematischer Schutz).	Moderate Komplexität. Kann oft bestehenden Code/Sprachen (C, Rust) wiederverwenden und mit geringfügigen Änderungen in der Enklave ausführen. Niedrigste Einstiegshürde unter diesen – keine Notwendigkeit, fortgeschrittene Kryptografie zu lernen – erfordert aber Systemprogrammierung und TEE-spezifisches SDK-Wissen.
ZKP (zk-SNARK/STARK)	Vertrauen in mathematische Annahmen (z. B. Härte kryptografischer Probleme) und manchmal ein Trusted Setup (für SNARKs). Keine Abhängigkeit von einer einzelnen Partei zur Laufzeit.	Die Beweisgenerierung ist rechnerisch aufwendig (insbesondere für komplexe Programme), oft um Größenordnungen langsamer als nativ. Die Verifizierung On-Chain 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 Engpass.	Sehr starker Datenschutz – kann die Korrektheit beweisen, ohne private Eingaben preiszugeben. Nur minimale Informationen (wie die Beweisgröße) werden geleakt. Ideal für finanzielle Privatsphäre usw.	Hohe Komplexität. Erfordert das Erlernen spezialisierter Sprachen (Schaltkreise, zkDSLs wie Circom oder Noir) und das Denken in arithmetischen Schaltkreisen. Debugging ist schwierig. Weniger Experten verfügbar.
FHE	Vertrauen in die Mathematik (Gitterprobleme). Keine vertrauenswürdige Partei; Sicherheit gilt, solange die Verschlüsselung nicht gebrochen wird.	Sehr langsam für den allgemeinen Gebrauch. Operationen auf verschlüsselten Daten sind um mehrere Größenordnungen langsamer als Klartext. Skaliert etwas mit Hardwareverbesserungen und besseren Algorithmen, aber derzeit unpraktisch für den Echtzeiteinsatz in Blockchain-Kontexten.	Ultimativer Datenschutz – Daten bleiben während der gesamten Zeit verschlüsselt, auch während der Berechnung. Dies ist ideal für sensible Daten (z. B. medizinische, institutionsübergreifende Analysen), wenn die Leistung dies zulässt.	Sehr spezialisiert. Entwickler benötigen Krypto-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. Geht davon aus, dass eine Schwelle von Parteien ehrlich ist (keine Kollusion über eine bestimmte Anzahl hinaus). Kein Hardware-Vertrauen erforderlich. Vertrauensbruch, wenn zu viele kolludieren.	Typischerweise langsamer als nativ aufgrund von Kommunikationsrunden, aber oft schneller als FHE. Die Leistung variiert: einfache Operationen (Addieren, Multiplizieren) können effizient sein; komplexe Logik kann die Kommunikationskosten in die Höhe treiben. Die Latenz ist empfindlich gegenüber Netzwerkgeschwindigkeiten. Die Skalierbarkeit kann durch Sharding oder partielle Vertrauensannahmen verbessert werden.	Starker Datenschutz, wenn die Annahmen zutreffen – kein einzelner Node sieht die gesamte Eingabe. Aber einige Informationen können über die Ausgabe oder wenn Parteien ausfallen, durchsickern (außerdem fehlt die Prägnanz von ZK – man erhält das Ergebnis, aber keinen leicht teilbaren Beweis dafür, ohne das Protokoll erneut auszuführen).	Hohe Komplexität. Erfordert das Entwerfen eines benutzerdefinierten Protokolls für jeden Anwendungsfall oder die Verwendung von Frameworks (wie SPDZ oder das Angebot von Partisia). Entwickler müssen über kryptografische Protokolle nachdenken und oft die Bereitstellung mehrerer Nodes koordinieren. Die Integration in Blockchain-Apps kann komplex sein (erfordert Off-Chain-Runden).

Zitationen: Der obige Vergleich stützt sich auf Quellen wie die Analyse von Sanders Network und andere, die hervorheben, dass TEEs in Geschwindigkeit und Benutzerfreundlichkeit überzeugen, während ZK und FHE auf maximale Vertrauenslosigkeit auf Kosten hoher Rechenleistung abzielen und MPC Vertrauen verteilt, aber Netzwerk-Overhead einführt.

Aus der Tabelle werden einige wichtige Kompromisse deutlich:

• Leistung: TEEs haben einen großen Vorteil in Bezug auf Rohgeschwindigkeit und geringe Latenz. MPC kann oft moderate Komplexität mit einer gewissen Verlangsamung bewältigen, ZK ist langsam in der Erzeugung, aber schnell in der Verifizierung (asynchrone Nutzung), und FHE ist derzeit bei weitem die langsamste Option für beliebige Aufgaben (obwohl es für begrenzte Operationen wie einfache Additionen/Multiplikationen in Ordnung ist). 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 (vertrauen 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 vertrauen der Hardware und dem Anbieter. 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, besser mit dem dezentralen Ethos übereinzustimmen – keine besonderen Entitäten, denen man vertrauen muss, nur rechnerische Härte. MPC liegt dazwischen: Vertrauen ist dezentralisiert, aber nicht eliminiert (wenn N von M Nodes kolludieren, bricht der Datenschutz zusammen). Für maximale Vertrauenslosigkeit (z. B. ein wirklich zensurresistentes, dezentrales System) könnte man sich daher kryptografischen Lösungen zuwenden. Andererseits sind viele praktische Systeme damit einverstanden, anzunehmen, dass Intel ehrlich ist oder dass eine Reihe wichtiger Validatoren nicht kolludieren wird, und tauschen ein wenig Vertrauen gegen enorme Effizienzgewinne ein.

• Sicherheit/Schwachstellen: TEEs können, wie besprochen, durch Hardwarefehler 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 (auch 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 gehen von „ehrlichen, aber neugierigen“ Teilnehmern aus und könnten fehlschlagen, wenn jemand offen betrügt). Im Blockchain-Kontext könnte ein TEE-Bruch katastrophaler sein (alle Enklaven-basierten Verträge könnten gefährdet sein, bis sie gepatcht sind), während ein kryptografischer ZK-Bruch (wie die Entdeckung eines Fehlers in einer von einem ZK-Rollup verwendeten Hash-Funktion) ebenfalls katastrophal sein könnte, aber angesichts der einfacheren Annahme im Allgemeinen als weniger wahrscheinlich angesehen wird. Die Angriffsfläche ist sehr unterschiedlich: TEEs müssen sich um Dinge wie Leistungsanalyse kümmern, während ZK sich um mathematische Durchbrüche kümmern muss.

• Datenschutz: FHE und ZK bieten die stärksten Datenschutzgarantien – Daten bleiben kryptografisch geschützt. MPC stellt sicher, dass Daten geheim geteilt werden, sodass keine einzelne Partei sie sieht (obwohl einige Informationen durchsickern könnten, wenn Ausgaben öffentlich sind oder Protokolle nicht sorgfältig entworfen wurden). TEE hält Daten von außen privat, aber innerhalb der Enklave werden Daten entschlüsselt; wenn jemand irgendwie die Kontrolle über die Enklave erlangt, geht die Datenvertraulichkeit verloren. Außerdem erlauben TEEs dem Code typischerweise, alles mit den Daten zu tun (einschließlich unbeabsichtigter Leckage durch Seitenkanäle oder das Netzwerk, wenn der Code bösartig ist). TEEs erfordern also, dass Sie auch dem Enklaven-Code vertrauen, nicht nur der Hardware. Im Gegensatz dazu beweisen ZKPs Eigenschaften des Codes, ohne jemals Geheimnisse preiszugeben, sodass Sie dem Code nicht einmal vertrauen müssen (außer dass er tatsächlich die bewiesene Eigenschaft besitzt). Wenn eine Enklaven-Anwendung einen Fehler hätte, der Daten in eine Protokolldatei leckte, würde die TEE-Hardware dies nicht verhindern – während ein ZK-Beweissystem einfach nichts außer dem beabsichtigten Beweis preisgeben würde. Dies ist eine Nuance: TEEs schützen vor externen Angreifern, aber nicht unbedingt vor Logikfehlern im Enklaven-Programm selbst, während ZKs Design einen deklarativeren Ansatz erzwingt (man beweist genau das, was beabsichtigt ist und nichts weiter).

• Kompatibilität & Integration: TEEs lassen sich recht einfach in bestehende Systeme integrieren – man kann ein bestehendes Programm nehmen, es in eine Enklave legen und einige Sicherheitsvorteile erzielen, ohne das Programmiermodell zu stark zu ändern. ZK und FHE erfordern oft das Umschreiben des Programms in einen Schaltkreis oder eine restriktive Form, was ein enormer Aufwand sein kann. Zum Beispiel beinhaltet das Schreiben einer einfachen KI-Modellverifizierung in ZK die Transformation in eine Reihe von arithmetischen Operationen und Einschränkungen, was weit entfernt davon ist, einfach TensorFlow in einer TEE auszuführen und das Ergebnis zu attestieren. MPC kann ebenfalls ein benutzerdefiniertes Protokoll pro Anwendungsfall erfordern. Aus Sicht der Entwicklerproduktivität und Kosten sind TEEs daher attraktiv. Wir haben gesehen, dass TEEs in einigen Bereichen schneller angenommen wurden, gerade weil man bestehende Software-Ökosysteme nutzen kann (viele Bibliotheken laufen mit geringfügigen Anpassungen in Enklaven). ZK/MPC erfordern spezialisiertes Ingenieurwissen, das knapp ist. Die Kehrseite ist jedoch, dass TEEs eine Lösung liefern, die oft stärker isoliert ist (man muss dieser Enklave oder dieser Gruppe von Nodes vertrauen), während ZK einen Beweis liefert, den jeder On-Chain überprüfen kann, was ihn hochgradig kompatibel macht (jeder Vertrag kann einen zk-Proof verifizieren). ZK-Ergebnisse sind also portabel – sie erzeugen einen kleinen Beweis, den beliebig viele andere Verträge oder Benutzer nutzen können, um Vertrauen zu gewinnen. TEE-Ergebnisse liegen normalerweise in Form einer Attestierung vor, die an eine bestimmte Hardware gebunden und möglicherweise nicht prägnant ist; sie sind möglicherweise nicht so leicht teilbar oder kettenunabhängig (obwohl man eine Signatur des Ergebnisses veröffentlichen und Verträge so programmieren kann, dass sie diese akzeptieren, wenn sie den öffentlichen Schlüssel der Enklave kennen).

In der Praxis sehen wir hybride Ansätze: Zum Beispiel argumentiert Sanders Network, dass TEE, MPC und ZK jeweils in verschiedenen Bereichen glänzen und sich gegenseitig ergänzen können. Ein konkreter Fall ist die dezentrale Identität: Man könnte ZK-Proofs verwenden, um eine Identitätsberechtigung zu beweisen, ohne sie preiszugeben, aber diese Berechtigung könnte durch einen TEE-basierten Prozess überprüft und ausgestellt worden sein, der Ihre Dokumente privat geprüft hat. Oder betrachten Sie die Skalierung: ZK-Rollups liefern prägnante Beweise für viele Transaktionen, aber die Generierung dieser Beweise könnte durch die Verwendung von TEEs beschleunigt werden, um einige Berechnungen schneller durchzuführen (und dann nur eine kleinere Aussage zu beweisen). Die Kombination kann manchmal die Vertrauensanforderung an TEEs reduzieren (z. B. TEEs für die Leistung verwenden, aber die endgültige Korrektheit immer noch über einen ZK-Proof oder über ein On-Chain-Challenge-Spiel überprüfen, sodass eine kompromittierte TEE nicht betrügen kann, ohne erwischt zu werden). MPC kann mit TEEs kombiniert werden, indem der Rechen-Node jeder Partei eine TEE ist, was eine zusätzliche Schicht hinzufügt, sodass selbst wenn einige Parteien kolludieren, sie die Daten der anderen immer noch nicht sehen können, es sei denn, sie brechen auch die Hardware-Sicherheit.

Zusammenfassend bieten TEEs einen sehr praktischen und sofortigen Weg zu sicherer Berechnung mit moderaten Annahmen (Hardware-Vertrauen), während ZK und FHE einen eher theoretischen und vertrauenslosen Weg zu hohen Rechenkosten bieten und MPC einen verteilten Vertrauensweg mit Netzwerkkosten. Die richtige Wahl in Web3 hängt von den Anwendungsanforderungen ab:

• Wenn Sie schnelle, komplexe Berechnungen mit privaten Daten benötigen (wie KI, große Datensätze) – sind TEEs (oder MPC mit wenigen Parteien) derzeit der einzig praktikable Weg.
• Wenn Sie maximale Dezentralisierung und Verifizierbarkeit benötigen – glänzen ZK-Proofs (zum Beispiel bevorzugen private Kryptowährungstransaktionen ZKP wie bei Zcash, weil Benutzer nichts außer Mathematik vertrauen wollen).
• Wenn Sie kollaboratives Computing zwischen mehreren Stakeholdern benötigen – ist MPC natürlich geeignet (wie Mehrparteien-Schlüsselverwaltung oder Auktionen).
• Wenn Sie extrem sensible Daten haben und langfristiger Datenschutz ein Muss ist – könnte FHE attraktiv sein, wenn sich die Leistung verbessert, denn selbst wenn jemand Jahre später Ihre Chiffretexte erhält, erfahren sie ohne den Schlüssel nichts; wohingegen ein Enklaven-Kompromiss Geheimnisse rückwirkend preisgeben könnte, wenn Protokolle geführt wurden.

Es ist erwähnenswert, dass der Blockchain-Bereich all diese Technologien parallel aktiv erforscht. Wir werden wahrscheinlich Kombinationen sehen: z. B. Layer-2-Lösungen, die TEEs integrieren, um Transaktionen zu sequenzieren und dann einen ZKP zu verwenden, um zu beweisen, dass die TEE die Regeln befolgt hat (ein Konzept, das in einigen Ethereum-Forschungen untersucht wird), oder MPC-Netzwerke, die TEEs in jedem Node verwenden, um die Komplexität der MPC-Protokolle zu reduzieren (da jeder Node intern sicher ist und mehrere Parteien simulieren kann).

Letztendlich ist die Wahl zwischen TEEs, ZK, MPC und FHE keine Nullsummenentscheidung – jede zielt auf unterschiedliche Punkte im Dreieck von Sicherheit, Leistung und Vertrauenslosigkeit ab. Wie ein Artikel es formulierte, stehen alle vier vor einem „unmöglichen Dreieck“ aus Leistung, Kosten und Sicherheit – keine einzelne Lösung ist in allen Aspekten überlegen. Das optimale Design verwendet oft das richtige Werkzeug für den richtigen Teil des Problems.

6. Akzeptanz in wichtigen Blockchain-Ökosystemen

Trusted Execution Environments haben in verschiedenen Blockchain-Ökosystemen unterschiedliche Akzeptanzgrade erfahren, oft beeinflusst durch die Prioritäten dieser Gemeinschaften und die Einfachheit der Integration. Hier bewerten wir, wie TEEs in einigen der wichtigsten Ökosysteme genutzt (oder erforscht) werden: Ethereum, Cosmos und Polkadot, sowie andere.

Ethereum (und allgemeine Layer-1s)

Auf dem Ethereum-Mainnet selbst sind TEEs nicht Teil des Kernprotokolls, wurden aber in Anwendungen und Layer-2s eingesetzt. Ethereums Philosophie stützt sich auf kryptografische Sicherheit (z. B. aufkommende ZK-Rollups), aber TEEs haben Rollen in Oracles und Off-Chain-Ausführung für Ethereum gefunden:

• Oracle-Dienste: Wie besprochen, 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 verfügbar, die zusätzliches Vertrauen erfordern. Auch API3 (ein weiteres Oracle-Projekt) hat die Verwendung von Intel SGX erwähnt, um APIs auszuführen und Daten zu signieren, um die Authentizität zu gewährleisten. Diese Dienste speisen Daten mit stärkeren Zusicherungen in Ethereum-Verträge ein.

• Layer-2 und Rollups: In der Ethereum-Community gibt es laufende Forschung und Debatten über die Verwendung von TEEs in Rollup-Sequencern oder Validatoren. Zum Beispiel haben das Konzept „ZK-Portal“ von ConsenSys und andere die Verwendung von TEEs vorgeschlagen, um die korrekte Reihenfolge in optimistischen Rollups durchzusetzen oder den Sequencer vor Zensur zu schützen. Der von uns gesehene Medium-Artikel deutet sogar darauf hin, dass TEE bis 2025 zu einer Standardfunktion in einigen L2s für Dinge wie den Schutz vor Hochfrequenzhandel werden könnte. Projekte wie Catalyst (eine Hochfrequenzhandels-DEX) und Flashbots (für MEV-Relays) haben TEEs untersucht, um eine faire Reihenfolge von Transaktionen durchzusetzen, bevor sie die Blockchain erreichen.

• Enterprise Ethereum: In Konsortial- oder Permissioned-Ethereum-Netzwerken sind TEEs weiter verbreitet. Das Trusted Compute Framework (TCF) der Enterprise Ethereum Alliance war im Grunde ein Entwurf zur Integration von TEEs in Ethereum-Clients. Hyperledger Avalon (ehemals EEA TCF) ermöglicht die Ausführung von Teilen von Ethereum-Smart Contracts Off-Chain in einer TEE und deren anschließende Verifizierung On-Chain. Mehrere Unternehmen wie IBM, Microsoft und iExec haben dazu beigetragen. Während dies auf öffentlichem Ethereum nicht üblich geworden ist, können in privaten Implementierungen (z. B. einer Gruppe von Banken, die Quorum oder Besu verwenden) TEEs eingesetzt werden, sodass selbst Konsortialmitglieder die Daten der anderen nicht sehen, sondern nur autorisierte Ergebnisse. Dies kann die Datenschutzanforderungen in einem 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 umstieg; es wurde später zum Secret Network auf Cosmos). Ein weiteres war Decentralized Cloud Services (DCS) in frühen Ethereum-Diskussionen. In jüngerer Zeit ermöglicht OAuth (Oasis Ethereum ParaTime) Solidity-Verträgen, mit Vertraulichkeit zu laufen, indem es das TEE-Backend von Oasis nutzt, aber auf Ethereum abrechnet. Auch einige Ethereum-basierte dApps wie medizinische Datenfreigabe oder Gaming haben mit TEEs experimentiert, indem sie eine Off-Chain-Enklavenkomponente hatten, die mit ihren Verträgen interagiert.

Die Akzeptanz von Ethereum ist also eher indirekt – es hat das Protokoll nicht geändert, um TEEs zu erfordern, aber es verfügt über eine Vielzahl optionaler Dienste und Erweiterungen, die TEEs für diejenigen nutzen, die sie benötigen. Wichtig ist, dass Ethereum-Forscher vorsichtig bleiben: Vorschläge, einen „TEE-only Shard“ zu erstellen oder TEEs tief zu integrieren, stießen in der Community aufgrund von Vertrauensbedenken auf Skepsis. Stattdessen werden TEEs eher als „Co-Prozessoren“ für Ethereum denn als Kernkomponenten angesehen.

Cosmos-Ökosystem

Das Cosmos-Ökosystem ist durch sein modulares SDK und seine souveränen Chains experimentierfreundlich, und Secret Network (oben behandelt) ist ein Paradebeispiel für die TEE-Akzeptanz in Cosmos. Secret Network ist tatsächlich eine Cosmos SDK-Chain mit Tendermint-Konsens, die so modifiziert wurde, dass sie SGX in ihren Validatoren vorschreibt. Es ist eine der prominentesten Cosmos-Zonen nach dem Haupt-Cosmos Hub, was eine signifikante Akzeptanz der TEE-Technologie in dieser Community anzeigt. Der Erfolg von Secret bei der Bereitstellung von Interchain-Datenschutz (durch seine IBC-Verbindungen kann Secret als Datenschutz-Hub für andere Cosmos-Chains dienen) ist ein bemerkenswerter Fall der TEE-Integration auf L1.

Ein weiteres Cosmos-bezogenes Projekt ist Oasis Network (obwohl nicht auf dem Cosmos SDK aufgebaut, wurde es von einigen der gleichen Personen entworfen, die zu Tendermint beigetragen haben und teilt ein ähnliches Ethos modularer Architektur). Oasis ist eigenständig, kann aber über Bridges usw. mit Cosmos verbunden werden. Sowohl Secret als auch Oasis zeigen, dass im Cosmos-Land die Idee von „Datenschutz als Funktion“ über TEEs genügend Anklang gefunden hat, um dedizierte Netzwerke zu rechtfertigen.

Cosmos hat sogar ein Konzept von „Datenschutzanbietern“ für Interchain-Anwendungen – z. B. kann eine App auf einer Kette einen Vertrag im Secret Network über IBC aufrufen, um eine vertrauliche Berechnung durchzuführen und dann das Ergebnis zurückzuerhalten. Diese Kompatibilität entsteht jetzt.

Zusätzlich hat das Projekt Anoma (nicht streng Cosmos, aber im Sinne der Interoperabilität verwandt) über die Verwendung von TEEs für absichtsbasierte Architekturen gesprochen, obwohl dies eher theoretisch ist.

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

Polkadot und Substrate

Polkadots Design ermöglicht es Parachains, sich zu spezialisieren, und tatsächlich hostet Polkadot mehrere Parachains, die TEEs verwenden:

• Sanders Network: Bereits beschrieben; eine Parachain, die eine TEE-basierte Compute-Cloud anbietet. Sanders ist als Parachain live und bietet Dienste für andere Chains über XCMP (Cross-Chain Message Passing) an. Zum Beispiel kann ein anderes Polkadot-Projekt eine vertrauliche Aufgabe an Sanders' Worker auslagern und einen Beweis oder ein Ergebnis zurückerhalten. Sanders' native Token-Ökonomie incentiviert den Betrieb von TEE-Nodes, und es hat eine beträchtliche Community, was eine starke Akzeptanz signalisiert.
• Integritee: Eine weitere Parachain, die sich auf Unternehmens- und Datenschutzlösungen mittels TEEs konzentriert. Integritee ermöglicht es Teams, ihre eigenen privaten Side-Chains (genannt Teewasms) zu implementieren, bei denen die Ausführung in Enklaven erfolgt. Sie zielt auf Anwendungsfälle wie die vertrauliche Datenverarbeitung für Unternehmen ab, die sich weiterhin an die Polkadot-Sicherheit binden möchten.
• /Root oder Crust?: Es gab Ideen, TEEs für dezentralen Speicher oder Zufallsbaken in einigen Polkadot-bezogenen Projekten zu verwenden. Zum Beispiel plante Crust Network (dezentraler Speicher) ursprünglich einen TEE-basierten Proof-of-Storage (obwohl es später zu einem anderen Design wechselte). Und Polkadots zufällige Parachain (Entropy) zog TEEs vs. VRFs in Betracht.

Polkadots Abhängigkeit von On-Chain-Governance und Upgrades bedeutet, dass Parachains neue Technologien schnell integrieren können. Sowohl Sanders als auch Integritee haben Upgrades durchlaufen, um ihre TEE-Integration zu verbessern (wie die Unterstützung neuer SGX-Funktionen oder die Verfeinerung von Attestierungsmethoden). Die Web3 Foundation finanzierte auch frühere Bemühungen bei Substrate-basierten TEE-Projekten wie SubstraTEE (einem frühen Prototyp, der Off-Chain-Vertragsausführung in TEEs mit On-Chain-Verifizierung zeigte).

Das Polkadot-Ökosystem zeigt somit mehrere unabhängige Teams, die auf TEE-Technologie setzen, was einen positiven Akzeptanztrend anzeigt. Es wird zu einem Verkaufsargument für Polkadot, dass „wenn Sie vertrauliche Smart Contracts oder Off-Chain-Berechnungen benötigen, wir Parachains dafür haben“.

Andere Ökosysteme und allgemeine Akzeptanz

• Unternehmen und Konsortien: Außerhalb des öffentlichen Kryptobereichs haben Hyperledger und Unternehmensketten TEEs für permissionierte Umgebungen stetig übernommen. Zum Beispiel testete der Basler Ausschuss eine TEE-basierte Handelsfinanzierungs-Blockchain. Das allgemeine Muster ist: Wo Datenschutz oder Datenvertraulichkeit ein Muss sind und die Teilnehmer bekannt sind (sodass sie möglicherweise sogar gemeinsam in Hardware-Sicherheitsmodule investieren), finden TEEs ein komfortables Zuhause. Diese mögen in Krypto-Nachrichten keine Schlagzeilen machen, aber in Sektoren wie Lieferkette, Bankenkonsortien oder Netzwerken zum Austausch von Gesundheitsdaten sind TEEs oft die erste Wahl (als Alternative dazu, einfach einem Dritten zu vertrauen oder schwere Kryptografie zu verwenden).

• Layer-1s außerhalb von Ethereum: Einige neuere L1s haben mit TEEs experimentiert. NEAR Protocol hatte ein frühes Konzept eines TEE-basierten Shards für private Verträge (noch nicht implementiert). Celo zog TEEs für Light-Client-Proofs in Betracht (ihre Plumo-Proofs basieren jetzt auf Snarks, aber sie untersuchten SGX, um Kettendaten für Mobilgeräte zu einem bestimmten Zeitpunkt 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, aber zum Bootstrapping von Vertrauen (nicht für die Vertragsausführung, da ihre „Chain Key“-Kryptografie dies handhabt).

• Bitcoin: Obwohl Bitcoin selbst keine TEEs verwendet, gab es Nebenprojekte. Zum Beispiel **TEE-basierte Verwahrungslösungen