Zcash e la cerimonia – Riassunto completo

Tempo di lettura:10 minuti

Introduzione

Le prove di conoscenza-zero di Zcash si basano su un insieme di parametri pubblici che consentono agli utenti di costruire e verificare transazioni private. A causa delle limitazioni crittografiche, questi parametri devono essere generati in una fase di impostazione: vengono campionati alcuni numeri casuali (che chiamiamo “rifiuto tossico”) che vengono poi utilizzati per costruire i parametri.

Dopo la fase di configurazione, i rifiuti tossici devono essere distrutti per prevenire la contraffazione di Zcash. (Nota che la privacy dell’utente è ancora protetta anche se la fase di configurazione fallisce o se i rifiuti tossici non vengono distrutti.)

 

Cerimonia di computazione Multi-Party

Al fine di garantire che i rifiuti tossici non vengano prodotti, il nostro team ha progettato un protocollo di computazione multipartito (MPC) che consente a più parti indipendenti di costruire in modo collaborativo i parametri. Questo protocollo ha la proprietà che, al fine di compromettere i parametri finali, tutti i partecipanti dovrebbero essere compromessi o disonesti.

I parametri pubblici di Zcash sono stati generati utilizzando questo protocollo in una cerimonia che si è svolta dal 21 al 23 ottobre. La cerimonia ha coinvolto sei partecipanti, ciascuno nella propria sede, ciascuno con il proprio hardware:

  1. Andrew Mille
  2. Peter Van Valkenburgh
  3. John Dobbertin (pseudonym)
  4. Zooko Wilcox
  5. Derek Hinch
  6. Peter Todd

Durante la cerimonia, Sean Bowe (uno degli ingegneri del software MPC) ha coordinato l’esecuzione della cerimonia.

Inoltre, Morgen Peck (un giornalista che scrive per IEEE Spectrum), Nat Kramer (un videografo) e Daniel Cooper (un assistente di produzione) sono stati invitati alla stazione di Zooko per documentare e osservare il processo.

 

Panoramica sul design della cerimonia

Tutti i partecipanti hanno un ruolo simile: le loro macchine campionano casualmente un “frammento” di rifiuti tossici e usano questo frammento per eseguire calcoli. I partecipanti devono comunicare tra loro durante la cerimonia, ma nessuna delle comunicazioni è considerata sensibile e tutto è disponibile in una trascrizione pubblica.

I partecipanti non comunicano direttamente tra loro. Esiste un server coordinatore che funge da ponte tra i partecipanti ed esegue alcune passi di inizializzazione deterministica e altri calcoli impegnativi. Non è una parte privilegiata o non accessibile della cerimonia; tutti i calcoli eseguiti dal coordinatore possono essere verificati dal pubblico utilizzando la stessa trascrizione pubblica menzionata in precedenza. Il server coordinatore registra i protocolli di comunicazione con la trascrizione pubblica, che viene utilizzata in seguito per verificare l’esecuzione del protocollo stesso.

I partecipanti stessi sono responsabili dell’ottenimento di hardware sicuro specifico per la cerimonia, mantenendo la custodia di quell’hardware fino a quando il loro ruolo è finito e distruggendo il loro frammento di rifiuti tossici spegnendo la macchina. A loro discrezione, i partecipanti possono distruggere fisicamente o performare un’analisi forense sull’hardware in seguito.

 

Hardware utilizzato in cerimonia

Al fine di ridurre l’area superficiale di attacco, ogni partecipante ha isolato il proprio frammento di rifiuti tossici dalla rete disponendo di due macchine che hanno un “vuoto d’aria” l’una con l’altra: un nodo di rete che comunica con il server coordinatore e un nodo di calcolo che ha il frammento di rifiuto tossico in memoria. Questo crea un vuoto d’aria che abbiamo scelto di collegare usando solamente un metodo DVD. I DVD servono inoltre come documentazione verificabile della comunicazione del protocollo.

I partecipanti sono stati incoraggiati a ottenere il loro nodo di calcolo da un negozio di computer a caso. Sono stati inoltre istruiti a rimuovere gli adattatori di rete wireless (wifi, bluetooth) e le unità a disco rigido dalla macchina prima di accenderli.

L’hardware esegue software open source che abbiamo sviluppato. In particolare, abbiamo creato gli ISO di avvio (Boot ISOs) con cui i partecipanti avviano le proprio macchine.

 

Preparazione per la cerimonia

PROVE GENERALI

In preparazione alla cerimonia, durante il mese precedente si sono svolte più prove generali.

