Sequel del precedente articolo in cui abbiamo spiegato Trusted Execution Environment (TEE), questo trattato approfondisce ancora di più la spiegazione della sidechain TEE e dei suoi componenti.

Livelli 0, 1 e 2

Il diagramma seguente mostra tre livelli di blockchain, ciascuno con le proprie responsabilità:

Per ottenere l'aggregazione delle identità, Litentry deve archiviare i dati utente sensibili, come un account Ethereum e il punteggio di credito calcolato. Abbiamo quindi scelto Trusted Execution Environment (TEE) per garantire la sicurezza e la privacy dell'archiviazione e dell'elaborazione dei dati. Litentry ha sviluppato una sidechain composta da più nodi dotati di TEE, offrendo archiviazione ed elaborazione distribuite dei dati degli utenti in modo sicuro e privato.

• Livello 0 : la rete principale delle catene di inoltro , come Kusama o Polkadot, è responsabile della sicurezza condivisa attraverso l'intera catena di inoltro e la rete parachain. Funziona anche come router per i messaggi XCM.
• Livello 1 : Litentry Parachain e Litmus Parachain sono utilizzati come blockchain specifici per l'applicazione. Si interconnettono con la catena di inoltro occupando uno slot parachain, consentendo alla catena di inoltro di convalidare i suoi blocchi e supervisionare i messaggi XCM.
• Livello 2 : la sidechain TEE è supportata da Integritee e consente l'esecuzione del runtime in un ambiente di esecuzione sicuro SGX. Questo è distinto dal parachain di livello 1 che rende pubblici e visibili tutti gli stati e gli estrinseci.

La parachain è composta da nodi che utilizzano un meccanismo dPOS (Delegated Proof of Stake) per sincronizzare e generare blocchi mentre la sidechain è composta da nodi dotati di Trusted Execution Environments (TEE).

Componenti software

Nel diagramma Parachain-Sidechain-Client sopra, ci sono quattro componenti software principali: Teerex Pallet, SGX Runtime, Identity Hub Client e Worker Server.

Paletta teerex

Il pallet Teerex in Parachain consente ai lavoratori TEE di registrarsi , scoprire e comunicare tra loro. Le sue caratteristiche principali sono:

• Fungendo da registro verificato che consente la verifica remota delle enclavi SGX, fornendo verificabilità pubblica.
• Progettato con la riservatezza al suo interno per colmare il divario di fiducia tra l'enclave e consentire a chiunque di verificare i codici che vengono eseguiti.
• Agendo come proxy indiretto per le chiamate di transizione di stato riservate off-chain eseguite dalle enclavi SGX.

Tempo di esecuzione SGX

Il runtime SGX nel lavoratore sidechain consente l'esecuzione riservata e l'integrazione di tutti i pallet compatibili con il substrato.

I pallet SGX vengono istanziati nell'enclave di lavoro TEE SGX, compilati in BLOB/binario WASM e dipendono da tee-sgx-sdk. Memorizza i dati sulla privacy nel nodo SGX, collegando le identità, verificando le asserzioni e memorizzando i grafici degli ID. I parametri/indirizzi estrinseci sono crittografati nella parachain e le chiavi private sono conosciute solo dai nodi SGX, che decrittografano i dati in SGX e inviano le chiamate al runtime. Questo aiuta a mantenere la privacy dei dati degli utenti, che Litentry rappresenta.

Ulteriori informazioni possono essere trovate nel repository di runtime SGX .

Client dell'hub di identità

Il client Identity Hub viene utilizzato per eseguire chiamate o operazioni ed è anche basato sul substrato.

