Ci siamo interessati da tempo al tema dell'anonimato nelle criptovalute e cerchiamo di seguire lo sviluppo delle tecnologie in questo campo. Nei nostri articoli abbiamo già approfondito i principi di funzionamento in Monero, e abbiamo anche condotto delle tecnologie esistenti in questo settore. Tuttavia, tutte le criptovalute anonime fino ad oggi si basano su un modello di dati proposto da Bitcoin — Unspent Transaction Output (UTXO). Per le blockchain basate su account come Ethereum, le soluzioni esistenti per implementare anonimato e riservatezza (ad esempio, o ) hanno cercato di replicare il modello UTXO nei contratti intelligenti.
Nel febbraio 2019, un gruppo di ricercatori dell'Università di Stanford e di Visa Research hanno rilasciato «Zether: Verso la privacy nel mondo dei contratti intelligenti». Gli autori hanno proposto per la prima volta un approccio per garantire l'anonimato nelle blockchain basate su account e presentato due varianti di smart contract: per transazioni confidenziali (concealment of balances and amounts) e anonime (concealment of sender and recipient). Riteniamo che la tecnologia proposta sia interessante e vorremmo condividerne il funzionamento, oltre a discutere perché la questione dell'anonimato nelle blockchain basate su account è considerata molto complessa e se gli autori siano riusciti a risolverla completamente.
Sul funzionamento di questi modelli di dati
Nella modello UTXO, la transazione è composta da «input» e «output». Un diretto analogo agli «output» sono le banconote nel tuo portafoglio: ogni «output» ha un certo valore nominale. Quando paghi qualcuno (formi una transazione), spendi uno o più «output», che diventano «input» della transazione e la blockchain li segna come spesi. Nel frattempo, il destinatario del tuo pagamento (o tu stesso, se hai bisogno di resto) riceve nuovamente «output» generati. Schmaticamente, questo può essere rappresentato così:
I blocchi basati su account funzionano in modo simile al tuo conto bancario. Operano solo sulla somma presente nel tuo conto e sulla somma del trasferimento. Quando trasferisci una somma dal tuo conto, non bruci nessun "output"; la rete non deve ricordare quali monete siano state spese e quali no. Nel caso più semplice, il controllo della transazione si riduce a verificare la firma del mittente e l'importo disponibile sul suo saldo:
Approfondimento della tecnologia
Ora parleremo di come Zether nasconda l'importo delle transazioni, il destinatario e il mittente. Durante la descrizione dei principi del suo funzionamento, annoteremo le differenze tra le versioni confidenziale e anonima. Poiché garantire la riservatezza nei blocchi basati su account è molto più semplice, alcune delle limitazioni imposte dall'anonimizzazione saranno irrilevanti per la versione confidenziale della tecnologia.
Nascondere i saldi e gli importi dei trasferimenti
Per la criptazione dei saldi e degli importi dei trasferimenti in Zether si utilizza uno schema di criptazione . Funziona nel seguente modo: quando Alice vuole inviare a Bob b monete all'indirizzo (al suo chiave pubblica) Y, sceglie un numero casuale r e cripta l'importo:
dove C — importo criptato, D — un valore ausiliario necessario per decifrare questa somma, G — un punto fisso su una curva ellittica, nel quale moltiplicando la chiave segreta si ottiene la chiave pubblica.
Quando Bob riceve questi valori, li somma semplicemente al suo saldo crittografato allo stesso modo, il che rende questo schema conveniente.
Analogamente, Alice sottrae dal suo saldo gli stessi valori, solo che utilizza la sua Y chiave pubblica.
Nascondere destinatario e mittente
Il mescolamento delle "uscite" nell'UTXO è nato all'inizio delle criptovalute ed è utile per nascondere il mittente. Per questo, il mittente durante il trasferimento seleziona casualmente "uscite" nella blockchain e le mescola con le proprie. Successivamente, firma le "uscite" con una firma ad anello - un meccanismo crittografico che permette di convincere il verificatore che tra le "uscite" mescolate siano presenti le monete del mittente. Le monete mescolate, ovviamente, non vengono spese.
Tuttavia, per nascondere il destinatario, non possiamo generare uscite false. Pertanto, in UTXO ogni "uscita" ha un suo indirizzo unico, che è crittograficamente collegato all'indirizzo del destinatario di queste monete. Attualmente non esiste un modo per rivelare la connessione tra l'indirizzo unico dell'uscita e l'indirizzo del destinatario senza conoscere le sue chiavi segrete.
Nella modello basato su account non possiamo utilizzare indirizzi monouso (altrimenti si tratterebbe già di un modello di "uscite"). Pertanto, destinatario e mittente devono essere mescolati tra altri account nella blockchain. In questo modo, dagli account mescolati viene detratti 0 monete crittografate (o viene aggiunto 0 — nel caso del mescolamento del destinatario), senza modificare effettivamente il loro saldo reale.
Poiché sia il mittente che il destinatario hanno sempre un indirizzo costante, qui sorge la necessità, nei trasferimenti verso gli stessi indirizzi, di utilizzare gli stessi gruppi per mescolare. È più facile considerare questo con un esempio.
Immagina che Alice decida di fare una donazione al fondo di Bob, ma preferisca che questa transazione rimanga anonima per un osservatore esterno. Allora, per mascherare la sua identità nel campo del mittente, inserisce anche gli account di Adam e Adele. E per nascondere Bob, nel campo del destinatario aggiunge gli account di Ben e Bill. Per la successiva donazione, Alice decide di inserire accanto a sé Alex e Amanda, e accanto a Bob Bruce e Benjamen. In questo caso, analizzando la blockchain, in queste due transazioni ci sarà solo una coppia di partecipanti in comune: Alice e Bob, il che de-anonimizza queste transazioni.
Corse delle transazioni
Come già accennato, per nascondere il proprio saldo nei sistemi basati su account, l'utente crittografa il proprio saldo e l'importo della transazione. Deve però dimostrare che il saldo sul proprio conto rimane non negativo. Il problema è che nel formare una transazione, l'utente costruisce una prova relativa al suo stato attuale del conto. E se Bob inviasse una transazione a Alice, e questa venisse accettata prima di quella inviata da Alice? In tal caso, la transazione di Alice sarebbe considerata non valida, poiché la prova del saldo è stata elaborata prima dell'accettazione della transazione di Bob.
La prima soluzione che viene in mente in una situazione del genere è congelare l'account fino al completamento della transazione. Ma questo approccio non è praticabile, perché oltre alla complessità di risolvere un problema del genere in un sistema distribuito, in uno schema anonimo non è chiaro quale account bloccare.
Per affrontare questo problema, la tecnologia separa le transazioni in entrata e in uscita: la spesa ha un effetto immediato sul saldo, mentre le entrate sono differite. Viene introdotto il concetto di «epoca» — gruppi di blocchi di dimensioni fisse. L’attuale «epoca» è determinata dal rapporto tra l’altezza del blocco e la dimensione del gruppo. Elaborando una transazione, la rete aggiorna immediatamente il saldo del mittente, mentre i fondi del destinatario vengono accumulati. I fondi accumulati diventano disponibili per il destinatario del pagamento solo quando si verifica una nuova «epoca».
Di conseguenza, l'utente può inviare transazioni indipendentemente dalla frequenza con cui riceve fondi (ovviamente nel limite del proprio saldo). La dimensione dell'epoca è determinata dalla velocità con cui i blocchi si propagano nella rete e quanto velocemente una transazione entra in un blocco.
Questa soluzione funziona bene per le transazioni riservate, ma con le transazioni anonime, come vedremo più avanti, genera seri problemi.
Protezione contro gli attacchi di replay
Nei blocchi basati su account, ogni transazione è firmata con la chiave privata del mittente, il che garantisce al validatore che la transazione non sia stata modificata e che sia stata creata dal proprietario di quella chiave. Ma cosa succede se un malintenzionato, che sta ascoltando il canale di trasmissione, intercetta questo messaggio e invia un secondo messaggio identico? Il validatore confronterà la firma della transazione e sarà convinto della sua autenticità, e la rete detrarrà nuovamente la stessa somma dal saldo del mittente.
Questa attacco viene chiamato attacco di replay. Nel modello UTXO, tali attacchi non sono rilevanti, poiché il malintenzionato cercherebbe di utilizzare uscite già spese, il che non è valido e viene rifiutato dalla rete.
Per evitare che ciò accada, nella transazione viene inserito un campo con dati casuali, chiamato nonce o semplicemente "sale". Quando viene reinviata la transazione con il "sale", il soggetto che verifica controlla se questo nonce è stato utilizzato in precedenza e, se non lo è, considera la transazione valida. Per non memorizzare nella blockchain tutta la storia dei nonce degli utenti, di solito nella prima transazione viene accettato come uguale a zero, e poi viene incrementato di uno. Resta solo da controllare che il nonce della nuova transazione differisca da quello precedente di uno.
Nello schema di trasferimento anonimo emerge il problema della validazione dei nonce delle transazioni. Non possiamo associare i nonce in modo esplicito all'indirizzo del mittente, poiché ciò svelerebbe chiaramente l'identità del trasferimento. Non possiamo nemmeno aumentare di uno i nonce di tutti gli account coinvolti, poiché ciò potrebbe entrare in conflitto con altre transazioni in fase di elaborazione.
Gli autori di Zether propongono di generare i nonce in modo crittografico, a seconda dell'"epoca". Ad esempio:
Qui x — la chiave segreta del mittente, e Gepoch — un generatore aggiuntivo per epoche, ottenuto tramite l'hashing di una stringa del tipo 'Zether +'. Ora, apparentemente, il problema è risolto: non riveliamo il nonce del mittente e non interferiamo con i nonce dei partecipanti non coinvolti. Tuttavia, questo approccio impone una grave limitazione: un account può inviare non più di una transazione per 'epoca'. Purtroppo, questo problema rimane irrisolto e, al momento attuale, rende la versione anonima di Zether, a nostro avviso, poco praticabile.
Difficoltà delle prove a zero conoscenze
Nel sistema UTXO, il mittente deve dimostrare alla rete che non sta spendendo un importo negativo, altrimenti è possibile generare nuove monete dal nulla (perché ciò sia possibile, ne abbiamo parlato in uno dei precedenti ). Deve inoltre firmare gli 'ingressi' con una firma ad anello, per dimostrare che tra le monete miscelate ci sono fondi che gli appartengono.
Nella versione anonima della blockchain basata su account, le espressioni per la prova diventano molto più complesse. Il mittente dimostra che:
- L'importo inviato è positivo;
- Il saldo rimane non negativo;
- Il mittente ha correttamente criptato gli importi delle transazioni (compresi quelli nulli);
- Il saldo cambia solo per il mittente e il destinatario;
- Il mittente possiede la chiave segreta del proprio account ed è effettivamente presente nell'elenco dei mittenti (tra i coinvolti);
- Il nonce utilizzato nella transazione è stato composto correttamente.
Per una prova così complessa, gli autori utilizzano una miscela (uno degli autori, per inciso, ha partecipato alla sua creazione) e , chiamato Sigma-bullets. La prova formale di tale affermazione è un compito piuttosto complesso e limita notevolmente il numero di persone intenzionate a implementare la tecnologia.
Quali sono i risultati finali?
A nostro avviso, la parte Zether che introduce la riservatezza nei blockchain basati su account può essere utilizzata già adesso. Tuttavia, l'attuale versione anonima della tecnologia impone gravi limitazioni al suo utilizzo, e la sua complessità complica l'implementazione. Tuttavia, non si deve sottovalutare che gli autori l'hanno rilasciata solo pochi mesi fa e, forse, qualcun altro troverà una soluzione ai problemi esistenti oggi. Infatti, è così che si sviluppa la scienza.
Fonte: habr.com
