Als Fortsetzung des vorherigen Artikels , in dem wir Trusted Execution Environment (TEE) erklärt haben, geht diese Abhandlung noch tiefer in die Erklärung der TEE-Sidechain und ihrer Komponenten ein.

Schichten 0, 1 und 2

Das folgende Diagramm zeigt drei Schichten von Blockchains, jede mit ihren eigenen Verantwortlichkeiten:

Um eine Identitätsaggregation zu erreichen, muss Litentry sensible Benutzerdaten wie ein Ethereum-Konto und einen berechneten Kredit-Score speichern. Wir haben uns daher für Trusted Execution Environment (TEE) entschieden , um die Sicherheit und Vertraulichkeit der Datenspeicherung und -verarbeitung zu gewährleisten. Litentry hat eine Sidechain entwickelt, die aus mehreren mit TEE ausgestatteten Knoten besteht und eine verteilte Speicherung und Verarbeitung von Benutzerdaten auf sichere, private Weise bietet.

• Schicht 0 – Das Hauptnetz von Relaisketten wie Kusama oder Polkadot ist für die Bereitstellung gemeinsamer Sicherheit über die gesamte Relaiskette und das Parachain-Netzwerk verantwortlich. Es fungiert auch als Router für XCM-Nachrichten.
• Layer 1 – Litentry Parachain und Lackmus Parachain werden als anwendungsspezifische Blockchains eingesetzt. Sie verbinden sich mit der Relaiskette, indem sie einen Parachain-Slot belegen, wodurch die Relaiskette ihre Blöcke validieren und XCM-Nachrichten überwachen kann.
• Schicht 2 – Die TEE-Sidechain wird von Integritee unterstützt und ermöglicht die Ausführung der Laufzeit in einer sicheren SGX-Laufumgebung. Dies unterscheidet sich von der Schicht-1-Parachain, die alle Zustände und Extrinsiken öffentlich und sichtbar macht.

Die Parachain besteht aus Nodes, die einen dPOS-Mechanismus (Delegated Proof of Stake) verwenden, um Blöcke zu synchronisieren und zu generieren, während die Sidechain aus Nodes besteht, die mit Trusted Execution Environments (TEEs) ausgestattet sind.

Softwarekomponenten

Im obigen Parachain-Sidechain-Client- Diagramm gibt es vier Hauptsoftwarekomponenten: Teerex Pallet, SGX Runtime, Identity Hub Client und Worker Server(s).

Teerex-Palette

Die Teerex-Palette in Parachain ermöglicht TEE-Mitarbeitern, sich zu registrieren , zu entdecken und miteinander zu kommunizieren . Seine Hauptmerkmale sind:

• Fungiert als verifizierte Registrierung, die eine Remote-Verifizierung von SGX-Enklaven ermöglicht – und öffentliche Überprüfbarkeit bietet.
• Entwickelt mit Vertraulichkeit im Kern, um die Vertrauenslücke zwischen der Enklave zu schließen und es jedem zu ermöglichen, die ausgeführten Codes zu überprüfen.
• Fungiert als indirekter Proxy für vertrauliche Zustandsübergangsaufrufe außerhalb der Kette, die von SGX-Enklaven ausgeführt werden.

SGX-Laufzeit

Die SGX-Laufzeit im Sidechain-Worker ermöglicht die vertrauliche Ausführung und Integration aller substratkompatiblen Paletten.

SGX-Paletten werden in der TEE SGX-Worker-Enklave instanziiert, in WASM Blob/Binary kompiliert und hängen von tee-sgx-sdk ab. Es speichert Datenschutzdaten im SGX-Knoten, verknüpft Identitäten, verifiziert Behauptungen und speichert ID-Diagramme. Extrinsische Parameter/Adressen werden in der Parachain verschlüsselt und die privaten Schlüssel sind nur SGX-Knoten bekannt, die Daten in SGX entschlüsseln und Aufrufe an die Laufzeit weiterleiten. Dies trägt dazu bei, den Datenschutz der Benutzer zu wahren, wofür Litentry steht.

Weitere Informationen finden Sie im SGX Runtime Repo .

Identity Hub-Client

Der Identity Hub Client wird zur Ausführung von Aufrufen oder Operationen verwendet und ist ebenfalls substratbasiert.

Der Client interagiert mit Parachain und Sidechain über RPC / WSS (das Diagramm zeigt keine Sidechain-Interaktion, da es noch nicht geöffnet ist.) Aufrufe an die Parachain sind verschlüsselt und undurchsichtig, um die Vertraulichkeit geltend zu machen. Der Inhalt der Operation ist nur für den Client und das Sidechain-TEE (SGX, SGX-Worker/-Knoten und SGX-Laufzeit) sichtbar.

Es gibt verschiedene Arten von Aufrufen, die vom Client basierend auf dem Operationsziel ausgeführt werden können. Sie beinhalten:

