Questo articolo, diviso in due parti, affronta da un punto di vista prettamente tecnico il funzionamento di uno degli aspetti meno compresi di Bitcoin, ovvero il processo di mining e la creazione del “consenso”. A livello bibliografico è d’obbligo citare il testo “Mastering Bitcoin” di Andreas Antonopoulos, del quale questo testo è ripresa ragionata. Chi fosse interessato ad approfondire questi temi, con o senza integrazione delle dinamiche legate al codice, può trovare supporto nei corsi formativi e nella attività consulenziali erogate da Bcademy.

Mining and Consensus

Mining, letteralmente: minare. L’attività di mining:

• Genera nuova moneta (garantendo l’incentivo);

• Valida le transazioni (è la base sulla quale si crea il consenso).

Questa attività permette l’esistenza di una moneta digitale decentralizzata, validando appunto le transazioni, che vengono inserite in blocchi nella blockchain, e premiando l’attività con fee e nuovi coin, poiché l’attività, consistendo nella soluzione di problemi matematici, richiede l’utilizzo di risorse reali. La soluzione, chiamata Proof-of-Work (prova di lavoro), è di fatto una prova di un lavoro concreto svolto (la risoluzione del PoW algorithm), e la competizione per trovare per primo la soluzione (ed acquisire gli incentivi) è la base del modello di sicurezza di Bitcoin.

Bitcoin Economics

I bitcoin vengono "coniati" durante la creazione di ciascun blocco (in media 10 min) a un tasso fisso, in diminuzione. Ogni 210.000 blocchi (circa quattro anni) il tasso di emissione della valuta, inizialmente 50 BTC diminuisce del 50% (halving).

A novembre 2012, il nuovo tasso di emissione di bitcoin è stato ridotto a 25 BTC per blocco, nel giugno 2016 a 12,5 BTC per blocco, e sarà dimezzato ulteriormente a 6,25 BTC per blocco arrivati al blocco 630,000 (circa giugno 2020).

