Cosa ‘ e come funziona il MINING

Mining

Se avessimo avuto accesso ad un servizio centralizzato di fiducia, ciò sarebbe banale da implementare; esso potrebbe essere codificato esattamente come descritto. Tuttavia, con i Bitcoin abbiamo provato a costruire un sistema monetario, combinando il sistema di transizione di stato con un sistema di consenso al fine di assicurare che ognuno sia d’accordo sull’ordine delle transazioni. Il processo di consenso decentralizzato del Bitcoin richiede l’esistenza dei nodi nel network, che continuamente tentano di produrre pacchetti di transazioni chiamati “blocchi”. Il network è destinato a produrre all’incirca un blocco ogni dieci minuti, con ogni blocco che contiene una marca temporale, un numero, un riferimento a (ad esempio l’hash del) precedente blocco e una lista di tutte le transazioni che sono avvenute dal precedente blocco. Con il passare del tempo, questo crea una persistente, sempre crescente, “blockchain” che si aggiorna costantemente per rappresentare l’ultimo stato del libro mastro del Bitcoin.

L’algoritmo per controllare la validità di un blocco, espresso in questo paradigma, è il seguente:

1. Controllo se il blocco precedente esiste ed è valido.
2. Controllo se la marca temporale del blocco è più grande del blocco precedente^[2] ed è inferiore di 2 ore nel futuro.
3. Controllo se il proof of work sul blocco è valido.
4. Sia S[0] lo stato alla fine del blocco precedente.
5. Si supponga TX la lista della transazione del blocco con n transazioni. Per tutti i in0...n-1, sia impostato S[i+1] = APPLY(S[i],TX[i]) Se da qualsiasi applicazione risulti un errore, esce e ritorna falso.
6. Ritorna vero, e registra S[n] come uno stato alla fine del blocco.

In definitiva, ogni transazione del blocco deve fornire una transazione di stato che sia valida. Si noti che ogni stato non è codificato, in nessun modo, nel blocco; esso è puramente una astrazione da ricordare per la validazione del nodo e può solo essere (in modo sicuro) computata, per qualsiasi nodo, iniziando dallo stato di genesi e applicata sequenzialmente ad ogni transazione in ogni nodo. Si noti che è importante l’ordine nel quale ogni miner include le transazioni nel blocco; se ci sono due transazioni A e B nel blocco tale che B impiega una UTXO creata da A, poi il blocco sarà validato se A viene prima di B ma non viceversa.

La parte interessante dell’algoritmo di validazione del blocco è il concetto di “proof of work”: la premessa è che l’hash SHA256 di ogni blocco, costituito come un numero di 256-bit, deve essere inferiore di un target regolato dinamicamente, che è al tempo di questo scritto approssimativamente 2¹⁹². Lo scopo di ciò è di rendere computazionalmente “difficile” la creazione di un blocco, prevenendo con ciò agli attacchi sibilla dal ricreare l’intera blockchain a loro favore. Poichè SHA256 è progettato per essere una funzione completamente imprevedibile e pseudo-randomica, l’unico modo di creare un blocco valido è semplicemente un test, con l’incremento ripetuto del numero controllando se il nuovo hash corrisponde. Al target corrente di 2¹⁹², questo significa un media di 2⁶⁴ tentativi; in generale, il target è ricalibrato dal network ogni 2016 blocchi in modo che, in media, un nuovo blocco è prodotto, ogni dieci minuti, da qualche nodo nel network. Nella prospettiva di compensare i miners per questo lavoro computazionale, ogni dieci minuti il miner è autorizzato ad includere una transazione donando a se stesso 25 BTC da nulla. In aggiunta, se qualche transazione ha un valore totale denominale più alto nei suoi inputs che ne suoi outputs, la differenza va al miner come “commissione di transazione”. Incidentalmente, questo è pure l’unico meccanismo attraverso cui avviene l’emissione dei BTC; in assoluto lo stato di genesi non contiene alcuna moneta.

Nella prospettiva di una migliore comprensione dello scopo del mining, esaminiamo il caso in cui avvenga un attacco criminoso. Visto che la crittografia implicita nel Bitcoin è nota per essere sicura, l’attaccante colpirà l’unica parte del sistema del Bitcoin che non è protetta direttamente dalla crittografia: l’ordine delle transazioni. La strategia dell’attaccante è semplice:

1. Invio 100 BTC ad un commerciante in cambio di qualche prodotto (preferibilmente un bene digitale consegnabile rapidamente)
2. Attesa per la consegna del prodotto
3. Produzione di un’altra transazione che invia 100 BTC a se stesso
4. Tentativo di convincere il network che la sua transazione a se stesso era quella che è avvenuta per prima.

Una volta avvenuto lo step (1), dopo qualche minuto qualche miner includerà la transazione nel blocco, ad esempio il blocco numero 270000. Dopo circa un’ora, cinque o più blocchi saranno aggiunti alla chain dopo quel blocco, con ognuno di questi blocchi che indirettamente indicano la transazione e quindi la “confermano”. A questo punto, il commerciante accetterà il pagamento come finalizzato e consegnerà il prodotto; considerato che stiamo assumendo che questo sia un bene digitale, consegnato in un istante. Adesso, l’attaccante crea un’altra transazione inviando i 100 BTC a se stesso. Se l’attaccante semplicemente la rilascia, questa non sarà processato; i miners proveranno ad eseguire APPLY(S,TX) e prendere nota che TX consuma un UTXO che non è più nello stato. Invece, in questo modo, l’attaccante crea una “fork” della blockchain, iniziando a minare un’altra versione del blocco 270000 indirizzando il blocco 269999 come una antecedente ma con una nuova transazione che prende il posto di quella vecchia. Poiché i dati del blocco sono differenti, ciò richiede il rifacimento della “proof-of-work”. Inoltre, la nuova versione del blocco 270000 dell’attaccante ha un hash differente, così i blocchi originali da 270001 a 270005 non “conducono” a quello; quindi, la chain originale e quella nuova dell’attaccante saranno completamente separate. La regola è che, nel caso di fork, la blockchain più lunga è considerata essere quella vera e così i legittimi minatori lavoreranno sulla chain del 270005, mentre l’attaccante sta lavorando da solo sulla chain del 270000. Affinché l’attaccante crei la blockchain più lunga, egli dovrebbe avere più potenza computazionale che il resto del network per ottenere (da quel momento, “51% attacco”).

Link: https://github.com

Resta aggiornato con la Newsletter Settimanale

Scrivi la tua Email

PS: Ricordati di cliccare nella mail di conferma che riceverai e in ogni momento potrai cancellare la tua sottoscrizione.

Andrea Belvedere

Independent researcher and consultant, Tech Writer at Blockchain Technology. From Italy