Prima prova generale: questo ha coinvolto Andrew Miller, Peter Van Valkenburgh e Sean Bowe. L’unità DVD utilizzata dal nodo di calcolo di Andrew aveva un’anomalia irrecuperabile. Il software è stato modificato per rendere possibile il ripristino da un guasto all’unità.

Seconda prova generale: questo ha coinvolto anche Andrew Miller, Peter Van Valkenburgh e Sean Bowe. (Nat Kramer ha anche documentato il processo alla postazione di Sean Bowe.) C’era un problema di rete sul nodo di rete di Andrew. Sean Bowe è stato in grado di recuperare la situazione facendo collegare manualmente il contenuto di un DVD e fornendolo al server coordinatore. Il nodo di rete di Andrew ha ristabilito una connessione con il server coordinatore e la cerimonia ha continuato verso il suo completamento. Il software è stato modificato per recuperare meglio dalle interruzioni della rete.

Terza prova generale: questo ha coinvolto Zooko Wilcox, Derek Hinch e Andrew Miller. (Morgen Peck ha anche osservato il processo tramite la chat video.) Il nodo di calcolo di Zooko non è stato in grado di disinstallare correttamente il disco di avvio a causa di una Race Condition durante l’avvio. Il software è stato modificato per il nodo di calcolo di Zooko per rendere meno probabile questa eventualita’. La cerimonia è continuata, e quasi completata, ma a causa di una rigida politica di controllo degli accessi, non è stato possibile recuperare da un guasto all’unità che si è verificato nell’ultima fase, anche sul nodo di calcolo di Zooko. Il software è stato modificato in modo che i partecipanti potessero intervenire manualmente se le politiche di controllo degli accessi interrompessero la cerimonia.

 

Cambiamenti finali e fasi preparatorie (21 ottobre 2016)

Ai partecipanti è stata fornita una serie di istruzioni che li hanno indirizzati all’acquisto di hardware, all’avvio del software su questo hardware e alla diagnostica integrata che ha testato l’unità DVD e assicurato che la cerimonia potesse iniziare in sicurezza.

Dopo la divulgazione di una vulnerabilità in escalation dei privilegi di Linux (Dirty COW, CVE-2016-5195) il software del nodo di calcolo e di rete è stato aggiornato con il kernel Linux rilasciato di recente 4.4.26 e gli ISO di avvio finali sono stati forniti ai partecipanti.

Il codice utilizzato per la cerimonia è stato contrassegnato come finalmpc2.

Le ISO di avvio fornite ai partecipanti:

  • Nodo di rete ISO (SHA256:375550be4c64ebc68a9306421bb71ad3556bc73f156a231503084f923900f4cb)
  • Nodo di calcolo ISO (SHA256:5f43aa1244a01b3cf9da4abeadde9e34b954a873565fc56b58c10780f3ce0e4c)

Queste ISO possono essere riprodotte in modo riproducibile utilizzando uno script che abbiamo fornito. I timestamp saranno diversi, ma il contenuto dei binari non dovrebbe. Uno strumento come Diffoscope può essere usato per confrontarli.

Nel software originale coordinatore, il primo partecipante a connettersi è anche il primo ad agire ed il primo a completare il proprio ruolo nella cerimonia. La pianificazione dei conflitti significava che alcuni partecipanti avrebbero dovuto terminare prima il 23 ottobre. Il software del coordinatore è stato modificato in modo che l’ordine dei partecipanti potesse essere modificato prima dell’inizio della cerimonia, nel caso in cui i partecipanti si collegassero nell’ordine sbagliato. (Dopo l’inizio del protocollo, l’ordine non può essere modificato).

 

Cerimonia(22-23 ottobre 2016)

La mattina del 22 ottobre, Sean Bowe ha inizializzato il server coordinatore. Il server era in questo caso un EC2 a 128 core. Ai partecipanti è stato richiesto di iniziare i loro ruoli: il nodo di rete si collegava al server coordinatore e chiedeva all’utente di inserire un impegno che i nodi di calcolo avrebbero prodotto, vincolando la loro partecipazione alla trascrizione.

A causa di un malinteso, John Dobbertin ha reinizializzato il proprio nodo di rete, fornendo l’impegno al coordinatore. Questo non è incoraggiato perché il software coordinatore utilizza ID peer generati casualmente per distinguere gli utenti. Ciò è stato corretto manualmente prima dell’inizio del protocollo.

