Whitepaper – Proof-of-Work

Davide

Novembre 10, 2022

Siamo giunti alla quarta puntata di questa serie di articoli dedicata all’analisi del whitepaper di Bitcoin.

Come nelle migliori serie tv, facciamo un breve riassunto di quanto abbiamo visto finora.

Riassunto delle puntate precedenti

Il nostro protagonista, Satoshi Nakamoto, ci ha introdotto alla necessità di avere un sistema di pagamento che consente alla persone di scambiarsi valore tra di loro senza la necessità di un ente centrale di controllo. Il sistema di pagamento, deve essere inoltre irreversibile così da proteggere i venditori dalle frodi e, attraverso l’implementazione di alcuni meccanismi, da proteggere gli acquirenti.

Per ottenere quanto descritto, Satoshi, ha introdotto il Timestamp per provare che le transazioni sono esistite in qualche forma in un dato istante della storia.

Tutte le transazioni avvenute contemporaneamente vengono raccolte tramite un hash e pubblicate su un server USENET che ne certifica l’esistenza nel tempo.

Aggiungiamo ora un tassello.

L’obiettivo finale di Satoshi, come abbiamo capito, è di non essere vincolato a qualche server o autorità centrale. Per questo si rende necessario implementare un server timestamp distribuito su base peer-to-peer: la Proof-of-Work.

Come fare? “semplice”, sfruttando l’idea alla base del sistema Hashcash di Adam Back.

Ma partiamo dall’inizio 🙂

Il problema dello SPAM

Già negli anni 90’ le poste elettroniche dei pochi utilizzatori di internet erano inondate da centinai di mail spazzatura, le cosiddette mail di SPAM.

Piccolo aneddoto, il termine SPAM deriva dal nome di una marca di carne in scatola. Negli anni ‘70 questa carne era riproposta in maniera così martellante da diventare altamente fastidiosa.

Chiusa parentesi e riprendiamo 🙂

Come ben sappiamo, lo spam causa due problemi principali alla nostra posta elettronica:

un intasamento della nostra casella postale, rendono a volte snervante la ricerca delle mail utili ricevute
inaffidabilità della posta elettronica. A causa delle tecnologie anti-spam, spesso, anche le mail che inviamo finiscono nella posta indesiderata del mittente.

Proprio per risolvere questi due problemi prende vita, nel 1997, Hashcash.

Hashcash di Adam Back

Senza perderci in dettagli vediamo come funziona Hashcash e perché è un problema per gli spammer.

Supponiamo di dover ricevere una mail dal nostro amico Pippo:

Da: pippo@pippo.it
A: info@coindipity.com
Oggetto: Test hashcash
Data: 28/10/2022 22:05:00
X-Hashcash: 0:221028:info@coindipity.com:16

Il plugin software aggiungerà alla mail che sta inviando Pippo un’intestazione X-Hashcash formata dai seguenti elementi:

0: la versione di stampa utilizzata
221028: la data di invio della mail 28/10/2022
info@coindipity.com: la mail del destinatario
16: una stringa, che prova che è stato eseguito un certo calcolo e quindi è stato eseguito del lavoro prima di poter inviare la mail.

Il principio di funzionamento sta proprio in quell’ultimo numeretto. Ma come viene calcolato?

Prima dell’invio della mail, il computer di Pippo inizia ad aggiungere alla stringa 0:221028:info@coindipity.com: un numero casuale alla volta eseguendone la funzione di hash SHA-1 finche’, nel nostro esempio, il risultato della funzione di hash non inizia con uno 0.

Proviamoci 🙂

Tentativo 1

0:221028:info@coindipity.com:0

7cdb5d915b486a3f803fb9713a56c70c3f0f1e33

Tentativo 2

0:221028:info@coindipity.com:1

218c5796fd32ac5d0ed568add7ee2a70bdb2919f

Tentativo 3

0:221028:info@coindipity.com:2

1618d340e1dc0de67b23f8dd56e3b936ef5d3516

……

…..

Tentativo 17

0:221028:info@coindipity.com:16

0a6e5050dccefa78338bce92066380e4c609ecb0

YEEEEE. Al sedicesimo tentativo siamo riusciti a trovare un risultato della funzione SHA-1 che soddisfi il requisito di iniziare con uno 0.

Finalmente, Pippo riuscirà ad inviare la propria mail.

Immaginate ora di essere uno spammer che deve inviare 10000 mail ad utenti diversi.

Per ogni mail dovete far eseguire al vostro PC l’algoritmo SHA-1 finche’ il risultato della funzione non inizia almeno con uno 0.

Capite bene, che dopo qualche mail perdete la pazienza 😉

Per lo spammer professionista il lavoro richiesto è molto più complicato del nostro esempio. Infatti, gli si potrebbe chiedere di calcolare un hash con otto zeri iniziali. A quel punto, il costo dello spam raggiungerebbe un livello tale da non portare nessun ritorno economico.

Cosa deve fare il destinatario che riceve la mail?

Alla ricezione della mail l’algortimo Hashcash installato sul nostro PC esegue le seguenti verifiche:

calcola lo SHA-1 dell’intestazione ricevuta e verifica che il risultato inizi con il numero di zeri richiesto, nel nostro esempio basta uno 0 iniziale.
verifica che la data non sia più lontana di due giorni dalla data corrente
verifica che la mail del destinatario sia registrata nei nostri contatti o in qualche mailing list dove siamo iscritti
Verifica che il risultato dell’hash non sia mai stato utilizzato una volta, confrontandolo con un database di hash ricevuti in precedenza

Se tutti questi test son considerati validi allora la mail non è uno spam e possiamo leggerla tranquillamente.

L’integrazione di Nakamoto

Come abbiamo visto, il timestamp di un blocco è il risultato della funzione di hash SHA-256 avente come input l’insieme di transazioni del blocco corrente e il timestamp del blocco precedente.

Il risultato poi veniva pubblicato sul server USENET come prova ai restanti partecipanti della rete.

Per svincolarsi dalla pubblicazione sul server USENET, Satoshi fa sua l’idea di Adam Back utilizzata su Hashcash.

A differenza di Hashcash, Nakamoto, utilizza la funzione SHA-256, rilasciata dalla NSA successivamente alla funzione SHA-1. Se avete bisogno di un ripasso sulla funzione di SHA-256 trovate le informazioni necessarie nel capitolo dedicato alle Transazioni.

Perché il blocco e quindi le transazioni all’interno di esso siano valide, l’hash ottenuto deve soddisfare una condizione: iniziare con il numero di richiesto di 0.

Proprio come fa l’algoritmo di Adam Back per filtrare le mail di spam.

Vi starete chiedendo com’è possibile calcolare dei nuovi hash con gli stessi input d’ingresso.
La risposta è semplice: si aggiunge come parametro d’ingresso il Nonce.

Che cos’è il Nonce?

Il Nonce – Number Only Used Once – è un un numero a 32 bit (cioè da 0 a 4.294.967.296) utilizzato come parametro di ingresso della funzione di SHA-256 per calcolare un timestamp che rispecchi il numero di 0 richiesto dal protocollo.

Vediamolo con un semplice esempio.

lo SHA-256 di Coindipity da come risultato:

289945f74540bc0386ab686441fef93d958603382681dc2fa238e296218b1b44

Il nostro obiettivo è ottenere un hash che inizi con uno 0.

Iniziamo aggiungendo un Nonce

Tentativo 1

Coindipity0

b9df3c35ae0882c75c9d197b0800f1bbda809c5e2c43eee529b8391b19b8daf2

non va bene…incrementiamo di 1 il nonce

Tentativo 2

Coindipity1

21e0d9b0811bfc1aa94b1abd115bd3531ea8f7829fcb0ff8bca55cd1fddeae82

niente….mettiamolo a 2 ora

Tentativo 3

Coindipity2

60856a9b49ba48e498dc8dd17cd3ecc05c77b17b14571738c5839d7e99f17f62

ehmmm….

Tentativo 4

Coindipity3

aecce8bf7894f3065f12fbc49587b55d82cd2c5dc8532f246c3dcfa5ef5f342b

…..

….

Tentativo 31

Coindipity30

0790b2d5bfaf57b10db7b7666698a5b7fa8ce071d9b223004654337ac9cac586

Finalmente, al 31esimo tentativo siamo riusciti a calcolare l’hash che rispetta il vincolo di uno zero iniziale. Quindi il Nonce è uguale a 30.

Calcolo delle probabilità

Il nostro esempio è stato relativamente semplice: dopo 31 tentativi siamo riusciti a calcolare l’hash con il vincolo richiesto.

Ma se volessimo ottenere un hash con 5 zeri iniziali?

La probabilità di trovarlo velocemente diminuirebbe drasticamente.

Basti pensare che, ad esempio, la probabilità di ottenere un hash con 5 zeri iniziali (00000) è di circa 1 su un milione (1 su 16^5, 16 perché l’hash è formato da cifre esadecimali e 5 è il numero di 0 da ottenere).

Attualmente, l’hash del blocco 760032 è 00000000000000000003faffa0adf6b3767420ba37378f051e31ec149ba36eff

in pratica, il protocollo ha richiesto di trovare un hash con ben 19 zeri iniziali per validare le transazioni di quel blocco.

A voi il calcolo della probabilità e del numero di operazioni da eseguire per trovarlo 😉

Ci possono essere manomissioni?

A questa domanda risponde, come sempre, Satoshi.

Semplifichiamo 😉