• Nicht vertrauenswürdiger Anruf : Der Client interagiert mit dem Parachain-Knoten über nicht vertrauenswürdige Anrufe, indem er Transaktionen oder Abfragen sendet. Beispielsweise ist eine Guthabenübertragung über den Client ein nicht vertrauenswürdiger Anruf.
• Vertrauenswürdiger Anruf : Der Client interagiert mit dem TEE-Worker-Server. ZB das Aufrufen von link_eth, das aus der SGX-Konto-Linker-Palette stammt. Oder fragen Sie die verschlüsselten Daten in SGX ab.
• Direkter Anruf : Client ruft extrinsisch in der SGX-Laufzeit an (wie ein vertrauenswürdiger Anruf).
• Indirekter Aufruf : Der Client verschlüsselt den SGX-Laufzeitaufruf und sendet ihn in Parachain an Teerex Pallet. Worker-Knoten-Synchronisierungsblöcke identifizieren call_work extrinsisch, parsen Aufrufe von Parachain und senden an die SGX-Laufzeit. Die Details können dem Diagramm unten entnommen werden:

Der/die Worker-Server führen Funktionen mit spezifizierten Eingaben und Ressourcengrenzen als Reaktion auf TEE-Aufrufe und -Operationen aus. Um eine ausreichende Skalierung zu gewährleisten, sind für diese Ausführungen normalerweise viele Worker-Server erforderlich.

Server sind der komplizierteste Teil des gesamten TEE und ihre Hauptfunktionen sind wie folgt:

1. Verwendet bei der Durchführung einer Fernbeglaubigung – der Vorgang, bei dem der TEE-Hersteller (Intel) aufgefordert wird, ein TEE zu authentifizieren. Der Hersteller unterzeichnet einen Bericht, um zu bestätigen, dass sowohl das TEE selbst als auch der Hash der Binärdatei, die es ausführt, echt sind
2. Stellt die Ausführungsumgebung für die SGX-Laufzeit im vertrauenswürdigen Knoten bereit
3. Synchronisieren Sie die Blöcke von parachain, entschlüsseln und analysieren Sie die Daten von call_work
4. Erzeugt den Block der Seitenkette, synchronisiert und führt einen Konsens zwischen den Knoten durch
5. Bietet RPC- und WSS-Dienste
6. Senden Sie eine Antwort an die Parachain über extrinsisch

Sharding – das Prinzip der Aufteilung der gesamten Arbeitslast, die Server bewältigen müssen, in kleinere, besser zu verwaltende Teile – wird von Beginn des Sidechain-Designs an unterstützt. Der Serverknoten tritt einem Shard bei (jeder direkte und indirekte Aufruf hat eine standardmäßige Parameter-Shard-Identität). Der Serverknoten führt dann den Aufruf mit demselben Shard aus, dem er beigetreten ist. Der Vorteil von Sharding ist wie folgt:

1. Der Status für jeden Shard ist isoliert – die verschiedenen Shard-Knoten können die privaten Daten des anderen nicht sehen
2. Shard-Knoten können den Aufruf von einem anderen Shard überspringen. Dies hilft, Ressourcen zu sparen und macht es schneller, weniger extrinsische im Block auszuführen
3. Sharding ermöglicht den großflächigen Einsatz unserer Lösung bei gleichzeitigem Schutz der Nutzerdaten

Wenn Sie eine Identitätsverknüpfung (Web2 <> Web3 oder Cross-Chain-Wallet-Verknüpfung) oder eine verifizierbare Generierung von Anmeldeinformationen in Identity Hub anfordern, werden alle Daten, die zum Abschließen der Anfrage erforderlich sind, in der TEE-Umgebung gespeichert und berechnet.

Dazu gehören die Anfrage selbst, die Beziehung zwischen verschiedenen Wallets, Daten, die von einem bestimmten Wallet abgerufen werden, das den Anspruch in einem VC unterstützt, usw.

Die anfänglichen Funktionalitäten von Litentry Parachain, einschließlich Token-Transfer, Governance, Staking und Cross-Chain-Transfer, beinhalten keine Prozesse zum Schutz der Privatsphäre.

Ein besonderer Dank geht an Mel Zhou , Eric Zhang und Kailai Wang für ihren wissens- und fachwissensbasierten Beitrag zu der Artikelserie, die wir veröffentlicht haben, um Benutzer, Community-Mitglieder und Datenschutzbegeisterte über unsere Datenschutz- und Identitätsverwaltungslösung aufzuklären.

Hier sind Links zum Lesen unserer früheren Veröffentlichungen, um die neuartige Lösung, die wir bei Litentry entwickeln, besser zu verstehen:

• Datenschutz in Litentry I: Implikation und Design
• Datenschutz in Litentry II: Trusted Execution Environment erklärt