Zooko Wilcox non disponeva di una connessione Ethernet presso la sua ubicazione e pertanto richiedeva la comunicazione wireless con il server coordinatore. Tuttavia, l’immagine di avvio del nodo di rete non conteneva alcuna infrastruttura wireless, quindi a Zooko è stato dato il software del nodo di rete da compilare ed eseguire sul suo laptop personale. (Questo non disturba il nostro protocollo anti-minacce, perché il nodo di rete è già considerato compromesso semplicemente collegandosi a Internet.L’immagine di avvio del nodo di rete viene data solo ai partecipanti per semplificare il processo e ridurre il rischio di guasti.)

L’ordine finale dei partecipanti alla cerimonia era:

  1. Andrew Miller
  2. Peter Van Valkenburgh
  3. John Dobbertin (pseudonym)
  4. Zooko Wilcox
  5. Derek Hinch
  6. Peter Todd

 

Fase di impegno

Il nodo di calcolo di ciascun partecipante genererà casualmente il proprio frammento di rifiuti tossici. All’utente viene chiesto di fornire entropia aggiuntiva per aumentare il generatore di numeri casuali di Linux. Dopo che il frammento di rifiuti tossici è stato generato, viene costruito un tipo speciale di “chiave pubblica” che viene utilizzato per verificare la valutazione del protocollo e vincolare il partecipante alla cerimonia.

Questa “chiave pubblica” non viene immediatamente rivelata. Tutti i partecipanti trascrivono manualmente l’hash della chiave pubblica (il “commit”) dal nodo di calcolo al nodo di rete. Il server coordinatore inserirà tutti gli impegni nella trascrizione pubblica.

Fase 1
Durante queste fasi, ha luogo un “protocollo round robin”: il coordinatore (deterministicamente) inizializza la fase iniziale, e ciascun partecipante esegue una trasformazione a questo stadio che viene passato al prossimo partecipante.

La Fase 1 (anche a volte indicata come “poteri di tau”) vedrà ogni partecipante ricevere un “disco A” sul proprio nodo di rete. Il nodo di rete masterizza questo disco A e lo trasferisce al nodo di calcolo. Il nodo di calcolo legge questo disco e, prima di deserializzare ed elaborare il suo contenuto, visualizza un hash del disco che viene richiesto al partecipante di registrare.

Il nodo di calcolo procede quindi a eseguire una trasformazione impegnativa dello stato che richiede più di mezz’ora. In seguito, il nodo di calcolo stamperà un hash del disco che sta per masterizzare (“disco B”), al quale viene anche chiesto di registrare il partecipante. Il disco masterizzato viene trasferito al nodo di rete, che invia i contenuti al coordinatore.

In totale, ci vuole circa un’ora per ogni partecipante a svolgere il proprio ruolo in questa fase. Solo durante questa fase, ogni partecipante invia la sua “chiave pubblica” e un NIZK utilizzato per una successiva convalida.
FFT
Dopo la fase 1, il coordinatore prende il risultato della fase 1 ed esegue un calcolo impegnativo che richiede più di un’ora per essere completato. Questo calcolo è deterministico. Il risultato è utilizzato per inizializzare la fase 2.
Fase 2
La seconda fase è iniziata la sera del 22 ottobre. La fase 2 si svolge in modo simile allo stadio 1, con la differenza che il calcolo richiede molto più tempo. Ogni partecipante ha ricevuto un disco “C” e ha prodotto un disco “D” in modo simile a prima. In totale, ci vogliono circa due ore per ogni partecipante a completare il proprio ruolo nella seconda fase.
Fase 3
La fase 3 è iniziata la mattina del 23 ottobre. Questa fase si comporta in modo simile alle fasi precedenti, tranne che il calcolo è poco impegnativo. Ogni partecipante riceve un disco “E” e produce un disco “F”. In totale, ogni partecipante impiega circa 40 minuti per completare il proprio ruolo in questa fase.

Dopo che il partecipante ha completato la sua parte nella fase 3, il loro ruolo nel protocollo è finito. Sono incaricati di disattivare il loro nodo di calcolo a questo punto, per distruggere il loro frammento di rifiuti tossici. Sono incaricati di mantenere i loro DVD al sicuro per l’archiviazione e l’analisi.

 

Completamento della cerimonia

