Siamo interessati da molto tempo al tema dell'anonimato nelle criptovalute e cerchiamo di seguire lo sviluppo delle tecnologie in questo settore. Nei nostri articoli abbiamo già discusso in dettaglio i principi di funzionamento in Monero, e anche effettuato tecnologie esistenti in questo campo. Tuttavia, tutte le criptovalute anonime oggi sono costruite sul modello di dati proposto da Bitcoin - Unspent Transaction Output (di seguito UTXO). Per le blockchain basate su account come Ethereum, le soluzioni esistenti per implementare l'anonimato e la riservatezza (ad esempio, o ) ha cercato di replicare il modello UTXO nei contratti intelligenti.
Nel febbraio 2019, un gruppo di ricercatori dell'Università di Stanford e Visa Research rilasciato "Zether: Verso la privacy nel mondo dei contratti intelligenti." Gli autori sono stati i primi a proporre un approccio per garantire l'anonimato nelle blockchain basate su account e hanno presentato due versioni di un contratto intelligente: per transazioni riservate (nascondere saldi e importi di trasferimento) e anonime (nascondere il destinatario e il mittente). Troviamo interessante la tecnologia proposta e vorremmo condividerne la struttura, nonché parlare del motivo per cui il problema dell'anonimato nelle blockchain basate su account è considerato molto difficile e se gli autori sono riusciti a risolverlo completamente.
Sulla struttura di questi modelli di dati
Nel modello UTXO, una transazione è composta da “input” e “output”. Un analogo diretto delle “uscite” sono le banconote nel tuo portafoglio: ogni “uscita” ha un valore nominale. Quando paghi qualcuno (forma una transazione) spendi uno o più “output”, nel qual caso diventano “input” della transazione e la blockchain li contrassegna come spesi. In questo caso, il destinatario del pagamento (o tu stesso, se hai bisogno di resto) riceve gli “output” appena generati. Ciò può essere rappresentato schematicamente in questo modo:
Le blockchain basate su account sono strutturate in modo molto simile al tuo conto bancario. Si occupano solo dell'importo nel tuo account e dell'importo del trasferimento. Quando trasferisci una somma dal tuo conto, non bruci nessun “output”, la rete non ha bisogno di ricordare quali monete sono state spese e quali no. Nel caso più semplice, la verifica della transazione si riduce al controllo della firma del mittente e dell’importo sul suo saldo:
Analisi della tecnologia
Successivamente parleremo di come Zether nasconde l'importo della transazione, il destinatario e il mittente. Mentre descriviamo i principi del suo funzionamento, noteremo le differenze tra la versione riservata e quella anonima. Poiché è molto più semplice garantire la riservatezza nelle blockchain basate su account, alcune delle restrizioni imposte dall’anonimizzazione non saranno rilevanti per la versione riservata della tecnologia.
Nascondere saldi e importi di trasferimento
Uno schema di crittografia viene utilizzato per crittografare i saldi e trasferire gli importi in Zether . Funziona come segue. Quando Alice vuole mandare Bob b monete per indirizzo (la sua chiave pubblica) Y, sceglie un numero casuale r e crittografa l'importo:
dove C - importo crittografato, D - valore ausiliario necessario per decifrare questo importo, G - un punto fisso sulla curva ellittica, moltiplicato per la chiave segreta si ottiene la chiave pubblica.
Quando Bob riceve questi valori, li aggiunge semplicemente allo stesso modo al suo saldo crittografato, motivo per cui questo schema è conveniente.
Allo stesso modo, Alice sottrae gli stessi valori dal suo saldo, solo come Y utilizza la tua chiave pubblica.
Nascondere il destinatario e il mittente
Il mescolamento degli "output" in UTXO risale agli albori delle criptovalute e aiuta a nascondere il mittente. Per fare questo, il mittente stesso, quando effettua un bonifico, raccoglie degli “output” casuali nella blockchain e li mescola con i propri. Successivamente, firma gli “output” con una firma ad anello, un meccanismo crittografico che gli consente di convincere il verificatore che le monete del mittente sono presenti tra gli “output” coinvolti. Le monete miste stesse, ovviamente, non vengono spese.
Tuttavia, non saremo in grado di generare output falsi per nascondere il destinatario. Pertanto, in UTXO, ogni “output” ha il proprio indirizzo univoco ed è crittograficamente collegato all’indirizzo del destinatario di queste monete. Al momento non è possibile identificare la relazione tra l'indirizzo univoco di output e l'indirizzo del destinatario senza conoscerne le chiavi segrete.
Nel modello basato sugli account non possiamo utilizzare indirizzi una tantum (altrimenti sarebbe già un modello di “uscite”). Pertanto, il destinatario e il mittente devono essere mescolati tra gli altri conti nella blockchain. In questo caso, sui conti misti viene addebitato uno 0 crittografato (o vengono aggiunti 0 se il destinatario è misto), senza modificare effettivamente il loro saldo reale.
Poiché sia il mittente che il destinatario hanno sempre un indirizzo permanente, diventa necessario utilizzare gli stessi gruppi per la miscelazione durante il trasferimento agli stessi indirizzi. È più facile vederlo con un esempio.
Diciamo che Alice decide di dare un contributo all'organizzazione benefica di Bob, ma preferisce che il trasferimento rimanga anonimo per un osservatore esterno. Poi, per camuffarsi nel campo mittente, entra anche nei conti di Adam e Adele. E per nascondere Bob, aggiungi gli account di Ben e Bill nel campo del destinatario. Nel contributo successivo, Alice ha deciso di scrivere accanto a lei Alex e Amanda, e accanto a Bob Bruce e Benjen. In questo caso, quando si analizza la blockchain, in queste due transazioni c'è solo una coppia di partecipanti intersecanti: Alice e Bob, che rende anonime queste transazioni.
Gare di transazione
Come abbiamo già accennato, per nascondere il saldo nei sistemi basati su account, l'utente crittografa il suo saldo e l'importo del trasferimento. Allo stesso tempo, deve dimostrare che il saldo del suo conto rimane non negativo. Il problema è che quando si crea una transazione, l'utente crea una prova relativa allo stato del suo conto corrente. Cosa succede se Bob invia una transazione ad Alice e questa viene accettata prima di quella inviata da Alice? Quindi la transazione di Alice verrà considerata non valida, poiché la prova del saldo è stata creata prima che la transazione di Bob fosse accettata.
La prima decisione che si prende in una situazione del genere è quella di congelare il conto fino al completamento della transazione. Ma questo approccio non è adatto, perché oltre alla complessità di risolvere un problema del genere in un sistema distribuito, in uno schema anonimo non sarà chiaro quale account bloccare.
Per risolvere questo problema, la tecnologia separa le transazioni in entrata da quelle in uscita: la spesa ha un effetto immediato sul bilancio, mentre le entrate hanno un effetto ritardato. Per fare ciò, viene introdotto il concetto di "epoca": un gruppo di blocchi di dimensioni fisse. L'attuale "epoca" viene determinata dividendo l'altezza del blocco per la dimensione del gruppo. Durante l’elaborazione di una transazione, la rete aggiorna immediatamente il saldo del mittente e conserva i fondi del destinatario in un serbatoio di stoccaggio. I fondi accumulati vengono messi a disposizione del beneficiario solo quando inizia una nuova “era”.
Di conseguenza, l’utente può inviare transazioni indipendentemente dalla frequenza con cui riceve i fondi (ovviamente nella misura in cui il suo saldo lo consente). La dimensione dell'epoca viene determinata in base alla velocità con cui i blocchi si propagano attraverso la rete e alla velocità con cui una transazione entra in un blocco.
Questa soluzione funziona bene per i trasferimenti riservati, ma con le transazioni anonime, come vedremo in seguito, crea seri problemi.
Protezione contro gli attacchi di riproduzione
Nelle blockchain basate su account, ogni transazione è firmata dalla chiave privata del mittente, che convince il verificatore che la transazione non è stata modificata ed è stata creata dal proprietario di questa chiave. Ma cosa succede se un utente malintenzionato che sta ascoltando il canale di trasmissione intercetta questo messaggio e invia esattamente lo stesso secondo? Il verificatore verificherà la firma della transazione e si convincerà della sua paternità, e la rete cancellerà nuovamente lo stesso importo dal saldo del mittente.
Questo attacco è chiamato attacco replay. Nel modello UTXO tali attacchi non sono rilevanti, poiché l’aggressore tenterà di utilizzare gli output spesi, che di per sé non sono validi e vengono rifiutati dalla rete.
Per evitare che ciò accada, nella transazione viene integrato un campo con dati casuali, chiamato nonce o semplicemente “salt”. Quando si reinvia una transazione con un salt, il verificatore controlla se il nonce è stato utilizzato in precedenza e, in caso contrario, considera la transazione valida. Per non memorizzare l'intera cronologia dei nonce degli utenti nella blockchain, solitamente nella primissima transazione viene impostato uguale a zero, quindi incrementato di uno. La rete può solo verificare che il nonce della nuova transazione differisca di volta in volta dalla precedente.
Nello schema di trasferimento anonimo si pone il problema della validazione dei nonce delle transazioni. Non possiamo associare esplicitamente il nonce all'indirizzo del mittente, poiché, ovviamente, questo rende anonimo il trasferimento. Inoltre, non possiamo aggiungerne uno ai nonce di tutti gli account partecipanti, poiché ciò potrebbe entrare in conflitto con altri trasferimenti in fase di elaborazione.
Gli autori di Zether propongono di generare il nonce crittograficamente, a seconda dell’“epoca”. Per esempio:
Qui x è la chiave segreta del mittente e Gepoch — un generatore aggiuntivo per l'epoca, ottenuto eseguendo l'hashing di una stringa nella forma 'Zether + '. Ora il problema sembra essere risolto: non riveliamo il nonce del mittente e non interferiamo con i nonce dei partecipanti non coinvolti. Ma questo approccio impone una seria limitazione: un conto non può inviare più di una transazione per “epoca”. Questo problema purtroppo rimane irrisolto e attualmente rende la versione anonima di Zether, a nostro avviso, poco adatta all'uso.
La complessità delle prove a conoscenza zero
In UTXO il mittente deve dimostrare alla rete che non sta spendendo una cifra negativa, altrimenti diventa possibile generare nuove monete dal nulla (perché questo è possibile, abbiamo scritto in uno dei precedenti ). E firmare anche gli “input” con la firma ad anello per dimostrare che tra le monete mescolate ci sono fondi che gli appartengono.
Nella versione anonima della blockchain basata su account, le espressioni per la prova sono molto più complesse. Il mittente dimostra che:
- L'importo inviato è positivo;
- Il saldo resta non negativo;
- Il mittente ha crittografato correttamente gli importi del trasferimento (incluso lo zero);
- Il saldo sul saldo cambia solo per il mittente e per il destinatario;
- Il mittente possiede la chiave privata del suo account ed è effettivamente presente nell'elenco dei mittenti (tra quelli coinvolti);
- Il Nonce utilizzato nella transazione è composto correttamente.
Per una dimostrazione così complessa, gli autori utilizzano una miscela (uno degli autori, tra l'altro, ha preso parte alla sua creazione) e , che sono chiamati proiettili Sigma. La prova formale di tale affermazione è un compito piuttosto difficile e limita notevolmente il numero di persone disposte a implementare la tecnologia.
Il risultato?
A nostro avviso, la parte di Zether che porta la privacy nelle blockchain basate sugli account può essere utilizzata in questo momento. Ma al momento, la versione anonima della tecnologia impone gravi restrizioni al suo utilizzo e la sua complessità alla sua implementazione. Non è però da escludere che gli autori lo abbiano pubblicato solo pochi mesi fa, e forse qualcun altro troverà una soluzione ai problemi che esistono oggi. Dopotutto, è così che si fa la scienza.
Fonte: habr.com