[INFO] Anatomia di una SHIELDED TRANSACTION

jason
Moderatore
Moderatore
Messaggi: 9

27/05/2017, 19:09  

Come funzionano le transazioni tra gli indirizzi schermati
Nell'articolo “anatomia di una transazione di Zcash “abbiamo fornito una panoramica generale sulle transazioni di Zcash. Lo scopo di questo post è invece quello di fornire una spiegazione semplificata riguardo al funzionamento delle operazioni di conservazioni della privacy di Zcash grazie alle prove di Zero-knowledge.
Utilizzando i termini proposti nel precedente articolo, ci concentreremo esclusivamente su transazioni tra indirizzi schermati (comunemente denominati z-addrs).

Per comprendere l'aspetto riguardante la conservazione della privacy, mettiamo da parte tutto ciò che prevede il consenso utilizzando Proof of Work e la blockchain, e concentriamoci su un particolare nodo che ha ottenuto l'elenco corretto delle uscite di transazioni non utilizzate.

Ricordiamo innanzitutto come questa lista esamina la blockchain Bitcoin.
Ogni uscita di transazione non utilizzata (UTXO) può essere considerata come una nota non spesa descritta dall'indirizzo / chiave pubblica del suo proprietario e dalla quantità di BTC che contiene. Per semplicità di presentazione, supponiamo che ciascuna nota contenga esattamente 1 BTC e che ci sia al massimo una nota per indirizzo. Perciò, in un dato momento, il database di un nodo è costituito da un elenco di note non spese in cui ogni nota può essere descritta semplicemente dall'indirizzo del proprietario.
Ad esempio, il database può sembrare così:

Nota1 = (PK1) ,
Nota2 = (PK2) ,
Nota3 = (PK3)


Supponiamo che PK1 sia l'indirizzo di Alice, che desidera inviare la sua nota di 1 BTC all'indirizzo di Bob PK4 . Lei invierà un messaggio che sostanzialmente dice "Spostare 1 BTC da PK1 a PK4 " a tutti i nodi. Alice inoltre firmerà questo messaggio con la chiave segreta sk1 corrispondente a PK1 e questo convincerà il nodo che ha effettivamente il diritto di spostare denaro da PK1.
A questo punto il nodo controllerà la firma, verificherà che esista una nota 1 BTC con indirizzo PK1 e aggiornerà la propria base di dati di conseguenza:

Nota4 = (PK4) ,
Nota2 = (PK2) ,
Nota3 = (PK3)


Ora, supponiamo che ogni nota contenga anche un 'numero di serie' casuale r. Presto vedremo che questo è utile per ottenere la privacy.
Quindi, il database appare in questo modo:

Nota1 = ( PK1 , r 1 ),
Nota 2 = ( PK 2, r2) ,
Nota 3 = ( PK 3 , r3)


Facendo un passo indietro, un primo passo naturale verso la privacy sarebbe quello di avere il nodo "crittografato", o semplicemente un hash, delle note, piuttosto che le note stesse.

H1 = HASH ( Nota 1 ),
H2 =HASH (Nota2) ,
H3 =HASH (Nota3)


Come passo successivo per preservare la privacy, il nodo continuerà a memorizzare l’ hash di una nota anche dopo che è stata spesa.
Così, non sarà più un database di note non spese, ma piuttosto un database di tutte le note che esistevano.

Ora la questione principale è:
Come distinguere, senza distruggere la privacy, le note che sono state usate dalle note che sono state spese?

Questo è il punto in cui entra in gioco il nullifier. Si tratta di un elenco di hash di tutti i numeri seriali di note che sono state spese. Ogni nodo memorizza la lista di nullifier, oltre all'insieme di hash di note.
Ad esempio, dopo che Nota 2 è stata spesa, il database del nodo potrebbe essere simile a questo:


HASHED NOTES | NULLIFIER SET
H1= HASH (Nota1) | nf1= HASH (r2)
H2 = HASH (Nota2) |
H3 = HASH (Nota 3) |

Ma ATTENZIONE, abbiamo controllato che Nota1 non sia stata spesa prima, ma non abbiamo controllato se appartenesse ad Alice.
In realtà, non abbiamo controllato che fosse una nota "reale" a tutti gli effetti, reale nel senso che il suo hash sia nella tabella dei nodi degli hash delle note.

Un modo semplice per Alice, per risolvere questo problema sarebbe semplicemente quello di pubblicare Nota1 , piuttosto che il suo hash, ma ovviamente, questo comprometterebbe la privacy che stiamo cercando di realizzare.

Qui è dove le prove Zero-Knowledge vengono in nostro salvataggio:

Oltre ai passaggi descritti precedentemente, Alice pubblicherà una stringa di prova π convincendo i nodi che chiunque abbia pubblicato questa transazione conosca i valori PK1 , Sk1, e r1, tale per cui:

  • L'hash della nota Nota 1 =( PK 1 ,r1), esiste nella lista degli hash delle note
  • Sk1 è la chiave privata corrispondente a PK1 (e quindi chiunque ne è a conoscenza è il legittimo proprietario di Nota1)
  • L’ hash di r1 e nf2 (e quindi, se nf2 - che ora sappiamo essere il nullifier di Nota1 - non si trova attualmente nel set nullifier, Nota1 ancora non è stato speso).

Le proprietà delle prove Zero-Knowledge garantiscono che nessuna informazione PK 1 ,Sk 1 , o r 1 siano rivelati da π

Questo aneddoto dovrebbe darvi una prima visione di una transazione shielded:
Immaginate di essere nella vostra camera da letto, non ci sono finestre e altri punti di accesso tranne la porta blindata che è protetta da un codice di apertura, la mattina al vostro risveglio trovate un altra persona all'interno.
Ecco, voi potreste trarre con certezza la conclusione, senza uno scambio ulteriore di informazione, che questa persona è a conoscenza del codice di ingresso.


N.B.
  • Gli hash delle note devono essere memorizzati non solo sotto forma di un un elenco, ma anche in un albero Merkle. Questo renderà più efficienti le prove Zero-Knowledge. Inoltre, dobbiamo memorizzare un impegno computazionale nascosto e vincolante della nota, piuttosto che solo il suo hash.
  • Il nullifier deve essere definito in un modo leggermente più complesso per garantire la riservatezza futura del ricevitore in relazione al mittente
  • Non siamo andati nei dettagli su come eliminare la necessità di un canale privato tra mittente e destinatario.

  •   Informazione
  • Chi c’è in linea

    Visitano il forum: Nessuno e 1 ospite