TEE, MPC, FHE e ZKP non sono concorrenti. Sono amici. Le discussioni spesso confrontano questa tecnologia per determinare quale sia superiore. In realtà, queste tecnologie non si escludono a vicenda e possono funzionare insieme e completarsi a vicenda. 1. Ogni soluzione ha dei compromessi, ma non sono correlati >MPC non ha un singolo punto di guasto, ma richiede un intenso scambio di dati Un protocollo MPC si svolge in genere in tre fasi. 1. Gli utenti condividono segretamente i loro input privati, inviando dati crittografati ai nodi informatici, garantendo la sicurezza attraverso la non collusione o un modello a soglia completa (tutti i nodi devono colludere). 2. I nodi calcolano queste condivisioni segrete. 3. I nodi restituiscono le loro quote di output agli utenti, che ricostruiscono il risultato. MPC funziona meglio con nodi ben collegati, ma il suo costo deriva da un intenso scambio di dati tra di loro, quindi ci troviamo principalmente ad affrontare problemi di comunicazione generali. In molti protocolli MPC standard, ogni nodo comunica con tutti gli altri nodi per operazioni come le porte di moltiplicazione. Ciò si traduce in una complessità di comunicazione quadratica O(n²). Che cosa significa? • Ad esempio, con 10 nodi e una complessità computazionale di 1 KB, lo scambio di dati è di circa 100 GB. • Con 100 nodi, raggiunge circa 10 TB. Lo scambio di dati di MPC limita le applicazioni pratiche a 2-10 nodi a causa del sovraccarico di comunicazione. Quindi, a differenza della blockchain, un MPC veloce con centinaia di nodi non è ancora fattibile. > FHE richiede meno dati, ma più risorse di calcolo FHE affronta una sfida di lunga data: come abilitare il calcolo sicuro sui dati crittografati senza richiedere la decrittografia? Un utente può crittografare i propri dati sensibili, caricarli su un server e il server può eseguire calcoli su questo testo cifrato (messaggio crittografato). L'output risultante, ancora crittografato, può quindi essere decrittografato dall'utente utilizzando la propria chiave privata, a differenza della tradizionale crittografia end-to-end (E2EE) in cui il calcolo sui dati crittografati non è fattibile. FHE utilizza meno trasferimento dati rispetto a MPC, ma richiede una quantità significativamente maggiore di calcolo lato server. Ciò rende FHE generalmente più lento di MPC, tranne in situazioni con reti estremamente lente o infrastrutture di calcolo molto potenti. • Una semplice query di database che richiede millisecondi non crittografata può estendersi fino a 2-10 secondi con FHE • L'inferenza AI con FHE richiede da secondi a minuti rispetto ai millisecondi per le operazioni non crittografate > ZK non riguarda i calcoli generali e ha un problema di privacy Mentre tutte queste tecnologie consentono calcoli privati, le ZKP generano specificamente dimostrazioni con risultati "veri" o "falsi" (booleani). Come la maggior parte delle persone sa, gli ZKP sono ampiamente utilizzati negli zk-rollup, che sono prove succinte con una dimensione piccola, fissa e una verifica rapida, ideali per l'uso on-chain. Tuttavia, gli zk-rollup utilizzano la solidità e la concisione, ma non la loro proprietà zk. Mentre gli ZKP assicurano che una prova falsa non possa apparire valida (solidità) e che chiunque possa verificare una prova, negli zk-rollup sorge un problema di privacy. L'entità che esegue il circuito zk ha pieno accesso ai dati di input durante il calcolo, ovvero i dati sensibili visibili al dimostratore. Ciò compromette la privacy degli input degli utenti privati. > TEE è economico e veloce, ma anche vulnerabile agli attacchi del canale laterale A differenza di altre tecnologie per la privacy, i TEE si basano su hardware specifico, come SGX di Intel. Il modello di sicurezza dei TEE è meno trasparente rispetto ad altri metodi e sono state identificate vulnerabilità in varie implementazioni TEE. 2. Diversi compromessi: diversi modi per completarli Ogni tecnologia soffre di problemi diversi e ha anche vantaggi diversi, quindi dire che una tecnologia è di gran lunga migliore di un'altra senza fornire alcun contesto è certamente errato. Ogni opzione non può funzionare meglio in determinate situazioni rispetto ad altre opzioni e viceversa. Per fare un esempio: • Il problema della collusione non si riferisce in alcun modo al TEE, perché esiste solo un ambiente isolato in cui la collusione è impossibile • Le ZKP non possono essere correlate in alcun modo a MPC o FHE in termini di calcoli, perché la tecnologia ZK è correlata solo alla generazione di dimostrazioni booleane • Il principale presupposto di fiducia di TEE è che l'hardware venga violato, mentre il problema principale con l'hardware in FHE è che deve essere abbastanza veloce e performante • Stiamo parlando dello stesso argomento (hardware), ma ci sono assolutamente dei punti polari su cui riflettere Seguendo questa logica, ho deciso di approfondire la questione e vedere dove le diverse tecnologie possono completarsi a vicenda e offrire una soluzione migliore. 3. Sinergie e ruoli complementari Prendiamo il TEE come base certa e vediamo come possono funzionare diverse combinazioni e come possiamo risolvere i problemi in quelle opzioni. > TEE + MPC Problema: i TEE si basano su chiavi basate su hardware per la privacy, creando problemi di portabilità dei dati e potenziale censura. Soluzione: MPC può risolvere questo problema sostituendo le chiavi hardware e fungendo da servizio di gestione delle chiavi per i TEE. Le soluzioni MPC possono eseguire calcoli all'interno dei TEE per garantire che le operazioni di ciascuna parte siano isolate e sicure, rendendole ancora più sicure, e ci sono già più protocolli che lo fanno. • Se guardiamo la situazione da un punto di vista diverso e vediamo come TEE può trarre vantaggio da MPC, è replicando ambienti isolati, rendendoli più distribuiti • Invece di affidarsi a un TEE per gestire tutto, MPC distribuisce la responsabilità su diversi TEE • TEE può distribuire l'attendibilità su più enclave sicure e ridurre la dipendenza da una singola istanza TEE • Ogni enclave contribuisce al calcolo senza bisogno di fidarsi completamente delle altre grazie alle garanzie crittografiche di MPC. > TEE + FHE I problemi con TEE (attacchi side-channel) e FHE (enormi risorse di calcolo) sono diversi, così come le tecniche che portano. L'esecuzione di codice in un ambiente isolato non equivale a disporre di una tecnologia per eseguire calcoli sui dati decrittografati. In questo caso, TEE sembra un sovraccarico, perché il codice puro è in esecuzione in una macchina isolata e richiede la decrittografia, mentre FHE consente agli sviluppatori di eseguire calcoli su dati già crittografati. Mentre può essere vero in qualche modo che il TEE è un sovraccarico tecnologico, l'utilizzo di FHE ha un altro sovraccarico di risorse computazionali davvero elevate. Approssimativamente, quando si utilizza il TEE, c'è un sovraccarico del 5%, mentre si utilizza FHE, il sovraccarico è di circa 1.000.000x. Anche se potrebbe sembrare che i TEE e FHE possano creare sovraccarichi l'uno per l'altro, sto esplorando l'utilizzo dei TEE per gestire in modo sicuro le chiavi di decrittografia o gestire le attività ad alta intensità di prestazioni con cui FHE ha difficoltà. Se lo esaminiamo da un altro punto di vista, FHE può consentire a TEE di elaborare direttamente i dati crittografati mentre TEE gestisce le chiavi. > TEE + ZK C'è anche un esempio di quanto sia efficiente l'utilizzo di TEE e ZK utilizzando TEE per la dimostrazione di zkVM. Problema: l'esternalizzazione della prova di zkVM su qualsiasi altro dispositivo è problematica, perché la privacy diventa a rischio poiché il prover in genere ha bisogno di accedere agli input. Soluzione: Se eseguiamo zkVM all'interno di un TEE, il calcolo avviene all'interno di un'enclave sicura e impedisce all'host di accedere ai dati. Il TEE fornisce l'attestazione che la prova è stata generata correttamente. Ad esempio, @PhalaNetwork utilizza GPU abilitate per TEE per eseguire zkVM SP1, ottenendo un sovraccarico inferiore al 20% per carichi di lavoro complessi come zkEVM. 4. Phala come Fondazione TEE Phala costruisce il cloud decentralizzato TEE in criptovalute, in modo che chiunque possa sfruttare TEE e utilizzarlo per i propri scopi, compresi i team la cui offerta di prodotti principale è MPC, FHE o ZK. Volevo saperne di più ed esplorare i team che utilizzano Phala per questi scopi. > Phala + MPC @0xfairblock esegue il confidential computing per mitigare i rischi centralizzati e prevenire la perdita e la manipolazione delle informazioni nelle app, dove la loro tecnologia principale è MPC. Tuttavia, possono comunque beneficiare dei TEE: • L'enclave TEE di Phala genera chiavi private, che vengono poi crittografate a soglia e suddivise in condivisioni per l'archiviazione nell'MPC di Fairblock • Gli smart contract monitorano le operazioni TEE richiedendo l'invio regolare di chiavi crittografate e agiscono sostanzialmente come un meccanismo di rilevamento dei guasti • Se il TEE fallisce, gli smart contract attivano l'MPC di Fairblock per ricostruire e decrittografare privatamente le chiavi per mantenere la riservatezza della condivisione. In tale contesto, le chiavi rimangono sempre crittografate all'interno dei TEE, con MPC che garantisce che nessuna singola parte possa accedere alla chiave completa. I meccanismi di ripristino automatizzato proteggono dalla perdita di dati dovuta a arresti anomali o riavvii del sistema. > Phala + zkTLS Ci sono molti protocolli zk che utilizzano Phala, ma voglio evidenziare @primus_labs, perché la loro offerta principale riguarda zkTLS. Ho già scritto un articolo completo su zkTLS, ma la cosa più importante che devi sapere è che in zkTLS, l'attestatore funge da validatore che esamina i flussi di dati crittografati per verificarne l'autenticità. Difficoltà: ridurre la dipendenza dall'affidabilità dell'attestatore. • Utilizzando Dstack di Phala, gli attestatori di Primus possono eseguire le attestazioni all'interno di un TEE per assicurarsi che ogni ZKP sia supportato da attestazioni emesse all'interno di un TEE. • In tal caso, chiunque può verificare la prova utilizzando un esploratore di attestazioni. TEE mantiene bassa la latenza e non comporta alcun sovraccarico di tempo. > Phala + FHE @sporedotfun utilizza sia FHE sul lato @mindnetwork_xyz che TEE sul lato Phala. Nel sistema di staking-to-vote di Spore, gli aggressori possono mettere in staking i token prima delle scadenze per fuorviare gli elettori, quindi annullare lo staking e distorcere i risultati e i mercati. Difficoltà: trovare un equilibrio tra trasparenza e sicurezza per garantire che le decisioni di governance siano in linea con le intenzioni dei contributori a lungo termine. • Per contrastare il cecchinaggio dei voti, Spore adotta FHE tramite Mind Network e consente il voto alla cieca che protegge la privacy degli elettori. • FHE mantiene i voti crittografati per eliminare la possibilità per i cecchini di votare in modo dannoso. • TEE fornisce un ambiente zero-trust per l'aggregazione e la pubblicazione dei voti prima della pubblicazione finale. 5. Le possibilità sono infinite, ma vale la pena considerare i rischi e le prestazioni generali Come ho detto prima, ci sono molti casi d'uso possibili con la fondazione TEE, quindi le possibilità sono infinite. La considerazione principale è questa: • Il settore sta attualmente riscontrando una crescente domanda di calcoli complessi, guidati principalmente dall'intelligenza artificiale • La rapida espansione del settore dell'intelligenza artificiale aumenta i requisiti di prestazione. • Con l'aumento delle esigenze di prestazioni, dobbiamo considerare non solo le prestazioni e le caratteristiche di sicurezza di tecnologie specifiche, ma anche i loro costi. Per fornire stime approssimative del sovraccarico delle prestazioni utilizzando cifre approssimative, le seguenti proiezioni sono: • TEE — 5% di spese generali • MPC — 100x sopra la testa • ZK — 1.000 volte sopra la testa • FHE: 1.000.000 di volte il sovraccarico Come possiamo vedere, TEE introduce pochissimo sovraccarico in qualsiasi sistema ed è fondamentalmente l'ambiente più performante ed economico per calcoli complessi come l'inferenza AI. Nei sistemi attuali, e ancora di più nei sistemi futuri, gli sviluppatori dovrebbero considerare i TEE come una delle parti della progettazione finale del sistema, anche se l'offerta principale non riguarda i TEE. TEE non solo mitiga i compromessi individuali di MPC, FHE o ZK, ma sblocca anche molte possibilità per sviluppatori e utenti.