Una volta trovato l’hash con il vincolo richiesto, questo viene dato in pasto come ingresso alla funzione di hash del blocco successivo, creando, via via, una catena impossibile da spezzare.

Se un furbacchione volesse manomettere anche una sola transazione di un blocco dovrebbe non solo ricalcolare l’hash del blocco alterato ma dovrebbe anche ricalcolarlo per tutti i blocchi aggiunti successivamente. Perché, ormai vi dovrebbe essere chiaro, basta un piccola modifica per cambiare totalmente il risultato della funziona SHA-256.

L’aggiunta del nonce, rinforza ancora di più la sicurezza della rete. Non solo il malintenzionato dovrebbe ricalcolare l’hash ma questo dovrebbe anche rispettare il vincolo del numero di 0 richiesto dalla rete.

Il sistema decisionale per l’aggiunta di un nuovo blocco

Vediamo cos’è affermato in merito sul whitepaper.

La Proof-of-Work può essere vista come una gara, dove i concorrenti sono i partecipanti alla rete peer-to-peer.

Il primo partecipante che riesce a calcolare l’hash con il numero di zero richiesto vince la gara ed ha diritto ad aggiungere il nuovo blocco alla catena.

Come battere la concorrenza?

Il calcolo dell’hash richiede potenza di calcolo e questa potenza di calcolo è data dal lavoro delle CPU. E’ semplice quindi capire, che per vincere la gara un utente deve potenziare il motore della sua macchina e quindi investire per avere più CPU.

Più CPU possiede un concorrente più aumenta la sua probabilità di calcolare l’hash corretto prima degli altri.

Investire nel potenziamento della propria macchina significa anche avere un interesse diretto sul corretto funzionamento dell’intero protocollo Bitcoin. Questo susseguirsi di azioni da parte dei partecipanti permette a Bitcoin di rafforzare la sua sicurezza e la sua onestà.

Ovviamente, nulla viene fatto per nulla, e Satoshi ha pensato anche a questo 😉

Avremo modo di vederlo nei prossimi articoli.

La regola della catena più lunga

Una volta che un partecipante della rete trova la soluzione all’hash, la trasmette a tutti gli altri partecipanti, i quali bloccheranno la loro ricerca dell’hash per verificare la correttezza della soluzione ricevuta. Se corretta, il nuovo blocco verrà aggiunto alla catena e la soluzione verrà utilizzata per calcolare il successivo hash.

Se la maggior parte degli utenti ha investito per competere onestamente l’un l’altro, la catena onesta di blocchi crescerà molto velocemente superando tutte le altre catene. La catena di blocchi più lunga sarà quella considerata valida.

Se un’impostore volesse tentare una manomissione alla catena dovrebbe avere una quantità tale di CPU, e quindi di potenza di calcolo, da risolvere gli hash più velocemente di tutti gli altri, non solo del blocco manomesso ma anche di tutti quelli successivi.

L’impostore capirebbe immediatamente che non ha speranze nel riuscire nel suo attacco perché si troverebbe a rincorrere continuamente la catena più lunga. A qual punto, anche lui, si convertirebbe per partecipare onestamente alla rete.

Quando descritto viene definito Attacco al 51%. Sicuramente ne dedicheremo un articolo di approfondimento.

Aggiustamento della difficoltà di calcolo della proof-of-work

Siamo giunti quasi alla conclusione di questo corposo capitolo sulla Proof-of-Work, manca ancora un piccolo dettaglio.

Come abbiamo detto, la continua competizione tra i partecipanti della rete, porta ad un aumento della potenza di calcolo complessiva. Questo significa che gli hash, che iniziano con un certo numero di zero, cominceranno ad essere trovati sempre più velocemente e, di conseguenza, aumenterà anche il ritmo di aggiunta dei nuovi blocchi.

Satoshi ha previsto un piccolo algoritmo per fare in modo che il numero di blocchi trovati in un’ora rimanga costante. Per ottenere questo risultato, circa ogni due settimane, vengono regolati i numeri di 0 dell’hash in base alla potenza di calcolo disponibile.

Se la potenza di calcolo nelle due settimane aumenta, anche il numero di zero dell’hash aumenta.

Viceversa, se la potenza di calcolo diminuisce nelle due settimane, anche il numero di zero diminuisce.

Conclusioni

Che sudata!!! Probabilmente con questo articolo abbiamo raggiunto la vetta del whitepaper di Satoshi Nakamoto.

Chi si aspettava di trovare la parola mining all’interno dell’articolo, sarà rimasto un po’ deluso.

L’intenzione di Satoshi era di incentivare le persone a partecipare alla rete di Bitcoin e non di creare un vera e propria industria specializzata nella creazione di nuovi blocchi.

Spero di essermela cavata bene e di avervi chiarito qualche dubbio. Per qualsiasi cosa sapete dove e come trovarmi 😉

Al prossimo capitolo 🙂