Secret 2.0: Costruire la Privacy di Prossima Generazione per il Web 3
Nuove soluzioni crittografiche, reti complementari, rafforzamento dell’enclave ed altro ancora. Dai una prima occhiata a Secret 2.0, una massiccia evoluzione della nostra architettura come hub per la privacy del Web3!
Ciao community!
Oggi vi scrivo per parlare del passato, presente e futuro di Secret Network e per condividere alcuni piani che fino a questo momento non sono mai stati condivisi.
L’ecosistema di Secret è stato sempre orgoglioso della nostra capacità di iterare velocemente ed essere all’avanguardia nelle tecnologie pragmatiche di conservazione della privacy che possono essere implementate in produzione. Sette anni fa, siamo stati il primo team a parlare di privacy per il Web3 quando ho pubblicato i miei whitepaper originali (incluso “Decentralizing Privacy” che ora, con oltre 2.000 citazioni, è il documento più citato sulla privacy della blockchain). Più di due anni fa, Secret è diventato il primo Layer 1 con smart contract per la tutela della privacy, cosa che accade ancora oggi.
Ma con la crescita di Secret Network, insieme allo stesso Web3, è giunto il momento di pensare in modo più ampio alla nostra visione di Privacy e a come garantirci sempre la prima linea sia nella ricerca che nello sviluppo. Non vogliamo mai essere bloccati in un massimo locale; piuttosto, vogliamo essere sempre leader di mercato nelle soluzioni per la privacy del Web3. Vogliamo sempre spingere le nostre soluzioni in modo che siano più sicure, più performanti, più veloci e a costi inferiori, soprattutto con l’aumento dell’adozione.
Con “Secret 1.0” ci riferiamo a tutto lo sviluppo realizzato fino a questo punto: una blockchain L1 ed un ecosistema, relativamente maturo, di applicazioni per la tutela della privacy. Oggi parleremo di “Secret 2.0”: dove la nuova ricerca e sviluppo stanno portando l’ecosistema.
Una versione completa della visione di Secret 2.0 richiederebbe un whitepaper approfondito che includa tutto, dalla minuzia tecnica all’economia. Oggi non è il caso. Ma in questo post, vorrei condividere un paio di pezzi critici della tabella di marcia per aumentare ulteriormente le soluzioni di Secret per la privacy:
1) Realizzare una rete complementare: una soglia di crittografia completamente omomorfa (FHE) Layer-1 che, insieme alle enclavi, fornisce la migliore soluzione per la privacy
2) Rafforzamento di SGX (e altre enclavi supportate) utilizzando sia tecniche crittografiche che tecniche pratiche di ingegneria
Con questi miglioramenti, il futuro di Secret sembra più una brillante costellazione di soluzioni per la privacy interconnesse piuttosto che una singola stella. Diamo un’occhiata a entrambi i percorsi strategici di cui sopra e come aiuteranno a definire Secret come l’hub della privacy per l’intero Web3!
Alla fine di questo post, includeremo anche un invito per ricercatori, sviluppatori e partner interessati a contribuire a Secret 2.0. Se sei un ricercatore, uno sviluppatore o un team indipendente interessato a partecipare a questo sforzo, contatta SCRT Labs tramite e-mail: info@scrtlabs.com
Vuoi saperne di più su dove si trova Secret oggi? Tuffati qui.
Crittografia a soglia completamente omomorfa (FHE) per i Secret Contract
Abbiamo sempre affermato che la missione di Secret sia quella di fornire le soluzioni di privacy più pratiche nei sistemi di produzione. La privacy è troppo importante per essere discussa solo in un ambiente accademico: oggi è necessaria agli utenti. Tuttavia, teniamo d’occhio tutti i nuovi progressi accademici per capire quando e come potrebbero essere implementate nuove soluzioni in produzione a vantaggio di sviluppatori ed utenti. La sicurezza è uno spazio in continua evoluzione!
Abbiamo commentato in passato che le enclavi sicure erano (e in realtà lo sono tuttora) l’unica tecnologia attualmente pronta per l’uso generale in una rete di smart contract. Le enclavi offrono prestazioni più rapide a costi inferiori rispetto a più casi d’uso. Questo è il motivo per cui ci siamo concentrati sul loro utilizzo in Secret 1.0.
Tuttavia, abbiamo sempre considerato come la combinazione di più tecnologie potrebbe portare a soluzioni migliori pronte per andare in produzione. Grazie ai recenti progressi, stiamo ora esplorando la crittografia completamente omomorfa (FHE) come una seria opzione per rafforzare Secret come hub per la privacy.
Una nuova rete di accompagnamento basata sulla FHE (nome da rivelare) è progettata per assomigliare molto a Secret e attualmente stiamo lavorando a un modo interessante per interconnettere le due in modo incrociato. Ma ai fini di questo post, vorrei concentrarmi sulla progettazione tecnica di tale catena e su come può fornire la soluzione più sicura per risolvere il problema della privacy.
Per la privacy, la rete sfrutterà la crittografia completamente omomorfa (FHE), uno schema che consente di elaborare dati crittografati. In sostanza, mantiene l’invariante di:
Negli ultimi anni gli schemi FHE hanno migliorato le prestazioni a passi da gigante e la tendenza sembra continuare. Attraverso l’uso di GPU, FPGA ed eventualmente ASIC, possiamo aspettarci un aumento di 1.000–10.000 volte nei prossimi anni. I progressi sono promettenti e ora ci sono buone ragioni per credere che l’FHE possa diventare sufficientemente scalabile in un periodo abbastanza breve.
Ma c’è un problema. La stessa FHE può funzionare solo con una singola chiave; quindi, come gestiamo un ambiente multiutente come nel caso delle blockchain? Dobbiamo essenzialmente utilizzare una variante multi-party-computation (MPC) dell’FHE chiamata Threshold (Soglia) FHE. Come suggerisce il nome, Threshold FHE consente a ciascun server di eseguire qualsiasi calcolo sui dati crittografati, ma per decrittografare l’output, una certa soglia di nodi deve collaborare.
Quindi, come si inserisce questo nella nostra rete complementare? In sostanza, con un appropriato schema soglia FHE, possiamo fare in modo che i validatori condividano la chiave segreta di crittografia tra loro. Ciò può essere ottenuto abbastanza facilmente con un semplice protocollo DKG che è altamente efficiente. Utilizzando la condivisione segreta proattiva mobile, possiamo essenzialmente spostare le condivisioni dai validatori che lasciano a quelli che aderiscono. La parte “proattiva” assicurerebbe che qualsiasi utente malintenzionato non possa corrompere lentamente i validatori nel tempo, poiché richiede ai validatori di aggiornare le proprie condivisioni della chiave ogni determinata quantità di blocchi.
Con questa configurazione, inviare una transazione di smart contract alla rete è abbastanza banale:
1) L’utente invia una transazione chiamando una funzione in un contratto specifico, crittografando tutti i suoi dati utilizzando la chiave pubblica della chiave di rete condivisa.
2) Tutti i validatori eseguono il consenso come al solito, mentre calcolano i dati crittografati. Questo è fondamentalmente simile a come funziona Secret oggi, tranne per il fatto che il calcolo viene eseguito direttamente sui dati crittografati senza decrittografarli in un’enclave.
3) Usando questo schema possiamo ottenere la privacy di input, stato ed output proprio come in Secret oggi. (Per la privacy dell’output, tutti i validatori devono eseguire un protocollo di commutazione chiave che esegue una ri-crittografia del proxy di soglia per modificare l’output in modo che sia decrittografabile con una chiave nota solo all’utente.)
Una nota importante da menzionare è che ogni validatore riceverà una quota della chiave di decrittazione in base al loro stake. Per decrittografare la rete si richiederebbe il 67% della potenza di staking. Questa cifra è in linea con il numero di voti per approvare un blocco, quindi ha senso.
Un problema con questo progetto è che i validatori possono colludere e la collusione è banale e non rilevabile (scrivi alcune righe di codice che consentano ai validatori di scambiare le quote della chiave segreta fuori catena). Per questo motivo, riteniamo che per questo lavoro dovremo combinare queste tecniche crittografiche con SGX o un simile TEE (idealmente più TEE utilizzando più architetture). In questo modo, aumentiamo la barriera all’attacco: ora è necessario convincere tutti i validatori a colludere, il che diventa estremamente improbabile quando vengono utilizzati i TEE.
Tuttavia, è anche importante notare che eseguire FHE all’interno di un’enclave è probabilmente una cattiva idea. Come accennato, lo scaling FHE si baserà sul supporto di GPU, FPGA o ASIC, che oggi non sono compatibili con le enclavi. Fortunatamente, dovrebbe essere facile capire che abbiamo davvero bisogno della chiave di decrittazione della soglia solo in caso di cambio di chiave o decrittografia della soglia. L’intero calcolo crittografato effettivo può avvenire al di fuori dell’enclave, il che aiuterebbe notevolmente con le prestazioni. Inoltre, limitare le enclavi stesse a concentrarsi sulla memorizzazione di una condivisione di chiave e sull’esecuzione di uno specifico protocollo di decrittazione soglia significa che sarebbe molto più semplice proteggere quell’enclave da potenziali attacchi.
Rafforzamento SGX ed altre enclavi
L’introduzione di soluzioni crittografiche come FHE nella nostra costellazione di privacy migliorerà notevolmente l’offerta di Secret a sviluppatori e utenti allo stesso modo. Tuttavia, c’è molto di più che possiamo fare nel frattempo per rafforzare la nostra rete esistente, oltre a migliorarne la flessibilità futura. La maggior parte di queste idee cercano anche di combinare una crittografia più avanzata insieme ad SGX, in modo che sfrutti i vantaggi delle enclavi sicure ma che non si basi esclusivamente su di esse.
Thresholdizing (Sogliatura) della chiave master
Di recente ho scritto un post sul forum che descriveva come possiamo adattare un recente articolo di Momeni e collaboratori, che sfrutta la crittografia basata sull’identità (IBE) con la condivisione segreta per distribuire la chiave principale di Secret, che è la principale fonte di entropia utilizzata per generare chiavi di crittografia per le transazioni degli utenti, crittografie di stato, casualità sulla catena, ecc.
L’idea proposta suddivide sostanzialmente l’attuale master key, presente in ogni enclave (e quindi basterebbe rompere una singola enclave per decifrare tutti i dati), in condivisioni (in quote), in modo tale che bisogna richiedere le condivisioni (quote) del 67% dei validatori per essere effettivamente in grado di apprendere la chiave totale. Dal momento che tutte queste condivisioni (quote di chiave) vivono anche in enclavi, lo stesso argomento della catena Threshold FHE resta al di sopra: la necessità di rompere le enclavi della maggior parte della rete è probabilmente impraticabile in qualsiasi situazione.
La chiave segreta master condivisa verrà quindi utilizzata per generare una chiave derivata per ogni blocco. La parte interessante è che gli utenti possono generare a priori e autonomamente la chiave pubblica corrispondente per ogni blocco, mantenendo così la crittografia lato client delle transazioni non interattiva come avviene oggi. Inoltre, tutti i validatori possono generare la propria quota derivata della chiave segreta anche in modo indipendente e, per ogni blocco, allegarla come parte del meccanismo di consenso. Ciò significa che le enclavi imparano la chiave di un blocco specifico appena in tempo per eseguire i calcoli, ma non imparano mai la chiave master!
Possiamo utilizzare la stessa tecnica di condivisione segreta mobile proattiva della catena FHE per assicurarci che le condivisioni della chiave master vengano periodicamente aggiornate e spostate dai vecchi validatori a quelli nuovi, per migliorare sia la sicurezza che la disponibilità.
Segretezza avanzata?
Lo schema di cui sopra utilizza essenzialmente la crittografia omomorfa e il calcolo multi-parti (MPC) per prevenire una potenziale perdita della chiave master anche in una catastrofe SGX. Allo stesso modo, protegge meglio dalla collusione, a cui tutte le tecniche MPC sono vulnerabili mantenendo tutte le loro chiavi condivise nell’enclave.
Tutto ciò è fantastico, ma c’è ancora una grande sfida da affrontare. I validatori apprendono la chiave di un blocco una volta ogni blocco. Se un avversario si trova in un’enclave compromessa, può lentamente raccogliere chiavi e decifrare blocchi. Questo è ancora di portata limitata se si presume che ci sia un intervallo di tempo limitato tra l’essere in grado di compromettere un’enclave e risolverlo. Nel corso degli anni, man mano che le enclavi diventano sempre più testate in battaglia, questi attacchi dovrebbero diventare rari ed improbabili, ma ancora possibili. Forse è più preoccupante un nuovo validatore che è appena agli inizi e desidera elaborare tutto lo stato storico; potrebbe immediatamente prendere un’enclave compromessa e imparare tutta la storia.
Questa preoccupazione dev’essere affrontata con una qualche forma di segretezza avanzata per blockchain che preservano la privacy ed è probabilmente rilevante se si utilizzano enclavi di soluzioni crittografiche pure che devono archiviare chiavi nella rete. La segretezza avanzata comporta essenzialmente che qualsiasi chiave specifica si perda, non dovrebbe rivelare più di una piccola quantità di informazioni (ad esempio, una singola transazione o un blocco di dati). Questo è in una certa misura raggiunto dalla mia proposta di cui sopra, ma dovrebbe esserci anche un meccanismo che limiti la propria capacità di recuperare tutte le chiavi in una volta sola.
Ciò è attualmente un argomento di ricerca aperto che stiamo esaminando ed invitiamo altri ricercatori a collaborare con noi! Potenzialmente ha anche molte altre implicazioni.
Calcoli a due parti
Secret 1.0 ha una proprietà molto interessante e peculiare: può archiviare e operare su dati privati mentre, come qualsiasi blockchain, è sempre online e garantisce un’esecuzione corretta del codice del contratto.
Ciò presenta un tipo davvero interessante di applicazioni, in particolare per dati estremamente sensibili come wallet e chiavi crittografiche, password e seed, in cui potremmo non volerci fidare completamente della sola SGX, e similmente, gli utenti stessi non vorrebbero fidarsi di se stessi per gestire correttamente quelle chiavi.
Il caso d’uso attuale più interessante ed utile che vediamo è quello dei portafogli a soglia inarrestabile, ma questo dovrebbe servire solo da esempio. Questi wallet essenzialmente dividono la loro chiave tra un utente e Secret: ciascuno ottiene una quota. Su Secret, un utente può definire una politica di accesso, in modo tale che se la sua chiave è completamente compromessa, la catena noterà un comportamento sospetto (ad esempio, qualcuno che cerca di prosciugare il wallet) e lo bloccherebbe. D’altra parte, è abbastanza ragionevole presumere che nessun utente malintenzionato sarà in grado di compromettere sia la quota memorizzata sulla rete che la quota del portafoglio dell’utente, soprattutto se continuiamo ad utilizzare tecniche come la condivisione segreta proattiva che aggiorna le condivisioni di tanto in tanto.
Per abilitare questa tecnica, avremmo bisogno di aggiungere supporto e costruire diversi blocchi in Secret, come la crittografia additiva omomorfa e i protocolli di firma della soglia. Avremo bisogno di riadattarli per funzionare senza essere compilati in WASM per problemi di prestazioni/costo del gas (simile a ciò che ha fatto Ethereum in passato con la verifica in catena di alcune prove a conoscenza zero “zero-knowledge proofs”). Uno di questi progetti pilota è attualmente pianificato con un partner di progettazione.
Ciò dovrebbe illustrare una classe molto più ampia di calcoli a due parti, in cui il materiale sensibile di un utente viene suddiviso tra l’utente stesso e Secret.
E adesso?
Qui ribadirò ciò che è sempre stato parte della missione di Secret Network: portare sul mercato soluzioni pragmatiche per la privacy in modo che possano essere utilizzate in produzione da milioni di utenti nel mondo.
L’ecosistema Secret, dai suoi sviluppatori principali ai suoi validatori, dalle sue dApp ai suoi appassionati utenti, ha dimostrato che farà tutto il necessario per garantire che la nostra visione di un futuro Web3 più sicuro, diventi realtà. Ciò ha portato, negli ultimi anni, alla creazione e all’utilizzo di applicazioni che sono all’avanguardia nel nostro settore. Ora ti chiediamo di unirti a noi mentre aggiorniamo la nostra rete dalla sua prima forma a quella futura più potente: una costellazione di soluzioni per la privacy interconnesse che rafforzano le basi collettive.
Ci sono molti altri argomenti che avremmo potuto toccare in questo post, incluso il ridimensionamento verticale tramite rollup, il ridimensionamento orizzontale tramite IBC e molto altro. Questo è solo un primo sguardo a Secret 2.0, che sarà un’impresa molto complessa che includerà un notevole sforzo della comunità.
Oggi abbiamo dozzine di dApp private per impostazione predefinita che sfruttano Secret Network; in pochi anni puntiamo ad averne migliaia. Oggi abbiamo 250.000 account su Secret; miriamo a raggiungerne milioni. Combinando questi miglioramenti tecnici con un approccio aggressivo alla crescita di sviluppatori e utenti, possiamo garantire che ogni utente del Web3 abbia accesso a solide soluzioni per la privacy.
Un Internet più decentralizzato richiede che la privacy sia davvero brillante. Allo stesso modo, le soluzioni per la privacy richiederanno la decentralizzazione per essere sostenibili. Secret Network è il punto in cui la decentralizzazione e la privacy si intersecano, fornendo le giuste basi per gli utenti sia ora che in futuro.
— — — — — — — — — — — — — — — — — — — — — — — — — — —
Mettiti in contatto
Gran parte di quanto sopra proposto è già un’area attiva di ricerca e sviluppo, ma siamo costantemente alla ricerca dei migliori partner mentre continuiamo a perseguire l’obiettivo dell’adozione globale. Se sei un ricercatore, uno sviluppatore o un team indipendente interessato a partecipare a questo sforzo o ad una joint venture, contatta SCRT Labs tramite e-mail: info@scrtlabs.com
Secret Network ha anche sovvenzioni e altre risorse disponibili per gli sviluppatori che vogliono contribuire alla nostra missione riguardante la privacy. Se sei interessato a creare le tue Secret dApp, dai un’occhiata alle nostre risorse per sviluppatori e scopri come ottenere finanziamenti per supportare i tuoi progetti!
Se sei un appassionato garante della privacy degli utenti del Web3, della protezione dei dati di cui hanno bisogno e che meritano, diventa un agente segreto! La nostra missione è assicurarci che il web decentralizzato che stiamo costruendo sia davvero uno strumento di potenziamento accessibile a tutti. Dalla consapevolezza all’educazione, dalla crescita internazionale alle relazioni universitarie, ci sono molti modi per aiutare ad espandere l’ecosistema di Secret e la disponibilità globale delle tecnologie per la privacy.
Dai un’occhiata al programma degli Agenti Segreti e unisciti a una delle comunità migliori e più impegnate nell’intero spazio blockchain!
In Avanti e verso l’Alto!
Per discutere di Secret Network e delle Secrets dApp, visita i canali della nostra comunità:
