Loading...
Questo articolo è ripubblicato da Proof Street, una pubblicazione indipendente che si occupa di calcolo che preserva la privacy: ZK, FHE, MPC, TEEs e identità decentralizzata. Pubblicato originariamente come "Confidentiality compared: what four privacy architectures promise" il 12 agosto 2026. Ripubblicato con il permesso dell'autore come parte di Zcash Community Grant #339. Di Stephen Webber.
Alla fine di luglio, Zama ha attivato su Ethereum mainnet una piattaforma di swap confidenziali, in beta privata in vista di un lancio pubblico a settembre, che consente a un trader di inviare un intent cifrato che nasconde l'importo, la tolleranza allo slippage e la direzione dell'operazione.
Per farlo si affida a una piccola coreografia. Il trader deposita due trasferimenti confidenziali, uno contenente gli asset effettivi e uno per la gamba opposta con importo zero, così che un osservatore veda un movimento bidirezionale di entità nascosta e non possa distinguere un acquisto da una vendita. I market maker autorizzati decifrano l'intent, vedono la dimensione ma non la direzione, e quotano entrambi i lati. Un'asta a offerte sigillate regola il tutto on chain, e solo il market maker vincitore apprende in quale direzione si è mosso lo scambio. Il risultato netto è uno swap eseguito per importi rilevanti su una chain pubblica, in cui nessuna singola parte esterna all'operazione ricostruisce mai il quadro completo.
Zama descrive il prodotto come confidenziale end-to-end, ma che cosa comporta davvero questa riservatezza? Qui la riservatezza richiede riservatezza lungo un'intera catena di azioni, per cui il pubblico vede una cosa, gli offerenti perdenti ne vedono di più, dato che hanno decifrato la dimensione dell'operazione per poterla quotare, e l'offerente vincitore ne vede ancora di più. In parole semplici, ogni fase della sequenza è così perché qualcuno ha preso una decisione su chi deve sapere cosa e quando. Sarebbe bello riassumere la riservatezza con "Nessuno vede niente", ma in pratica nulla funzionerebbe. La riservatezza deve essere strutturata e deve seguire una sequenza.
L'aspetto interessante è che quasi dieci anni prima di quel lancio, Zcash ha introdotto il primo layer di regolamento confidenziale su una blockchain pubblica, usando prove a conoscenza zero per nascondere mittente, destinatario e importo di una transazione, dimostrando al tempo stesso a tutti che la transazione era valida. Nel decennio successivo, "confidenziale" è diventato l'aggettivo di almeno quattro famiglie tecnologiche distinte: transazioni schermate, crittografia completamente omomorfica, calcolo multi-parte e ambienti di esecuzione attendibili. Prodotti di tutte e quattro le famiglie ora operano in produzione, diversi dei quali sulla stessa chain. Quindi, cosa c'è dentro la scatola?
Le quattro famiglie offrono risposte diverse, e talvolta sovrapposte, a quattro problemi differenti, e poiché ogni risposta oggi arriva confezionata come prodotto, il compito reale è capire quale problema si ha davvero.
Qualsiasi affermazione di riservatezza, una volta ridotta all'essenziale, deve rispondere a quattro domande. Quali dati vengono nascosti? A chi? Durante quale fase della vita dei dati? E che cosa deve essere considerato affidabile affinché la garanzia resti valida?
Come esempio, prendiamo la piattaforma di swap. Deve nascondere importo, direzione e slippage. Perché non la coppia di asset? Zama afferma che una versione futura nasconderà anche quella. A chi: al pubblico e ai bot di front-running completamente, ai market maker che fanno le quotazioni parzialmente, al market maker vincitore meno che a chiunque altro. Durante quale fase: durante quotazione e asta, con una divulgazione progettata al momento del regolamento. E di chi ci si deve fidare: la garanzia poggia sulla FHE stessa, sugli smart contract e su un sistema di gestione delle chiavi a soglia i cui operatori non devono colludere oltre una certa soglia. Secondo il litepaper, nessuna singola parte può mai accedere alle chiavi di decifratura.
È un progetto per eseguire operazioni di grande entità senza trasmettere la strategia. I market maker vedono la dimensione perché non possono formulare una quotazione senza di essa. Il vincitore apprende la direzione perché, naturalmente, il regolamento lo richiede.
Ciò che mostra l'esempio è che un'affermazione che suona binaria, come se qualcosa fosse confidenziale oppure no, in realtà si scompone in un programma di esclusioni. Ci sono modi molto diversi di arrivare ad affermazioni che suonano uguali.
Una transazione schermata di Zcash nasconde il mittente, il destinatario e l'importo. Ciò che resta pubblico è la prova: un argomento a conoscenza zero, verificabile da chiunque esegua un nodo, che dimostra che la transazione nascosta segue le regole. I fondi schermati esistono come note crittografate, ciascuna un record privato di un importo e del suo proprietario che appare on-chain solo come commitment crittografico. Spendere una nota pubblica un nullifier, un valore che impedisce che la stessa nota venga mai spesa due volte senza rivelare quale nota fosse. Questo significa che la rete può rifiutare le doppie spese senza mai apprendere quali fondi si sono mossi, quindi la spesa non lascia tracce che colleghino una transazione a un'altra. Il compito della prova è stabilire che chi spende possedeva la nota, che i valori della transazione sono in equilibrio e che nessun ZEC è stato creato o distrutto, il tutto senza divulgare alcuna delle quantità coinvolte.
La proprietà distintiva di questo design appare con maggiore evidenza se si considera di cosa ci si deve fidare. Non esiste alcun comitato che possa decifrare una transazione schermata, nessun insieme di operatori la cui soglia di collusione sia rilevante, nessun fornitore hardware la cui attestazione debba essere creduta. Ciò che resta nella base di fiducia è la matematica e la correttezza dei circuiti che codificano le regole. Per chiunque abbia un modello di minaccia che include l'infrastruttura stessa, operatori su cui si può fare pressione, fornitori che possono essere compromessi, quella lista breve è il prodotto.
Di fatto, questa base di fiducia è stata appena messa alla prova in produzione. Il 29 maggio, Taylor Hornby, un ricercatore di sicurezza impegnato in un audit per Shielded Labs, ha individuato un difetto di solidità nel circuito di prova della pool Orchard, presente dal lancio della pool nel 2022, che, secondo la divulgazione di Shielded Labs, avrebbe potuto consentire di coniare quantità illimitate di ZEC contraffatto all'interno di Orchard senza alcuna traccia on-chain.
La correzione d'emergenza è stata distribuita in cinque giorni: Orchard è stato messo in pausa il 2 giugno, poi ripristinato il 3 giugno con un circuito corretto. Il post di remediation di ZODL ha descritto l'impatto in modo più circoscritto rispetto a Shielded Labs, parlando di un rischio di double-spend all'interno della pool piuttosto che di offerta contraffatta, e riportando che la privacy degli utenti e il tetto dell'offerta totale non sono stati compromessi.
La ricostruzione della verificabilità è arrivata più tardi. Ironwood, attivato come NU6.3 il 28 luglio, sigilla definitivamente la pool Orchard, apre una nuova pool basata sul circuito corretto, supportata da audit indipendenti e attività di verifica formale, e instrada tutti i fondi in uscita attraverso un turnstile (tornello) che limita i prelievi a quanto è entrato verificabilmente, ripristinando la possibilità per ogni utente di controllare in modo indipendente l'offerta circolante senza vedere le transazioni di nessuno. Questo episodio mostra in azione il registro della base di fiducia. Quando la correttezza del circuito è venuta meno, il rimedio è stato matematica e migrazione, non la discrezionalità di un comitato, e il raggio d'impatto è stato contenuto dalla verificabilità che l'architettura aveva incorporato al confine della pool anni prima.
Ciò che lo shielding offre in cambio di questa base di fiducia minima è deliberatamente circoscritto. Lo stato nascosto è un pagamento, valore che si sposta da una parte a un'altra. Non esiste uno stato condiviso cifrato su cui molte parti eseguono calcoli, nessuna logica contrattuale confidenziale e nessun order book cifrato.
La FHE consente di eseguire calcoli su testi cifrati. Nel protocollo di Zama, nella versione oggi attiva su Ethereum, i saldi e gli importi dei trasferimenti esistono on-chain come handle cifrati secondo la bozza dello standard ERC-7984, i coprocessori eseguono l'aritmetica cifrata off-chain, e la decifratura richiede un quorum di operatori indipendenti di gestione delle chiavi, tredici organizzazioni al lancio su mainnet, selezionate per reputazione e partecipazioni operative, così che nessuna singola parte possa leggere i dati. Questo è ciò che rende possibile un order book cifrato o una pool di prestito confidenziale: lo stato nascosto di molte parti che si compone all'interno di una logica contrattuale condivisa.
Ma che dire del comitato di gestione delle chiavi? Qualcuno deve essere in grado di decifrare, altrimenti i dati non sono utilizzabili. La risposta del design è fare in modo che quel qualcuno sia una soglia di operatori indipendenti anziché un singolo custode, e governare chi può decifrare quali valori tramite il controllo degli accessi scritto direttamente nei contratti stessi, estendibile a parti designate come auditor, un meccanismo di delega le cui implicazioni di compliance appartengono alla prossima parte di questa serie. La domanda per chi valuta le soluzioni è se la composizione, gli incentivi e la soglia del comitato corrispondano al suo modello di minaccia.
La multi-party computation divide i dati in share distribuite tra nodi indipendenti, che calcolano congiuntamente un risultato senza che alcun nodo ricostruisca gli input. Avishay Yanai, co-fondatore e CEO di Soda Labs, la cui macchina virtuale a garbled-circuit esegue in produzione sulla rete COTI una logica contrattuale compatibile con EVM su valori cifrati, descrive un buon design MPC in produzione come qualcosa che assicura che nessuna singola parte, che si tratti di un osservatore, di un nodo che esegue il calcolo o del fornitore, veda mai input in chiaro o stato intermedio, e che tutti vedano solo ciò che la policy di divulgazione concede loro. La garanzia dipende solo dalla non-collusione, e questa è un'ipotesi su cui si può intervenire a livello ingegneristico e contrattuale, ad esempio con operatori in giurisdizioni separate, su cloud separati e sottoposti ad audit indipendenti, con responsabilità legale in caso di collusione. Il compito della crittografia qui è ciò che lui definisce una tremenda riduzione della fiducia, piuttosto che l'eliminazione della fiducia, per raggiungere un'equivalenza con la fiducia che le istituzioni ripongono nelle clearinghouse. La collusione oltre la soglia compromette la privacy, ma non la correttezza, poiché nei design con auditabilità pubblica i validatori esterni possono comunque verificare che i risultati riportati siano corretti senza partecipare al calcolo.
L'avvertenza è semplicemente che un osservatore di questo tipo vede che una transazione è avvenuta, quando, contro quale contratto, chi l'ha inviata, oltre alle dimensioni dei batch e alle commissioni. Un nodo partecipante può apprendere quale funzione è stata eseguita e i relativi pattern di throughput. Anche la correlazione temporale è un elemento da considerare, poiché i livelli di attività possono trapelare anche quando gli importi non lo fanno. E qualunque cosa l'applicazione produca in chiaro, piccole divulgazioni ripetute potrebbero crescere fino a formare pattern potenziali per una parte che li stia cercando attivamente. "È il confine della promessa", chiarisce, quindi chi valuta dovrebbe pretendere che i fornitori lo traccino in modo esplicito. Nessun modello computazionale rimedia all'invio di dati in chiaro, per esempio da parte di un client compromesso. Il protocollo calcola fedelmente su qualunque cosa gli venga fornita. Chi parla con chi è un problema di trasporto, e la compliance è una questione di policy più che di meccanismo: "Nessuna crittografia prende quel giudizio al posto tuo."
I design a garbled-circuit funzionano in round costanti, con il materiale crittografico pesante precalcolato prima che gli input esistano, ed è questo che rende praticabili i carichi di lavoro a tasso di transazione, laddove i protocolli di secret-sharing pagano round trip di rete per ogni operazione, e dove, secondo Yanai, alcune famiglie MPC proteggono i valori ma non il fatto stesso del calcolo, i design a garbled-circuit possono estendere la copertura anche agli indirizzi delle controparti e ai tipi di asset. Tuttavia, la proprietà più rilevante di questa famiglia per questo confronto è che MPC è un'architettura a sé stante ed è anche un ingrediente interno alle altre famiglie: il comitato di chiavi a soglia sotto un deployment FHE è esso stesso una multi-party computation. La domanda di chi valuta, nella formulazione di Yanai, è: "che cosa fa il mio comitato, e che cosa pago in aggiunta?" Se il comitato esiste in entrambi i casi, eseguire direttamente il calcolo in MPC può eliminare un costoso livello esterno.
Vale la pena chiarire che con lo stesso acronimo si discutono due prodotti molto diversi. La custody MPC divide una chiave di firma tra diverse parti così che nessuna di esse possa firmare da sola; protegge un solo segreto, e il calcolo congiunto coinvolto è una singola operazione fissa, la produzione di una firma. La compute MPC esegue una logica di programma generale su dati che restano nascosti per tutto il tempo e coinvolge input di molte parti, logica contrattuale arbitraria e operatività continua. La matematica è ciò che accomuna le due cose. Sul piano operativo, però, una si usa per la gestione delle chiavi e l'altra è un ambiente di esecuzione confidenziale.
Un TEE è una regione di un processore isolata via hardware che mantiene i dati cifrati in memoria e protetti dal sistema operativo, dall'hypervisor e dall'operatore della macchina, con attestazione remota che permette a una parte esterna di verificare quale codice venga eseguito all'interno. Questo design acquista le due cose per cui le famiglie crittografiche pagano a caro prezzo, generalità e velocità: un'enclave esegue programmi ordinari a un costo vicino a quello ordinario, ed è per questo che i TEE sostengono la maggior parte delle offerte di confidential compute dei grandi cloud e un insieme crescente di infrastrutture di chain.
La base di fiducia è il compromesso, perché la garanzia è forte solo quanto lo sono il design e la supply chain del fornitore hardware, l'infrastruttura di attestazione e la resistenza dell'enclave all'estrazione tramite side-channel, una classe di attacco con una lunga storia documentata. I progettisti di TEE conoscono questo registro meglio dei loro critici. Scegliere questa architettura significa fare una scommessa ponderata sul fatto che fiducia nell'hardware più attestazione siano il giusto prezzo da pagare per eseguire carichi di lavoro reali a velocità reali, e per molti deployment lo sono.
Le transazioni schermate di Zcash potrebbero servire il caso d'uso di una piattaforma di trading confidenziale? No, ma non è un limite. Una piattaforma RFQ è uno stato condiviso cifrato sotto logica contrattuale, dove gli intent nascosti di molte parti si compongono all'interno di un'asta che a sua volta opera alla cieca. Questo è più adatto a qualcosa come MPC, con stato privato condiviso sotto interazione frequente, un order book, un ciclo di compensazione. La schermatura non ha un substrato per questo; il suo stato nascosto è un pagamento tra due parti. La piattaforma stessa si adatta meglio a FHE o MPC, e vale la pena notare che quando Zama l'ha costruita, la riservatezza che offre è un programma di divulgazioni verso market maker autorizzati e identificati, il che è necessario per il trading istituzionale. Ma questo è un prodotto diverso da ciò che offre una transazione schermata, che è riservatezza senza whitelist e senza una parte che alla fine apprenda la direzione della tua operazione.
E per quanto riguarda i pagamenti aziendali e le buste paga? Questo è un mercato a cui oggi puntano tutti i fornitori FHE e MPC, ed è esattamente il problema per cui la schermatura è stata costruita: importi nascosti, controparti nascoste, validità pubblica. In linea di principio una chain schermata è la risposta con la base di fiducia più forte disponibile, nessun comitato, nessun fornitore, nessun insieme di operatori. In pratica il mercato dei pagamenti aziendali si vince sulle infrastrutture di pagamento, sull'integrazione ERC-20, sui custodi esistenti, sugli strumenti di conformità esistenti, sulle denominazioni in stablecoin, e Zcash schermato offre un asset diverso su una chain diversa. Ma è un buon adattamento a livello di forma del problema ed è semplicemente in attesa di integrazione. La crittografia può farlo, quindi le questioni pratiche riguardano ciò a cui si collega lo stack circostante.
Vale anche la pena osservare che cosa offrono le altre tre famiglie e lo shielding no: una parte che possa essere obbligata. Un comitato a soglia può ricevere un ordine del tribunale, un fornitore di enclave può essere citato in giudizio per le sue chiavi di firma e un insieme di operatori ha una giurisdizione. Un'istituzione che ha bisogno di un percorso di compliance può considerare il comitato come il prodotto. È anche, da un altro punto di vista, la vulnerabilità.
Se guardiamo di nuovo ai casi esaminati sopra, vediamo un quadro sovrapposto. La maggior parte dei deployment FHE ha sotto uno strato di MPC a soglia come livello di decifratura. Le prove a conoscenza zero certificano input cifrati prima che la FHE li consumi e, nei sistemi a garbled-circuit, possono certificarli anche a posteriori, offrendo agli utenti una forced exit che non dipende dalla disponibilità della rete, una pratica presa in prestito dalle architetture rollup. I TEE compaiono all'interno dei nodi MPC come difesa in profondità, i nodi di gestione delle chiavi di Zama eseguono la propria parte del calcolo all'interno di enclave hardware, e i TEE ospitano sempre più spesso i prover e i builder di sistemi le cui garanzie finali sono crittografiche. Un confronto scritto tra cinque anni potrebbe trovare difficile localizzare le giunture. Ma la composizione procede in una sola direzione.
Ed è per questo che la forma duratura della domanda di chi valuta non riguarda affatto "quale tecnologia". Ciò che bisogna cercare è come la riservatezza venga scandita nel tempo, che cosa venga escluso e che cosa faccia rispettare l'esclusione, che si tratti di matematica e correttezza dei circuiti, della non-collusione di un comitato, di una soglia di nodi onesti o del silicio di un fornitore. Leggi qualsiasi affermazione di riservatezza chiedendoti che cosa viene nascosto, a chi, fino a quando e sulla parola di chi, e allora saprai.
Divulgazione: questo pezzo è stato sostenuto da una Zcash Community Grant. ZCG non ha revisionato né approvato questo pezzo prima della pubblicazione. Gli impegni di finanziamento di Proof Street sono elencati nella pagina dei finanziamenti.
Pagine correlate: Pool schermate (Using_Zcash) · Chiavi di visualizzazione · la pagina "chi può vedere cosa" in Start_Here — inserire i percorsi wiki esatti