La cerimonia è stata completata la sera del 23 ottobre, circa 27 ore dopo l’inizio del protocollo. Dopo la cerimonia completata, il verificatore è stato eseguito sulla trascrizione, producendo i parametri pubblici Zcash. Quanto segue è l’output del verificatore di trascrizione.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Number of players: 6
Player 1 commitment: 2iQQBkf7k4K9aigJm4uHHufaSB8rXLLaRTMmTerK7dx6RCqNc9
Player 2 commitment: 6yV3Ji7zuVWVCQEfkhQ6Vfv51t5VfQHQVaLDGH6zkeunKmohr
Player 3 commitment: 6mGvvMFMKJNwKFmHXUwcCQMk7iu92bSqhtRabX3nkdnadEKte
Player 4 commitment: VGyYjzYc39em9TithdWFySSUwATMgcXcLtQ7ias7i4SkNdS4G
Player 5 commitment: 2YrFsjMadFukhdkQpn8oFgET2EQd9WnDW3AzYqNc3kELU45p7t
Player 6 commitment: 2B2HXuZAKayqgJpxojuUU9RN78pTv2gLvEDmEbWRBWEJ6Z1LS
Player 1 hash of disk A: 2oX6hBNiQxiZYZgDbSkgk3mhBACXmoGCfdhfZrSquNztZuZaqt
Player 1 hash of disk B: 2T2ceUDomnrCVCtJw2SwtYAeHCfnAhM9HBdzVkq6BdZ59nST5m
Player 2 hash of disk A: 2axdkGL6QzngjvY9jRBX5AqhSokukji8eQuYUfJwhp7sxcXvPr
Player 2 hash of disk B: 2RymyNbAWaBVDuzW4m1iKA72MsmZFnwMhNvqxxXDwugLTa62wc
Player 3 hash of disk A: YAQs9PiruKxfTwMTdTUHkYgt9QRvjpkF95cJRbNP8WLqPqjLW
Player 3 hash of disk B: 2omA7bsepmmxeygQzNBbodhdXTyhuK1i2KCRH9esB3azunwZPn
Player 4 hash of disk A: EDEtkk1PUhu4BQbTzx5yPSSpyqB6kV9g39p6sNt1ERGRG3APQ
Player 4 hash of disk B: 2fvnbP22XWHVD1DstGQ5FsHNaBLiZQg4MBVKmWf7sWCYg5A9L7
Player 5 hash of disk A: 2oQgZxPLAL2f8xkvm71RqwKK6dCFQSrazESXci32M2LZeG7nxe
Player 5 hash of disk B: UBjr6UU8oJ4ZzpsTU3vRHmzZmuN7TjX3eLsmdRhw4dW6dEbvH
Player 6 hash of disk A: rnMAJE2bxMbCT6yRvufD2ww17kmP9qaKnipxrvZTWXe27d6GW
Player 6 hash of disk B: 27Em5cp6QSGVsJsAcvZLW7CoMkKv5Ybi3LAGPPeGwqCF7Diex
Player 1 hash of disk C: 29PLu7dtT9BjJhtoAzxpSxvrp4tE15xjJufL1ANHGwkwieyxMo
Player 1 hash of disk D: 2YVAELKtHdufKRPTzT5ZpHFgxrcro6JmBKkYz4GEQqcXbQdViM
Player 2 hash of disk C: 2qSQhJvQLjmXfQWHKMCR5EukSWU9BQ3KwdPSqkPUCSRzwmxowM
Player 2 hash of disk D: 2uAxySzeptYhEowKuBRGituPnc1U4BU1GMuL4Hfbyvtgq7x4Qn
Player 3 hash of disk C: 2DZ3pnkZcTMfAa28KfJpD5fQbnkQZZG5mFnFqvHHUDXJquSJAX
Player 3 hash of disk D: 2tfcauKUDBirJFSo8jbyEenLfHULThsQjVdN8FY3hJGn3dC2JP
Player 4 hash of disk C: 2gH6XJ8BeA5yXZL95ThSp9ucicwAoevaDK6xNBck9QUxXF1gEE
Player 4 hash of disk D: VFXKdDoYrA58evyJUrvkocGCHVvYF2h8HVLmuEtFkDfZY6EHk
Player 5 hash of disk C: 2RvKUp94tXE5b1qhyLpGPTXeWpS7FdNDvCG5MJPmZiccNuRYcw
Player 5 hash of disk D: ApPFWMqGBMemE3sTAuMRnwbmGonsPoXYC4r45HBMdmiRWLXqH
Player 6 hash of disk C: 2wGGYBXaeQdbLHvViArnLkGRERhztVk5qZmreSKwxEcFjMBNMC
Player 6 hash of disk D: 2g3rMWwyCL5wgKYHiVHR6EdnBc9Q5dPc1RW6tWwvwyJnx6AKq9
Player 1 hash of disk E: 2Zbrd1XhYKvZqeNcGQPVrusx1rRjxaQjFfzWcn64wCfTnEGTMg
Player 1 hash of disk F: 27ZzVxLTxXpjeTo86sdQ9kKU83UfNHLyGPuQ4CCV9ZRJ4g84jC
Player 2 hash of disk E: YWKCeTeYiKUNnd4aJBYcd8ZwBxscibmtDa4pxbz52fpYX2H9S
Player 2 hash of disk F: 2o1wWJHYzCirDmijHmnGFQ4pSfoYTkEKdPinag22eYonKf8EGC
Player 3 hash of disk E: 2jquuLB8omrtWV1GnXvghRN1A3MWMouyBSwEKD5fCMwk5SvktP
Player 3 hash of disk F: 2jrEGwnSyX9oX8UUGYhpEiPaLmGmrbhfFtcciXt3o5N7nPh63A
Player 4 hash of disk E: AY1Vm8dDSxDdpNhac8Mr7GkS18vomvXaoreg1mVcXyApmgbu8
Player 4 hash of disk F: 2RVi4vpjXtzD6gPLsFDSVrtX545HbVnNBhjAJVUTXpG22oLDD5
Player 5 hash of disk E: CFEWpN9STr4iVM8NLGcSUyoaEDr94FEp7VWR9HhQQYhuwUu7f
Player 5 hash of disk F: 2vohW4tyybTEZyf3ZarX5R1CgsUehQfwASExZQ86EWNd8ByC6a
Player 6 hash of disk E: chZdF1yRVDTsaD14KdaFv6N7e8ZPkMnxr9CpXkzq8JzonhLPx
Player 6 hash of disk F: 2HjRqGyKjPxDSbhP8KgyYtKpWCwrGt3v4ZEUZHsZpJHbJ2V9QL

