Continuiamo il nostro ciclo sul funzionamento della blockchain 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 online 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 classiche firme ad anello di Cryptonote e come questa tecnologia si svilupperà in futuro.
Poiché questo protocollo è una delle tecnologie più complesse di Monero, il lettore avrà bisogno di conoscenze di base sul funzionamento di questa blockchain e di una conoscenza superficiale della crittografia su curve ellittiche (per rinfrescare queste conoscenze, è possibile leggere i primi capitoli del nostro precedente articolo su ).
Protocollo RingCT
Una delle possibili minacce per le valute Cryptonote è l'analisi della blockchain, basata sulla conoscenza dell'importo e del tempo della transazione inviata. Questo consente ridurre significativamente l'ambito di ricerca delle uscite interessate dagli attaccanti. Per proteggersi da tale analisi, Monero ha implementato un protocollo di transazioni anonime che nasconde completamente gli importi delle transazioni in rete.
Vale la pena notare che l'idea di nascondere gli importi non è nuova. Uno dei primi a descriverla è stato lo sviluppatore di Bitcoin Core Greg Maxwell nel suo . L'attuale implementazione di RingCT è una sua modifica con la possibilità di utilizzare firme anulari (come potrebbe essere altrimenti), e ha preso il suo nome da qui — Transazioni Confidenziali Anulari.
Inoltre, il protocollo aiuta a risolvere i problemi legati al mescolamento delle uscite di tipo dust — uscite di piccolo importo (solitamente generate come resto dalle transazioni), che creavano più problemi di quanto valessero.
Nel gennaio 2017 si è svolto un hard fork della rete Monero, che permette di utilizzare opzionalmente transazioni riservate. E già a settembre dello stesso anno, a partire dall'hard fork della versione 6, queste transazioni sono diventate le uniche consentite nella rete.
RingCT utilizza diversi meccanismi: firme anonime di gruppo spontane multilivello collegate (Multilayered Linkable Spontaneous Anonymous Group Signature, di seguito MLSAG), schema di impegno (Pedersen Commitments) e range proofs (non esiste una traduzione consolidata di questo termine in italiano).
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, mentre il secondo si verifica nell'opposto. Si differenziano per la validazione degli importi delle transazioni e i dati firmati dalla firma MLSAG (ne parleremo più sotto). Le transazioni di tipo full possono essere generate con qualsiasi numero di entrate, non c'è una differenza fondamentale. Nel libro si afferma che la decisione di limitare le transazioni full a un'unica entrata è stata presa in fretta e potrebbe cambiare in futuro.
Firma MLSAG
Ricordiamo cosa sono gli ingressi di transazione firmati. Ogni transazione spende una certa somma di denaro e genera. La generazione di fondi avviene attraverso la creazione di uscite di transazione (un'analogia diretta sono le banconote), e l'uscita che viene spesa dalla transazione (poiché nella vita reale spendiamo proprio banconote) diventa un ingresso (attenzione, qui è molto facile confondersi).
Un ingresso fa riferimento a più uscite, ma ne spende solo una, creando così una «nuvola di fumo» per complicare l'analisi della storia dei trasferimenti. Se una transazione ha più di un ingresso, questa struttura può essere rappresentata come una matrice, dove le righe sono ingressi e le colonne sono le uscite coinvolte. Per dimostrare alla rete che la transazione sta spendendo le sue uscite (conosce le chiavi segrete), gli ingressi vengono firmati con una firma ad anello. Tale firma garantisce che il firmatario conoscesse le chiavi segrete di tutti gli elementi di una qualsiasi colonna.
Le transazioni riservate non utilizzano più gli approcci classici per Le firme anulari sono state sostituite dagli MLSAG, una versione adattata per più ingressi delle analoghe firme anulari a un solo strato. .
Si chiamano multilayer perché firmano più ingressi contemporaneamente, ognuno dei quali è mescolato con diversi altri, ovvero viene firmata una matrice, anziché una sola riga. Come vedremo più avanti, questo aiuta a ridurre le dimensioni della firma.
Esaminiamo come si forma una firma anulare, usando come esempio una transazione che spende 2 uscita reali e utilizza per il mescolamento m – 1 casuali dalla blockchain. Indichiamo le chiavi pubbliche delle uscite che spendiamo come
, e le key images corrispondenti: 
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 spendiamo, utilizzando le loro chiavi pubbliche:
e numeri casuali
Alla fine otteniamo i valori:
, che usiamo per calcolare il challenge.
per la coppia di uscite successive (per facilitare la comprensione di cosa inseriamo, abbiamo evidenziato questi valori con colori diversi). Tutti i valori successivi vengono calcolati in modo ciclico in base alle formule presentate nella prima illustrazione. L'ultimo a essere calcolato è il challenge 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 πla colonna -g saranno anch'essi necessari. Trasformiamo
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 già richiede molto spazio). Successivamente, chiunque effettui la verifica, 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 di tipo full viene aggiunta un'altra riga alla matrice con le uscite mischiate, ma ne parleremo più avanti.
Impegni di Pedersen
(si usa più spesso il termine inglese — commitments) sono utilizzati per consentire a una parte di dimostrare di conoscere un certo segreto (un numero) senza rivelarlo effettivamente. Ad esempio, lanci una serie di dadi, calcoli il commitment e lo passi alla parte di verifica. In questo modo, al momento della rivelazione del numero segreto, il verificatore calcola autonomamente il commitment, assicurandosi così che non lo hai ingannato.
In Monero, i commitments sono utilizzati per nascondere gli importi delle transazioni e applicano la variante più comune — i Pedersen commitments. A proposito, un fatto curioso: inizialmente gli sviluppatori proponevano di nascondere gli importi tramite miscelazione normale, cioè aggiungendo uscite per somme arbitrarie, per introdurre incertezza, ma poi sono passati ai commitments (anche se non è detto che abbiano risparmiato sulla dimensione della transazione, come vedremo più avanti).
In generale, un commitment appare nel seguente modo:
Dove C — il valore stesso del commitment, a — l'importo nascosto, H — un punto fisso sulla curva ellittica (generatore aggiuntivo), e x — una certa maschera arbitraria, un fattore nascosto che viene generato casualmente. Questa maschera è necessaria affinché una terza parte non possa semplicemente indovinare il valore del commitment.
Quando viene generata una nuova uscita, il portafoglio calcola il commitment per essa, e al momento della spesa prende o il valore calcolato durante la generazione o lo ricalcola nuovamente, a seconda del tipo di transazione.
RingCT semplice
Nel caso di transazioni RingCT semplici, per garantire che la transazione abbia creato uscite di un importo uguale a quello degli ingressi (non producendo denaro dal nulla), è necessario che la somma dei commitment dei primi e dei secondi sia la stessa, ovvero:
Le commissioni di commitment vengono calcolate in modo leggermente diverso — senza maschera:
, dove a — l'importo delle commissioni, che è pubblicamente accessibile.
Questo approccio consente di dimostrare alla parte verificatrice che utilizziamo somme identiche senza rivelarle.
Per rendere tutto più chiaro, consideriamo un esempio. Supponiamo che una transazione utilizzi due uscite (cioè diventano entrate) di 10 e 5 XMR, generando tre uscite per un totale di 12 XMR: 3, 4 e 5 XMR. Inoltre, paga una commissione di 3 XMR. Quindi, la somma dei fondi spesi più la somma generata e la commissione è pari a 15 XMR. Proviamo a calcolare i commitments e osserviamo la differenza delle loro somme (riportiamo alla matematica):
Qui vediamo che affinché l'equazione sia bilanciata — le somme delle maschere delle entrate e delle uscite devono essere uguali. Per questo motivo, il portafoglio genera casualmente x1, y1, y2 e y3, mentre il restante x2 viene calcolato così:
Utilizzando queste maschere, possiamo dimostrare a chiunque verifichi che non stiamo generando più fondi di quanti ne spendiamo, senza rivelare le somme. Originale, vero?
RingCT completo
Nelle transazioni full RingCT, il controllo delle somme di trasferimento è un po' più elaborato. In queste transazioni, il portafoglio non ricalcola i commitments per le entrate, ma utilizza quelli calcolati al momento della loro generazione. Dobbiamo considerare 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 chiave pubblica (e così è de facto), quindi z — è la chiave privata. Così, conosciamo la chiave pubblica e la corrispondente chiave privata. Con queste informazioni, possiamo usarle nella firma ad anello MLSAG insieme alle chiavi pubbliche delle uscite mischiate:
Quindi, una firma ad anello valida garantirà che conosciamo tutte le chiavi private di una delle colonne, mentre la chiave privata nell'ultima riga possiamo conoscerla solo se la transazione non genera fondi maggiori di quelli che spende. A proposito, qui c'è anche la risposta alla domanda "perché la differenza delle somme degli impegni non porta a zero" — se zG = 0, allora sveleremo la colonna con le uscite reali.
E 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 della transazione e la chiave view del destinatario per calcolare un segreto comune. Il mittente registra in campi speciali della transazione i dati sugli importi delle uscite, crittografati con questa chiave comune.
Range proofs
Cosa succede se usiamo un numero negativo come somma nei commitments? Questo potrebbe portare alla generazione di monete aggiuntive! Un tale evento non è accettabile, quindi è necessaria una garanzia che le somme utilizzate non siano negative (senza rivelare queste somme, naturalmente, altrimenti tutto il lavoro sarebbe inutile). In altre parole, dobbiamo dimostrare che la somma si trova nell'intervallo [0, 2n — 1].
Per questo, la somma di ciascun output viene suddivisa in bit binari e si calcola il commitment per ogni bit separatamente. È più chiaro considerarlo con un esempio.
Supponiamo che le somme siano piccole e possano essere contenute in 4 bit (in pratica sono 64 bit), e che stiamo creando un output di 5 XMR. Calcoliamo i commitments per ogni bit e il commitment totale per l'intera somma:
Successivamente, ogni commitment viene mescolato con un surrogato (Ci-2iH) e firmato a coppie con una firma circolare di Borromeo (un'altra firma circolare), proposta da Greg Maxwell nel 2015 (puoi leggere di più su di essa ):
Tutto questo è chiamato range proof e garantisce che nei commitments vengano utilizzate somme all'interno dell'intervallo [0, 2n — 1].
E ora?
Nella sua attuale implementazione, le prove di intervallo occupano molto spazio: 6176 byte per un'unica uscita. Questo porta a transazioni di grandi dimensioni e, di conseguenza, commissioni più elevate. Per ridurre le dimensioni delle transazioni, gli sviluppatori di Monero introducono bulletproofs invece delle firme di Borromeo: un meccanismo di prova di intervallo senza impegni bit a bit. , sono in grado di ridurre la dimensione delle prove di intervallo fino al 94%. A proposito, a metà luglio, la tecnologia ha superato da parte di Kudelski Security, che non ha riscontrato difetti significativi nella tecnologia stessa o nella sua implementazione. La tecnologia è già in uso nella rete di test e, con il nuovo hard fork, potrebbe probabilmente passare anche alla rete principale.
Fai le tue domande, proponi argomenti per nuovi articoli sulle tecnologie nel campo delle criptovalute e unisciti al nostro gruppo su , per rimanere aggiornato sulle nostre novità e pubblicazioni.
Fonte: habr.com