L’emissione di nuove monete diminuisce in modo esponenziale oltre 64 "dimezzamenti" (halving) fino al blocco 13.230.000 (estratto approssimativamente nell'anno 2137), quando si raggiungerà l'unità monetaria minima di 1 satoshi per blocco. Infine, dopo 13,44 milioni di blocchi, nel 2140 circa, saranno stati emessi tutti i 2.099,999,997,690,000 satoshi (quasi 21 milioni di bitcoin). Successivamente, i blocchi non conterranno nuovi bitcoin e i miner saranno ricompensati esclusivamente attraverso le commissioni di transazione.

L'emissione limitata e decrescente crea un approvvigionamento monetario fisso che resiste all'inflazione. A differenza di una moneta fiat, che può essere stampata in numeri infiniti da una banca centrale, il bitcoin non può mai essere inflazionato arbitrariamente, ergo la conseguenza più importante e discussa dell'emissione monetaria fissa e decrescente è che la valuta tende ad essere intrinsecamente deflazionistica.

Consenso decentralizzato

Tutti i sistemi di pagamento tradizionali dipendono da un modello di fiducia che ha un'autorità centrale che fornisce un servizio di clearinghouse, sostanzialmente verificando e “ripulendo” (clearing) tutte le transazioni. In Bitcoin non c’è alcuna autorità centrale, ma ogni nodo completo ha una copia completa di un libro mastro pubblico di cui può fidarsi come registro “autorevole”. La blockchain non viene creata da un'autorità centrale, ma ogni nodo della rete, che agisce sulle informazioni trasmesse attraverso connessioni di rete non sicure, può arrivare alla stessa conclusione e assemblare una copia dello stesso libro mastro pubblico. La principale invenzione di Satoshi Nakamoto è il meccanismo decentralizzato per il consenso emergente. Emergente, perché non viene raggiunto in modo esplicito (non vi è alcuna elezione o momento fisso in cui si verifica un consenso) ma il consenso emerge dell'interazione asincrona di migliaia di nodi indipendenti, il tutto seguendo semplici regole.

Il consenso decentralizzato di Bitcoin emerge dall'interazione di quattro processi che avvengono indipendentemente sui nodi attraverso la rete:

• verifica indipendente di ogni transazione;

• aggregazione indipendente di tali transazioni in nuovi blocchi da parte dei miner (e consumo di risorse per l’attività);

• verifica indipendente dei nuovi blocchi da parte di ogni nodo e aggiunta in catena;

• selezione indipendente, per ogni nodo, della catena con maggior calcolo computazionale.

Verifica indipendente delle transazioni

Ogni nodo verifica ogni transazione in base a una lunga lista di criteri.

• La sintassi e la struttura dati della transazione devono essere corrette.

• Nessuna lista di input o output è vuota.

• La dimensione della transazione in byte è inferiore a MAX_BLOCK_SIZE.

• Ogni valore di output, così come il totale, deve essere compreso nell'intervallo di valori consentito (meno di 21 milioni di monete, più della soglia di “polvere”).

• Nessuno degli input ha hash=0, N=-1 (le transazioni “coinbase” non devono essere inoltrate).

• nLockTime è inferiore o uguale a INT_MAX.

• La dimensione della transazione in byte è maggiore o uguale a 100.

• Il numero di operazioni di firma contenute nella transazione è inferiore al limite dell'operazione di firma.

• Lo script di sblocco (scriptSig) può solo spingere i numeri sullo stack e lo script di blocco (scriptPubkey) deve corrispondere ai moduli IsStandard (ciò rifiuta le transazioni "non standard").

• Una transazione corrispondente nel pool o in un blocco nel ramo principale deve esistere.

• Per ogni input, se l'output di riferimento esiste in qualsiasi altra transazione nel pool, la transazione deve essere rifiutata.

• Per ogni input, cercare nel ramo principale e nella mempool per trovare l’output di transazione di riferimento. Se l’output manca per qualsiasi input, questa sarà una transazione orfana. Aggiungi al pool di transazioni orfane, se una transazione corrispondente non è già nel pool.

• Per ogni input, se l’output di transazione di riferimento è un output coinbase, deve avere almeno COINBASE_MATURITY (100) conferme.

• Per ogni input, l'output di riferimento deve esistere e non può essere già speso.

• Utilizzando gli output di riferimento della transazione per ottenere i valori di input, verificare che ciascun valore di input, nonché la somma, siano compresi nell'intervallo di valori consentito (meno di 21 milioni di monete, più di 0).

• Rifiuta se la somma dei valori di input è inferiore alla somma dei valori di output.

• Rifiuta se la commissione di transazione è troppo bassa per entrare in un blocco vuoto (minRealyTxFee).

• Gli script di sblocco per ciascun input devono essere convalidati rispetto agli script di blocco degli 'output corrispondenti.

Queste condizioni possono essere viste in dettaglio nelle funzioni AcceptToMemoryPool, CheckTransaction e CheckInput in Bitcoin Core (le condizioni cambiano nel tempo, per affrontare nuovi tipi di attacchi denial-of-service o talvolta per allentare le regole in modo da includere più tipi di transazioni).

Verificando indipendentemente ogni transazione così come viene ricevuta e prima di propagarla, ogni nodo crea un pool di nuove transazioni valide (ma non confermate): il transaction pool (memory pool o mempool).

Aggregazione delle transazioni in un blocco

Dopo aver validato le transazioni, un nodo bitcoin le aggiunge alla mempool, dove le transazioni attendono fino a quando non sono in un blocco (minate). A differenza degli altri nodi, un nodo di mining (o semplicemente miner) aggrega transazioni dentro ad un blocco candidato (candidate block).  Questo blocco è chiamato blocco candidato perché non è ancora un blocco valido, in quanto non contiene una prova di lavoro valida. Il blocco diventa valido solo se il minatore riesce a trovare una soluzione all'algoritmo di prova di lavoro.

Coinbase. La prima transazione aggiunta al blocco è una transazione speciale, chiamata coinbase. A differenza delle normali transazioni non consuma (spende) UTXO come input. Invece, ha un solo input, coinbase appunto, che crea bitcoin dal nulla, ed un output, pagabile all'indirizzo bitcoin del minatore stesso.

Coinbase rewards and fees. Per costruire la transazione di generazione, un miner calcola innanzitutto l'ammontare totale delle commissioni di transazione aggiungendo tutti gli input e gli output delle transazioni che sono state aggiunte al blocco. Le tariffe sono calcolate come: Total Fees = Sum (Inputs) - Sum (Outputs). Successivamente, un miner calcola la ricompensa corretta per il nuovo blocco. Il premio viene calcolato in base all’altezza (height) del blocco, a partire da 50 bitcoin per blocco e ridotto della metà ogni 210.000 blocchi. Il “sussidio iniziale” (initial subsidy) è calcolato in satoshi moltiplicando 50 con la costante COIN (100.000.000 satoshi). Questo imposta la ricompensa iniziale (nSubsidy) a 5 miliardi di satoshi. Successivamente, la funzione calcola il numero di halving che si sono verificati dividendo l'height del blocco corrente per l'intervallo di “dimezzamento” (SubsidyHalvingInterval). Nel caso del blocco 277.316, con halving ogni 210.000 blocchi, il risultato è 1 “dimezzamento”. Il numero massimo di halving consentiti è 64, quindi il codice impone un premio zero (restituisce solo le commissioni) se vengono superati i 64 halving. A questo punto, la funzione utilizza binary-right-shift-operator per dividere la ricompensa (nSubsidy) di 2 per ogni round di halving. Nel caso del blocco 277,316, questo spostamento di una volta a destra della ricompensa di 5 miliardi di satoshi (un halving) e il risultato è 2,5 miliardi di satoshi, o 25 bitcoin. Infine, la ricompensa della coinbase (nSubsidy) viene aggiunta alle commissioni di transazione (nFees) e la somma viene restituita.

Struttura della Coinbase. La transazione coinbase ha un formato speciale. Invece di un input di transazione che specifica un UTXO precedente da spendere, ha un input coinbase.

In una transazione coinbase, i primi due campi sono impostati su valori che non rappresentano un riferimento UTXO. Invece di un Transaction Hash, il primo campo viene riempito con 32 byte tutti impostati su zero. Output Index è pieno di 4 byte tutti impostati su 0xFF (255 decimale). Unlocking Script è sostituito da dati coinbase, un campo dati arbitrario usato dai minatori.

Coinbase data. Le transazioni coinbase non hanno un campo di script di sblocco (scriptSig). Invece, questo campo viene sostituito dai dati di coinbase, che devono essere compresi tra 2 e 100 byte. Tranne che per i primi pochi byte, il resto dei dati di coinbase può essere usato dai miner in qualsiasi modo essi vogliano (sono dati arbitrari). Nel genesis block Satoshi Nakamoto ha aggiunto il testo The Times 03/Jan/2009 Chancellor on brink of second bailout for banks, utilizzandolo come prova della data e trasmettendo un chiaro messaggio. Attualmente, i miner utilizzano i dati della coinbase per includere ulteriori valori nonce e stringhe che identificano il pool di data mining.

I primi pochi byte della coinbase erano arbitrari, ma non è più così. In base a BIP0034, i blocchi della versione 2 (blocchi con il campo versione impostato su 2) devono contenere l'indice di height del blocco come un'operazione push di script all'inizio del campo Coinbase. Nel blocco 277.316 vediamo che il coinbase, che si trova nel campo Unlocking Script o scriptSig dell'ingresso della transazione, contiene il valore esadecimale 03443b0403858402062f503253482f. Decodifichiamo questo valore.

Il primo byte, 03, indica al motore di esecuzione dello script di inserire i tre byte successivi nello stack di script. I successivi tre byte, 0x443b04, sono l'height del blocco codificata nel formato little-endian (backward, il byte meno significativo prima). Invertire l'ordine dei byte e il risultato è 0x043b44, che è 277.316 in decimale. Le successive cifre esadecimali (03858402062) vengono utilizzate per codificare un nonce extra, o valore casuale, utilizzato per trovare una soluzione di prova di lavoro adeguata. La parte finale dei dati coinbase (2f503253482f) è la stringa codificata ASCII / P2SH /, che indica che il nodo di data mining che ha estratto questo blocco supporta il miglioramento pay-to-script-hash (P2SH) definito in BIP0016. L'introduzione della funzionalità P2SH richiedeva un "voto" da parte dei miner per approvare BIP0016 o BIP0017. Coloro che approvavano l'implementazione di BIP0016 dovevano includere / P2SH / nei loro dati di coinbase. Coloro che approvavano l'implementazione BIP0017 di P2SH dovevano includere la stringa p2sh / CHV nei loro dati coinbase. Il BIP0016 è stato eletto come vincitore e molti miner hanno continuato a includere la stringa / P2SH / nella loro coinbase per indicare il supporto per questa funzione.

Costruire l’header del blocco. Per costruire l’header (intestazione) del blocco, i nodi di miner devono completare sei campi.

Nel momento in cui il blocco 277.316 è stato estratto, il version number che descrive la struttura a blocchi è 2, che è codificata in formato little-endian in 4 byte come 0x02000000. Successivamente, il miner deve aggiungere l’hash del blocco precedente (Previous Block Hash):

0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569

Il prossimo passo è quello di riepilogare tutte le transazioni con un merkle tree, in modo da aggiungere la merkle root all'header del blocco. La coinbase transaction è elencata come prima transazione nel blocco. Quindi, dopo di esso vengono aggiunte le altre transazioni, per un totale di 419 (in questo caso). Come abbiamo visto, ci deve essere un numero pari di "foglie" nell'albero, quindi l'ultima transazione viene duplicata, creando 420 nodi, ciascuno contenente l'hash di una transazione. Gli hash delle transazioni vengono quindi combinati, in coppie, creando ogni livello dell'albero, fino a quando tutte le transazioni sono riepilogate in un nodo nella merkle root, che riassume tutte le transazioni in un singolo valore di 32 byte:

c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e

Il miner aggiungerà quindi un timestamp a 4 byte, codificato come timestamp "Epoch" di Unix, che si basa sul numero di secondi trascorsi dal 1° gennaio 1970 alla mezzanotte UTC / GMT. L'ora 1388185914 è uguale a venerdì, 27 dicembre 2013, 23:11:54 UTC / GMT.

Il Difficulty Target definisce la difficoltà richiesta della Proof-of-Work per rendere questo blocco valido. La difficoltà è memorizzata nel blocco come una metrica "difficulty bits", che è una codifica mantissa-exponent del target. La codifica ha un esponente da 1 byte, seguito da una mantissa a 3 byte (coefficiente). Ad esempio, nel blocco 277.316 il valore dei bit di difficoltà è 0x1903a30c. La prima parte 0x19 è un esponente esadecimale, mentre la parte successiva, 0x03a30c, è il coefficiente.

Il campo finale è Nonce, che viene inizializzato a zero. Con tutti gli altri campi compilati, l'intestazione del blocco è ora completa e può iniziare il processo di mining. L'obiettivo è ora di trovare un valore per il nonce che si traduce in un hash di intestazione di blocco inferiore all'obiettivo di difficoltà. Il nodo di data mining dovrà testare miliardi o trilioni di valori nonce prima che venga trovato un nonce che soddisfi i requisiti (operazione attualmente eseguita in pochi secondi, al quale segue la modifica di ulteriori parametri).

Minare il blocco. Quando un blocco candidato è stato costruito dal miner, l'hardware di mining ”mina” il blocco cercando una soluzione all'algoritmo di PoW valida, utilizzando la funzione hash SHA256. Il mining è il processo di hashing dell'header del blocco ripetutamente, modificando un parametro, fino a quando l'hash risultante corrisponde a un target specifico. Il risultato della funzione di hash non può essere determinato in anticipo, né può essere creato uno schema che produca un valore hash specifico. Questa caratteristica delle funzioni di hash significa che l'unico modo per produrre un risultato di hash corrispondente a un obiettivo specifico è di provare ancora e ancora, modificando casualmente l'input finché il risultato dell'hash desiderato appare per caso.

Proof-of-Work Algorithm. Un algoritmo di hash prende un input di dati di lunghezza arbitraria e produce un risultato deterministico a lunghezza fissa, un'impronta digitale dell'input. Per ogni input specifico, l'hash risultante sarà sempre lo stesso e può essere facilmente calcolato e verificato da chiunque implementa lo stesso algoritmo di hash. La caratteristica chiave di un algoritmo di hash crittografico è che è praticamente impossibile trovare due input diversi che producono la stessa impronta digitale. Come corollario, è anche praticamente impossibile selezionare un input in modo tale da produrre un'impronta digitale desiderata, oltre a provare input casuali. Si vedano i seguenti esempi…

I am Satoshi Nakamoto0 → a80a81401...

I am Satoshi Nakamoto1 → f7bc9a630...

I am Satoshi Nakamoto2 → ea758a813...

I am Satoshi Nakamoto3 → bfa977961...

Ogni frase produce un hash completamente diverso, ma sempre lo stesso. Il numero usato come variabile in tale scenario è chiamato nonce. Il nonce viene utilizzato per variare l'output di una funzione crittografica, in questo caso per variare l'impronta digitale SHA256 della frase. Per creare una “sfida” con questo algoritmo, impostiamo un obiettivo arbitrario: trovare una frase che produce un hash esadecimale che inizia con uno 0. L'output SHA256 dello script I am Satoshi Nakamoto13 produce l'hash

0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5

che corrisponde ai nostri criteri (inizia con 0). Ci sono voluti 13 tentativi per trovarlo. In termini di probabilità, se l'output della funzione di hash è distribuito uniformemente ci aspetteremmo di trovare un risultato con uno 0 come prefisso esadecimale una volta ogni 16 hash (una su 16 cifre esadecimali da 0 a F). In termini numerici, ciò significa trovare un valore hash inferiore a

0x1000000000000000000000000000000000000000000000000000000000000000

Chiamiamo questa soglia “obiettivo” e il compito è trovare un hash che sia numericamente inferiore all'obiettivo. Se riduciamo l'obiettivo, il compito di trovare un hash che è inferiore all'obiettivo diventa sempre più difficile. Nell'output SHA256 di uno script per generare molti hash modificando un nonce, il "nonce" vincente è 13 e questo risultato può essere confermato da chiunque in modo indipendente. Chiunque può aggiungere il numero 13 come suffisso alla frase "I am Satoshi Nakamoto" e calcolare l'hash, verificando che sia inferiore all'obiettivo. Il risultato positivo è anche una prova del lavoro, perché dimostra che abbiamo fatto il lavoro per trovare quel nonce. Mentre ci vuole solo un calcolo hash per verificare, ci sono voluti 13 calcoli hash per trovare un nonce che ha funzionato. Se avessimo un obiettivo inferiore (difficoltà più alta) ci vorrebbero molti più calcoli per trovare un nonce adatto, ma solo un calcolo per chiunque da verificare. Inoltre, conoscendo l'obiettivo, chiunque può stimare la difficoltà usando le statistiche e quindi sapere quanto lavoro è stato necessario per trovare un tale nonce.

La Proof of Work (prova di lavoro) di Bitcoin è molto simile alla sfida mostrata nell'output SHA256 di uno script per generare molti hash ripetendo su un nonce. Il miner costruisce un blocco candidato riempiendolo di transazioni. Poi, il miner calcola l'hash dell'intestazione di questo blocco e vede se è inferiore al target corrente. Se l'hash non è inferiore all'obiettivo, il minatore modificherà il nonce (di solito solo incrementandolo di uno) e riprova. Alla difficoltà attuale nella rete bitcoin, i minatori devono provare quadrilioni di volte prima di trovare un nonce che si traduce in un hash dell'header del blocco idoneo. Ad inizio 2017, la rete stava cercando di trovare un blocco il cui hash dell’header è inferiore a:

0000000000000000029AB9000000000000000000000000000000000000000000.

Ci vogliono in media più di 1.8zeta-hashes (migliaia di miliardi di miliardi) al secondo per consentire alla rete di scoprire il prossimo blocco. Sembra un compito impossibile, ma fortunatamente la rete stava portando a 3 exa-hashes al secondo (EH / sec) di potenza di calcolo, che sarà in grado di trovare un blocco in media in circa 10 minuti (attualmente siamo nell’ordine dei 120 EH/sec).

Target. Nel blocco 277.316, il blocco contiene il Target, in una notazione chiamata "bit di difficoltà" o semplicemente "bit", che nel blocco 277.316 ha il valore di 0x1903a30c. Questa notazione esprime l'obiettivo della PoW di difficoltà come un formato coefficiente / esponente, con le prime due cifre esadecimali per l'esponente e le successive sei cifre esadecimali come coefficiente. In questo blocco, quindi, l'esponente è 0x19 e il coefficiente è 0x03a30c.

Ciò significa che un blocco valido per l'height 277.316 è uno che ha un hash dell’header del blocco inferiore all’obiettivo. In binario, quel numero avrebbe più dei primi 60 bit impostati a zero. Con questo livello di difficoltà, un singolo minatore che elabora 1 trilione di hash al secondo (1 tera-hash al secondo o 1 TH / sec) troverà una soluzione solo una volta ogni 8.496 blocchi o una volta ogni 59 giorni, in media.

Aggiustamento del target. Come abbiamo visto, il target determina la difficoltà e quindi influenza il tempo necessario per trovare una soluzione all'algoritmo di prova di lavoro. I blocchi di Bitcoin vengono generati ogni 10 minuti, in media. Questo è il battito del bitcoin e sostiene la frequenza dell'emissione di valuta e la velocità di liquidazione della transazione. Deve rimanere costante non solo nel breve periodo, ma per un periodo di molti decenni. In questo periodo, si prevede che l'energia del computer continuerà ad aumentare a un ritmo rapido. Inoltre, anche il numero di partecipanti nel settore del mining e i computer che usano cambierà costantemente. Per mantenere il tempo di generazione del blocco a 10 minuti, la difficoltà deve essere regolata tenendo conto di questi cambiamenti. Infatti, la difficoltà è un parametro dinamico che viene periodicamente regolato per raggiungere un target di 10 minuti. Il retargeting della difficoltà si verifica automaticamente e su ogni nodo completo indipendentemente. Ogni 2.016 blocchi, tutti i nodi ricalibrano la difficoltà della PoW. L'equazione per il retargeting della difficoltà misura il tempo impiegato per trovare gli ultimi 2.016 blocchi e li confronta con il tempo previsto di 20.160 minuti (due settimane in base al tempo di blocco desiderato di 10 minuti). Viene calcolato il rapporto tra il tempo reale e il periodo temporale desiderato e viene effettuata una correzione corrispondente (più o meno) alla difficoltà. In termini semplici: se la rete trova blocchi più velocemente di ogni 10 minuti, la difficoltà aumenta. Se la scoperta dei blocchi è più lenta del previsto, la difficoltà diminuisce. Per evitare la volatilità estrema della “difficoltà”, la regolazione del retargeting deve essere inferiore a un fattore di 4 per ciclo. Qualsiasi ulteriore aggiustamento verrà effettuato nel prossimo retargeting perché lo squilibrio persisterà nei successivi 2.016 blocchi. Si noti che la difficoltà è indipendente dal numero di transazioni o dal valore delle transazioni. Ciò significa che la quantità di potenza di hash e quindi di energia spesa per proteggere bitcoin è del tutto indipendente dal numero di transazioni. Bitcoin può scalare, ottenere un'adozione più ampia e rimanere al sicuro senza alcun aumento della potenza di hashing dal livello attuale.

Mining. Dopo aver costruito un candidate block, l’header viene dato in pasto all’hardware di mining che comincia a testare trilioni di nonce al secondo. Poiché il nonce è di 32 bits, dopo aver esaurito tutte i nonce possibili - circa 4 miliardi, l’hardware modifica l’header del blocco (modificando lo spazio extra nonce della coinbase o il timestamp) resettando il counter del nonce e testando nuove combinazioni. Quasi 11 minuti dopo aver cominciato a minare il blocco 277.216, un hardware ha trovato la soluzione e rimandata al miner (mining node). Quando inserito nell’header, il nonce 924.591.752 produce l’hash

0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4

Che è inferiore al target:

0000000000000003A30C00000000000000000000000000000000000000000000

Immediatamente il miner trasmette il blocco ai peer. Loro ricevono, validano e propagano il nuovo blocco, che nodo per nodo viene aggiunto alla loro copia della blockchain che viene così estesa alla nuova altezza (height) di 277.316 blocchi. Man mano che i miner ricevono il blocco smettono di cercare soluzioni relative a quel height e cominciano a computare il prossimo blocco usando l’ultimo come “genitore”: cominciando a costruire sul blocco ricevuto gli altri miner si esprimono (“votano”) in favore dell’ultimo blocco ricevuto e la catena così estesa.

Validazione di un blocco

Il terzo passo nel meccanismo di consenso di bitcoin è la convalida indipendente di ogni nuovo blocco da parte di ogni nodo della rete. Mentre il blocco appena risolto si sposta attraverso la rete, ciascun nodo esegue una serie di test per validarlo prima di propagarlo ai pari. Ciò garantisce che solo i blocchi validi vengano propagati sulla rete. La convalida indipendente garantisce anche che i miner che agiscono in modo onesto ottengano i loro blocchi incorporati nella blockchain, guadagnando così la ricompensa. Quei miner che agiscono disonestamente hanno i loro blocchi respinti e non solo perdono la ricompensa, ma anche sprecano lo sforzo speso per trovare la PoW, incorrendo così nel costo dell'elettricità senza compensazione.

Quando un nodo riceve un nuovo blocco, convalida il blocco controllandolo secondo criteri che devono essere tutti soddisfatti; diversamente il blocco viene rifiutato. Questi criteri possono essere visualizzati nel client Bitcoin Core nelle funzioni CheckBlock e CheckBlockHeader e includono:

• La struttura dati del blocco è sintatticamente valida

• L'hash dell’header del blocco è inferiore al target

• Il timestamp del blocco è inferiore a due ore in avanti

• La dimensione del blocco è entro limiti accettabili

• La prima transazione (e solo la prima) è una transazione di coinbase

• Tutte le transazioni all'interno del blocco sono valide relativamente alla checklist considerata in Verifica indipendente delle transazioni (vedi sopra)

Assemblare e selezionare la catena di blocchi

Il passo finale nel meccanismo di consenso decentralizzato di bitcoin è l'assemblaggio di blocchi in catene e la selezione della catena con la maggior prova di lavoro. Una volta che un nodo ha convalidato un nuovo blocco, tenterà quindi di assemblare una catena collegando il blocco alla blockchain esistente. I nodi mantengono tre serie di blocchi:

• quelli collegati alla blockchain principale;

• quelli che formano rami dalla blockchain principale (catene secondarie);

• i blocchi che non hanno un genitore conosciuto nelle catene conosciute (orfani).

I blocchi non validi vengono rifiutati non appena uno dei criteri di convalida fallisce e quindi non sono inclusi in nessuna catena. La "catena principale" in qualsiasi momento è qualsiasi catena di blocchi abbia più PoW cumulativa ad essa associata. Nella maggior parte dei casi questa è anche la catena con il maggior numero di blocchi, a meno che non ci siano due catene di uguale lunghezza e una ha più PoW. La catena principale avrà anche rami con blocchi che sono "fratelli" (siblings) dei blocchi sulla catena principale. Questi blocchi sono validi ma non fanno parte della catena principale.

Quando viene ricevuto un nuovo blocco, un nodo proverà a inserirlo nella blockchain esistente. Il nodo esaminerà il campo previous block hash del blocco, che è il riferimento al genitore del nuovo blocco. Quindi, il nodo tenterà di trovare quel genitore nella blockchain esistente. La maggior parte delle volte, il genitore sarà il "suggerimento" della catena principale, il che significa che questo nuovo blocco estende la catena principale. Ad esempio, il nuovo blocco 277.316 ha un riferimento all'hash del blocco genitore 277.315. La maggior parte dei nodi che ricevono 277.316 avranno già il blocco 277.315 come punta della loro catena principale e quindi collegheranno il nuovo blocco ed estenderanno quella catena. A volte il nuovo blocco estende una catena che non è la catena principale. In tal caso, il nodo assegnerà il nuovo blocco alla catena secondaria che estende e quindi confronterà la difficoltà della catena secondaria con la catena principale. Se la catena secondaria ha più PoW cumulativa rispetto alla catena principale, il nodo ri-converge sulla catena secondaria, il che significa che seleziona la catena secondaria come la sua nuova catena principale, rendendo la vecchia catena principale una catena secondaria. Se il nodo è un miner, costruirà un blocco che estende questa nuova catena più lunga. Se viene ricevuto un blocco valido e nessun genitore viene trovato nelle catene esistenti, quel blocco viene considerato "orfano". I blocchi orfani vengono salvati nel pool di blocchi orfani dove rimarranno fino alla ricezione del genitore. Una volta che il genitore è stato ricevuto e collegato nelle catene esistenti, l'orfano può essere estratto dal pool orfano e collegato al genitore, rendendolo parte di una catena. I blocchi orfani si verificano in genere quando due blocchi estratti in un breve lasso di tempo vengono ricevuti in ordine inverso. Selezionando la catena con la maggior PoW, tutti i nodi raggiungono infine un consenso a livello di network. Le discrepanze temporanee tra le catene sono risolte alla fine con l'aggiunta di ulteriori PoW, estendendo una delle possibili catene. I miner "votano" con la loro potenza di estrazione scegliendo quale catena estendere minando il blocco successivo.

Alessio Salvetti, Co-founder di Bcademy e board member (VP), business developer, filosofo per formazione e bitcoiner per passione, esperto di modeling e lean startup, è co-founder di Inbitcoin e responsabile prodotto di Bcademy (CPO).