(Gli hash sono codificati in base58check per semplificare la trascrizione manuale per i partecipanti durante la cerimonia).
I parametri pubblici di Zcash consistono in due “chiavi”:

  • Proving key (SHA256: 8bc20a7f013b2b58970cddd2e7ea028975c88ae7ceb9259a5344a16bc2c0eef7)
  • Verifying key (SHA256: 4bd498dae0aacfd8e98dc306338d017d9c08dd0918ead18172bd0aec2fc5df82)The full output of the coordinator log can be found here.

 

Verifica della cerimonia

Il pubblico è invitato ad aumentare la fiducia nella cerimonia in vari modi:

  1. Il protocollo utilizzato durante la cerimonia è stato progettato specificamente per Zcash. Il design è specificato insieme a una prova crittografica nel whitepaper MPC. Dovrebbe essere esaminato dal pubblico per gli errori.
  2. Il protocollo utilizzato durante la cerimonia è stato implementato da Sean Bowe e Ariel Gabizon. È disponibile open source. Dovrebbe essere esaminato per i bug che potrebbero aver influito sulla cerimonia.
  3. Il software utilizzato dai partecipanti sulle loro macchine è stato generato utilizzando uno script che il pubblico può utilizzare anche per riprodurre gli ISO. Le persone possono usare strumenti come il diffoscope per analizzare le differenze.
  4. La trascrizione pubblica (SHA256: 7da0c07a4bec04fbe4ae99ebd62d4ce7e1710b1f7a1f317345b0a48feec984d3) viene utilizzata per verificare la valutazione del protocollo e produrre i parametri pubblici. Dovrebbe essere verificato utilizzando il nostro strumento di verifica, che produrrà gli stessi hash di dischi, impegni e parametri pubblici utilizzati in Zcash.
  5. I partecipanti al protocollo hanno rivelato un impegno che li vincola alla cerimonia e gli hash dei file masterizzati sui loro dischi. Questi dovrebbero essere controllati rispetto all’output dello strumento di verifica.
  6. Il sistema di vincoli R1CS utilizzato dal protocollo deve essere confrontato con quello che viene effettivamente utilizzato in Zcash.

 


Traduzione integrale del testo presente sul sito ufficiale di Zcash: https://z.cash/technology/paramgen.html#full-summary

NdT: Non sono un traduttore di professione per cui perdonate eventuali errori sopratutto in termini troppo tecnici. Grazie per la lettura

Navigazione multiarticolo<< Zcash e la cerimonia – IntroduzioneZcash e la cerimonia – Resoconto dettagliato di Peter Todd >>

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

Non perdere i nuovi articoli e le opportunità sulle criptovalute. Iscriviti alla newsletter!
Iscrizione
WP Twitter Auto Publish Powered By : XYZScripts.com