Il client interagisce con parachain e sidechain tramite RPC / WSS (il diagramma non mostra l'interazione con sidechain poiché non è ancora aperto). Le chiamate effettuate al parachain sono crittografate e opache per invocare la riservatezza. Il contenuto dell'operazione è visibile solo al Cliente e al TEE della sidechain (SGX, worker/nodi SGX e runtime SGX).

Esistono diversi tipi di chiamate che possono essere eseguite dal client in base alla destinazione dell'operazione. Loro includono:

• Chiamata non attendibile : il client interagisce con il nodo parachain tramite chiamate non attendibili, invio di transazioni o query. Ad esempio, un trasferimento del saldo tramite client è una chiamata non attendibile.
• Chiamata attendibile : il client interagisce con il server di lavoro TEE. Ad esempio chiamando link_eth, che è estrinseco dal pallet del linker dell'account SGX. Oppure interroga i dati crittografati in SGX.
• Chiamata diretta : il client chiama estrinseco nel runtime SGX (uguale a una chiamata attendibile).
• Chiamata indiretta : il client crittografa la chiamata di runtime SGX, invia a Teerex Pallet in parachain. Il nodo di lavoro sincronizza i blocchi identifica call_work estrinseco, analizza la chiamata da parachain e invia al runtime SGX. I dettagli possono essere trovati nello schema seguente:

I Worker Server eseguono funzioni con input e limiti di risorse specificati in risposta a chiamate e operazioni TEE. Per garantire un livello sufficiente di scalabilità, di solito sono necessari molti server di lavoro per queste esecuzioni.

I server sono la parte più complicata dell'intero TEE e le loro funzioni principali sono le seguenti:

1. Utilizzato per eseguire l'attestazione remota: il processo per chiedere al produttore del TEE (Intel) di autenticare un TEE. Il produttore firma un rapporto per confermare che sia il TEE stesso che l'hash del binario che sta eseguendo sono autentici
2. Fornisce l'ambiente di esecuzione per il runtime SGX nel nodo attendibile
3. Sincronizza i blocchi da parachain, decrittografa e analizza i dati da call_work
4. Genera il blocco della catena laterale, sincronizza ed effettua un consenso tra i nodi
5. Fornisce il servizio RPC e WSS
6. Invia una risposta al parachain tramite estrinseco

Lo sharding, il principio della suddivisione del carico di lavoro complessivo che i server devono gestire in blocchi più piccoli e più gestibili, è supportato dall'inizio della progettazione della sidechain. Il nodo del server si unisce a uno shard (ogni chiamata sia diretta che indiretta ha un'identità di shard con parametro predefinito). Il nodo del server esegue quindi la chiamata con lo stesso frammento a cui si è unito. Il vantaggio dello sharding è il seguente:

1. Lo stato di ogni shard è isolato: i diversi nodi shard non possono vedere i reciproci dati privati
2. I nodi shard possono ignorare la chiamata da un altro shard. Questo aiuta a risparmiare risorse e rende più veloce l'esecuzione meno estrinseca nel blocco
3. Lo sharding consente di utilizzare la nostra soluzione su larga scala, proteggendo allo stesso tempo i dati degli utenti

Quando si richiede il collegamento di identità (Web2 <> Web3 o collegamento di portafogli cross-chain) o la generazione di credenziali verificabili in Identity Hub, tutti i dati coinvolti per completare la richiesta verranno archiviati e calcolati nell'ambiente TEE.

Ciò include la richiesta stessa, la relazione tra diversi portafogli, i dati recuperati da un portafoglio specifico che supporta la richiesta in un VC, ecc.

Le funzionalità iniziali di Litentry Parachain, tra cui il trasferimento di token, la governance, lo staking e il trasferimento cross-chain, non implicano processi di tutela della privacy.

Un ringraziamento speciale a Mel Zhou , Eric Zhang e Kailai Wang per la loro conoscenza e il loro contributo basato sulla competenza alla serie di articoli che abbiamo pubblicato per educare gli utenti, i membri della comunità e gli appassionati di privacy sulla nostra soluzione di gestione della privacy e dell'identità.

Ecco i link per leggere le nostre pubblicazioni precedenti per comprendere meglio la nuova soluzione che stiamo costruendo in Litentry:

• Privacy in Litentry I: implicazione e design
• Privacy in Litentry II: Spiegazione dell'ambiente di esecuzione attendibile