Continuiamo il nostro ciclo sul funzionamento della blockchain di Monero, e l'articolo di oggi sarà dedicato al protocollo RingCT (Ring Confidential Transactions), che presenta transazioni riservate e nuove firme ad anello. Purtroppo, ci sono poche informazioni su internet su come funziona, e abbiamo cercato di colmare questa lacuna.
Parleremo di come questo protocollo consente alla rete di nascondere gli importi delle transazioni, perché si è rinunciato alle tradizionali firme ad anello di cryptonote e come questa tecnologia si svilupperà in futuro.
Poiché questo protocollo è una delle tecnologie più complesse in Monero, il lettore avrà bisogno di conoscenze di base sul funzionamento di questa blockchain e di una conoscenza superficiale della crittografia sulle curve ellittiche (per rinfrescare queste conoscenze, si possono leggere i primi capitoli del nostro precedente articolo su ).
Il protocollo RingCT
Una delle possibili attacchi alle valute cryptonote è l'analisi della blockchain, basata sulla conoscenza dell'importo e del tempo della transazione inviata. Questo consente di ristretta notevolmente il campo di ricerca delle uscite di interesse per i malintenzionati. Per proteggersi da tale analisi, Monero ha implementato un protocollo di transazioni anonime, che nasconde completamente gli importi delle transazioni nella rete.
È importante notare che l'idea di nascondere gli importi non è nuova. Uno dei primi a descriverla è stato il sviluppatore di Bitcoin Core Greg Maxwell nel suo . L'attuale implementazione di RingCT è una sua modifica con la possibilità di utilizzare firme ad anello (come si può fare senza di esse), ed è da qui che trae il suo nome — Ring Confidential Transactions.
Inoltre, il protocollo aiuta a risolvere i problemi di miscelamento delle uscite di piccole somme (di solito derivanti dai cambi di transazione), che causavano più problemi di quanto valessero.
Nel gennaio 2017 si è svolto un hard fork della rete Monero, che permette di utilizzare opzionalmente le transazioni riservate. Già a settembre dello stesso anno, con l'hard fork della versione 6, tali transazioni sono diventate le uniche autorizzate nella rete.
RingCT utilizza diversi meccanismi: firme anonime di gruppo spontanee collegate multilivello (Multilayered Linkable Spontaneous Anonymous Group Signature, in seguito — MLSAG), schema degli impegni (Pedersen Commitments) e prove di intervallo (non esiste un traduzione consolidata di questo termine in russo).
Il protocollo RingCT introduce due tipi di transazioni anonime: simple e full. Il primo tipo viene generato dal portafoglio quando la transazione utilizza più di un'entrata, il secondo — nel caso opposto. Si differenziano per la validazione delle somme delle transazioni e i dati firmati con la firma MLSAG (ne parleremo più avanti). Inoltre, le transazioni di tipo full possono essere generate con un numero qualsiasi di entrate, non c'è una differenza fondamentale. Nel libro si afferma che la decisione di limitare le transazioni full a un'unica entrata sia stata presa in fretta e potrebbe cambiare in futuro.
Firma MLSAG
Ricordiamo cosa sono le entrate firmate della transazione. Ogni transazione spende una certa quantità di fondi e genera. La generazione dei fondi avviene attraverso la creazione delle uscite della transazione (una diretta analogia è con le banconote), mentre l'uscita che la transazione spende (dopotutto, nella vita reale spendiamo proprio le banconote) diventa un'entrata (attenzione, qui è molto facile confondersi).
Un'entrata fa riferimento a diverse uscite, ma ne spende solo una, creando così una «cortina di fumo» per rendere più difficile l'analisi della cronologia delle transazioni. Se una transazione ha più di un'entrata, questa struttura può essere rappresentata come una matrice, dove le righe sono le entrate e le colonne sono le uscite coinvolte. Per dimostrare alla rete che la transazione spende effettivamente le proprie uscite (conosce le loro chiavi segrete), le entrate vengono firmate con una firma ad anello. Tale firma garantisce che il firmatario conoscesse le chiavi segrete di tutti gli elementi di una qualsiasi delle colonne.
Le transazioni riservate non utilizzano più le tradizionali firme ad anello per ma sono state sostituite da MLSAG — una versione adattata per più entrate delle simili firme ad anello a strato singolo, .
Si chiamano multistrato perché firmando più entrate contemporaneamente, ognuna delle quali è mescolata con altre, si firma una matrice e non solo una riga. Come vedremo in seguito, ciò aiuta a risparmiare sul peso della firma.
Esaminiamo come viene formata una firma ad anello, usando come esempio una transazione che spende 2 uscite reali e utilizza per il mescolamento m — 1 casuali dalla blockchain. Indichiamo le chiavi pubbliche delle uscite che spendiamo come
, e le immagini delle chiavi per esse rispettivamente: 
In questo modo otteniamo una matrice di dimensioni 2 x m. Per iniziare, dobbiamo calcolare i cosiddetti challenges per ogni coppia di uscite:
Iniziamo i calcoli dalle uscite, che utilizziamo con le loro chiavi pubbliche:
e numeri casuali
Alla fine otteniamo i valori:
, che utilizziamo per calcolare il challenge
della coppia successiva di uscite (per rendere più semplice capire dove inserire ciascun valore, abbiamo evidenziato questi valori con colori diversi). Tutti i valori seguenti vengono calcolati in modo circolare secondo le formule indicate nella prima illustrazione. L'ultimo challenge calcolato è quello per la coppia di uscite reali.
Come possiamo vedere, in tutte le colonne, tranne quella contenente le uscite reali, vengono utilizzati numeri generati casualmente
. Per π-esima colonna, saranno necessari anche a noi. Convertiamo
in s:
La firma stessa è un insieme di tutti questi valori:
Successivamente, questi dati vengono registrati nella transazione.
Come possiamo vedere, MLSAG contiene solo un challenge c0, il che consente di risparmiare sulla dimensione della firma (che richiede già molto spazio). Successivamente, qualsiasi verificatore, utilizzando i dati
, recupera i valori c1,…, cm e verifica che
. In questo modo il nostro anello si è chiuso e la firma ha superato il controllo.
Per le transazioni RingCT tipo full, viene aggiunta un'altra riga alla matrice con le uscite mischiate, ma di questo parleremo più avanti.
Pedersen Commitments
(si usa più frequentemente il termine inglese — commitments) sono utilizzati affinché una parte possa dimostrare di conoscere un certo segreto (numero), senza effettivamente rivelarlo. Ad esempio, tiri un numero con i dadi, calcoli un commitment e lo trasferisci alla parte verificatrice. In questo modo, al momento della rivelazione del numero segreto, il verificatore calcola autonomamente il commitment, verificando così che non lo hai ingannato.
In Monero, i commitments sono utilizzati per nascondere le somme delle transazioni e viene applicata la variante più comune — Pedersen commitments. A proposito, un fatto curioso: inizialmente, gli sviluppatori proponevano di nascondere le somme con un normale mischiare, aggiungendo uscite su somme casuali, per creare incertezza, ma poi sono passati ai commitments (senza però essere certi che ci fosse un risparmio in termini di dimensioni della transazione, come vedremo più avanti).
In generale, un commitment appare nel seguente modo:
Dove C — il valore del commitment stesso, a — la somma nascosta, H — punto fisso su una curva ellittica (generatore aggiuntivo), e x — una maschera arbitraria, un fattore nascosto, generato casualmente. La maschera qui serve affinché una terza parte non possa semplicemente indovinare il valore di commitment.
Durante la generazione di una nuova uscita, il portafoglio calcola il commitment per essa e, al momento della spesa, utilizza il valore calcolato in fase di generazione, oppure lo ricalcola — a seconda del tipo di transazione.
RingCT simple
Nel caso delle transazioni simple RingCT, per garantire che la transazione crei uscite per un valore pari a quello delle entrate (non producendo denaro dal nulla), è necessario che la somma dei commitments delle prime e delle seconde sia identica, cioè:
Il commitment delle commissioni si calcola in modo leggermente diverso — senza maschera:
, dove a — l'importo della commissione, è pubblicamente disponibile.
Questo approccio consente di dimostrare alla parte esaminante che utilizziamo somme identiche, senza rivelarle.
Per rendere tutto più chiaro, consideriamo un esempio. Supponiamo che la transazione spenda due uscite (cioè diventano entrate) di 10 e 5 XMR e generi tre uscite per un totale di 12 XMR: 3, 4 e 5 XMR. In questo caso, paga una commissione di 3 XMR. Pertanto, la somma dei soldi spesi più la somma generata e la commissione è pari a 15 XMR. Proviamo a calcolare i commitments e vediamo la differenza delle loro somme (ricordiamo la matematica):
Qui vediamo che, affinché l'equazione si bilanci, le somme delle maschere delle entrate e delle uscite devono essere identiche. A tal fine, il portafoglio genera casualmente x1, y1, y2 e y3, mentre rimasto x2 si calcola così:
Utilizzando queste maschere, possiamo dimostrare a qualsiasi esaminatore che non stiamo generando più fondi di quelli che spendiamo, senza rivelare le somme. Originale, vero?
RingCT full
Nelle transazioni full RingCT, il controllo delle somme delle transazioni avviene in modo leggermente più complesso. In queste transazioni, il portafoglio non ricalcola i commitments per le entrate, ma utilizza quelli calcolati al momento della loro generazione. A questo punto, dobbiamo supporre che la differenza delle somme non sarà più zero, ma piuttosto:
Qui z — la differenza delle maschere delle entrate e delle uscite. Se consideriamo zG come una chiave pubblica (che di fatto è), allora z — è una chiave privata. Pertanto, conosciamo le chiavi pubbliche e le corrispondenti chiavi private. Avere queste informazioni ci consente di utilizzarle nella firma circolare MLSAG insieme alle chiavi pubbliche delle uscite mischiate:
Di conseguenza, una firma circolare valida garantirà che conosciamo tutte le chiavi private di una delle colonne, mentre la chiave privata nell'ultima riga può essere conosciuta solo se la transazione non genera fondi superiori a quelli spesi. A proposito, qui c'è la risposta alla domanda «perché la differenza delle somme degli impegni non porta a zero» — se zG = 0, allora riveleremo la colonna con le uscite reali.
Ma come fa il destinatario dei fondi a sapere quanti soldi gli sono stati inviati? Qui tutto è semplice: il mittente della transazione e il destinatario scambiano chiavi tramite il protocollo di Diffie-Hellman, utilizzando la chiave di transazione e la chiave di visione del destinatario, e calcolano un segreto condiviso. Il mittente registra in campi speciali della transazione i dati sulle somme delle uscite, criptati con questa chiave comune.
Proof di intervallo
E cosa succede se utilizziamo un numero negativo come somma negli impegni? Questo potrebbe portare alla generazione di monete aggiuntive! Tale esito è inaccettabile, quindi è necessaria una garanzia che le somme che utilizziamo non siano negative (senza rivelare queste somme, ovviamente, altrimenti tutto il lavoro sarebbe vano). In altre parole, dobbiamo dimostrare che la somma si trova nell'intervallo [0, 2n — 1].
Per fare ciò, ogni somma di uscita viene suddivisa in bit binari e viene calcolato l'impegno per ciascun bit separatamente. È meglio esaminare come ciò avviene con un esempio.
Supponiamo che le somme siano piccole e rientrino in 4 bit (in pratica sono 64 bit), e creiamo un'uscita per un importo di 5 XMR. Calcoliamo gli impegni per ogni bit e l'impegno totale per l'intero importo:
Successivamente, ogni impegno viene mischiato con un surrogato (Ci-2iH) e firmato a coppie con la firma circolare di Borromeo (un'altra firma circolare), proposta da Greg Maxwell nel 2015 (puoi leggere di più su di essa ):
Tutto questo è chiamato proof di intervallo e consente di garantire che negli impegni siano utilizzate somme nell'intervallo [0, 2n — 1].
Cosa succede dopo?
Nell'attuale implementazione, le prove di rango occupano molto spazio: 6176 byte per ogni uscita. Questo porta a transazioni di grandi dimensioni e, di conseguenza, a commissioni più elevate. Per ridurre le dimensioni delle transazioni, gli sviluppatori di Monero introducono al posto delle firme di Borromeo i bulletproofs: un meccanismo di prova di rango senza impegni bit per bit. , possono ridurre le dimensioni delle prove di rango fino al 94%. A proposito, a metà luglio la tecnologia ha superato da parte della società Kudelski Security, che non ha riscontrato difetti significativi né nella tecnologia stessa né nella sua implementazione. La tecnologia è già utilizzata nella rete di test e con il nuovo hard fork potrebbe trasferirsi anche nella rete principale.
Fai le tue domande, proponi argomenti per nuovi articoli sulle tecnologie nel campo delle criptovalute e iscriviti al nostro gruppo su , per rimanere aggiornato sui nostri eventi e pubblicazioni.
Fonte: habr.com
