CAPIRE BITCOIN | PARTE UNDICESIMA | SEZIONE SECONDA: BITCOIN, MINING E CONSENSUS #2

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.

Fork della blockchain

Poiché la blockchain è una struttura dati decentralizzata, alcune copie di essa non sono sempre coerenti. Per risolvere questo problema, ogni nodo seleziona sempre e tenta di estendere la catena di blocchi con la maggior PoW (nota anche come catena più lunga). Sommando “il lavoro” registrato in ciascun blocco, un nodo può calcolare la quantità totale di PoW che è stata spesa per creare quella catena. Finché tutti i nodi selezionano la catena di difficoltà cumulativa più lunga, la rete globale di bitcoin alla fine converge in uno stato coerente. I fork (biforcazioni) si presentano come incoerenze temporanee tra versioni della blockchain, che vengono risolte dall'eventuale riconversione man mano che più blocchi vengono aggiunti a una delle biforcazioni.

La topologia della rete bitcoin non è organizzata geograficamente, ma forma una rete mesh di nodi interconnessi, che potrebbero essere localizzati molto lontano l'uno dall'altro geograficamente. La rappresentazione di una topologia geografica è una semplificazione utilizzata per illustrare un fork. Nella rete di bitcoin reale, la "distanza" tra i nodi viene misurata in "salti" da nodo a nodo, non sulla loro posizione fisica. A scopo illustrativo, i diversi blocchi sono mostrati come colori diversi, si diffondono attraverso la rete e colorano le connessioni che attraversano.

Nel primo diagramma, la rete ha una prospettiva c’è  della blockchain, con il blocco blu come la punta della catena principale.

Un fork si verifica ogni volta che ci sono due blocchi in competizione: ciò si verifica in condizioni normali ogni volta che due miner risolvono l'algoritmo di PoW in un breve periodo di tempo l'uno dall'altro. Mentre entrambi i miner scoprono una soluzione per i rispettivi blocchi candidati, trasmettono immediatamente il proprio blocco "vincente" ai loro vicini immediati che iniziano a propagare il blocco attraverso la rete. Ogni nodo che riceve un blocco valido lo incorporerà nella blockchain, estendendo la blockchain di un blocco. Se in seguito il nodo vede un altro blocco candidato che estende lo stesso genitore, collega il secondo candidato su una catena secondaria. Di conseguenza, alcuni nodi "vedranno" prima un blocco, mentre altri nodi vedranno emergere l'altro blocco e due versioni concorrenti della blockchain. Entrambi questi blocchi sono figli del blocco (“blu”), pensato per estendere la catena costruendo sopra il blocco (“blu”).

Supponiamo, ad esempio, che un miner trovi una soluzione di PoW con un blocco “rosso" che estende la blockchain, costruendo sopra il blocco principale "blu". Quasi contemporaneamente, un altro che stava anche estendendo il blocco "blu" trova una soluzione con un blocco "verde". Ora, ci sono due possibili blocchi, uno che chiamiamo "rosso" e uno che chiamiamo "verde". Entrambi i blocchi sono validi, entrambi i blocchi contengono una soluzione valida per PoW, ed entrambi i blocchi estendono lo stesso genitore (ed entrambi i blocchi probabilmente contengono la maggior parte delle stesse transazioni). Mentre i due blocchi si propagano, alcuni nodi ricevono prima il blocco "rosso" e alcuni ricevono prima il blocco "verde": la rete si divide in due diverse prospettive della blockchain.

Da quel momento, i nodi della rete bitcoin più vicina (topologicamente, non geograficamente) riceveranno prima il blocco "rosso" e creeranno una nuova blockchain dalla “maggiore difficoltà cumulativa” con "rosso" come ultimo blocco della catena (ad esempio, blu-rosso), ignorando il blocco candidato "verde" che arriva un po 'più tardi. Nel frattempo, i nodi più vicini al nodo “australiano” prenderanno quel blocco come vincitore e estenderanno la blockchain con "verde" come ultimo blocco (ad esempio, blu-verde), ignorando "rosso" quando arriverà qualche secondo dopo. Tutti i miner che hanno visto "rosso" per primi costruiranno immediatamente i blocchi candidati che fanno riferimento a "rosso" come genitore e iniziano a provare a risolvere la PoW per questi blocchi candidati. I minatori che hanno accettato "verde" invece inizieranno a costruire in cima a "verde" e ad estendere tale catena. I fork sono quasi sempre risolti in un blocco. Come parte della potenza di hashing della rete è dedicato alla costruzione di "rosso" come genitore, un'altra parte della potenza di hashing è incentrata sulla costruzione di "verde". Anche se il potere di hashing è diviso in modo quasi uniforme, è probabile che un gruppo di miner troverà una soluzione e la propagherà prima che l'altro gruppo di miner abbia trovato qualche soluzione. Diciamo, per esempio, che i miner che si trovano in cima a "verde" trovano un nuovo blocco "rosa" che estende la catena (ad esempio, blu-verde-rosa). Propagano immediatamente questo nuovo blocco e l'intera rete lo vede come una soluzione valida.

Tutti i nodi che hanno scelto "verde" come vincitore nel round precedente estenderanno semplicemente un ulteriore blocco alla catena. I nodi che hanno scelto "rosso" come vincitore, tuttavia, vedranno ora due catene: blu-verde-rosa e blu-rosso. La catena blu-verde-rosa è ora più lunga (più difficoltà cumulativa) rispetto alla catena blu-rossa. Di conseguenza, questi nodi imposteranno la catena blu-verde-rosa come catena principale e trasformeranno la catena blu-rossa in catena secondaria: la rete riconverge su una nuova catena più lunga. Questa è una riconversione della catena, perché quei nodi sono costretti a rivedere la loro prospettiva della blockchain per incorporare la nuova evidenza di una catena più lunga. Tutti i miner che lavorano sull'estensione della catena blu-rossa ora interromperanno il lavoro perché il loro blocco candidato è un "orfano", poiché il suo genitore "rosso" non è più sulla catena più lunga. Le transazioni all'interno di "rosso" vengono nuovamente messe in coda per l'elaborazione nel blocco successivo, poiché tale blocco non si trova più nella catena principale. L'intera rete ri-converge su una singola blockchain blu-verde-rosa, con "rosa" come ultimo blocco della catena. Tutti i miner iniziano immediatamente a lavorare su blocchi candidati che fanno riferimento a "rosa" come genitore per estendere la catena blu-verde-rosa.

È teoricamente possibile che un fork si estenda fino a due blocchi, se due blocchi si trovano quasi contemporaneamente da miner su "lati" opposti di un fork precedente. Tuttavia, la possibilità che ciò accada è molto bassa. L'intervallo di blocco di Bitcoin a 10 minuti è un compromesso di progettazione tra i tempi di conferma rapidi (liquidazione delle transazioni) e la probabilità di un fork.

Mining e “Hashing Race”

Il mining di Bitcoin è un settore estremamente competitivo. Il potere di hashing è aumentato esponenzialmente ogni anno dell'esistenza di bitcoin. In pochi anni la crescita ha riflesso un cambiamento completo della tecnologia, come nel 2010 e nel 2011, quando molti miner passarono dall'utilizzo dell'estrazione della CPU all'estrazione di GPU e all'estrazione FPGA (field programmable gate array). Nel 2013 l'introduzione dell'ASIC mining ha portato a un altro gigantesco balzo in avanti nel settore, collocando la funzione SHA256 direttamente su chip di silicio specializzati ai fini del mining. I primi chip di questo tipo potrebbero fornire più potenza di estrazione in un singolo box rispetto all'intera rete bitcoin nel 2010.

Il seguente elenco mostra la potenza di hashing totale della rete bitcoin, nei primi otto anni di funzionamento:

• 2009: 0.5 MH/sec–8 MH/sec (16× growth)

• 2010: 8 MH/sec–116 GH/sec (14,500× growth)

• 2011: 116 GH/sec–9 TH/sec (78× growth)

• 2012: 9 TH/sec–23 TH/sec (2.5× growth)

• 2013: 23 TH/sec–10 PH/sec (450× growth)

• 2014: 10 PH/sec–300 PH/sec (30× growth)

• 2015: 300 PH/sec-800 PH/sec (2.66× growth)

• 2016: 800 PH/sec-2.5 EH/sec (3.12× growth)

• Attualmente siamo nell’ordine dei 120 EH/sec

Negli ultimi due anni (2016-17) i chip ASIC sono diventati sempre più “denser”, raggiungendo la soglia di fabbricazione del silicio alla dimensione (risoluzione) di 16 nm (nanometri). Attualmente l’obiettivo è di arrivare ai 14nm superando le CPU general-purpose, poiché la profittabilità del settore è più alta di quello generalista. La potenza di mining della rete continua ad avanzare ad un ritmo esponenziale dato che la corsa per i chip è accompagnata ad una gara per data center a densità più elevata in cui è possibile distribuire migliaia di questi chip. Non si tratta più di quanto si può minare con un solo chip, ma di quante chip ci stanno in un edificio (pur continuando a dissipare il calore e fornendo una potenza adeguata).

The Extra Nonce Solution. Dal 2012, il mining si è evoluto per risolvere una limitazione fondamentale nella struttura dell'header del blocco. Agli albori si poteva minare un blocco iterando attraverso il nonce fino a quando l'hash risultante era inferiore all'obiettivo. A mano a mano che aumentava la difficoltà, i miner spesso “pedalavano” attraverso tutti i 4 miliardi di valori del nonce senza trovare un hash idoneo. Tuttavia, questo è stato facilmente risolto aggiornando il timestamp del blocco per tenere conto del tempo trascorso. Poiché il timestamp fa parte dell'header, la modifica consente ai miner di scorrere nuovamente i valori del nonce con risultati diversi. Una volta che l'hardware di mining ha superato i 4GH/ sec, tuttavia, questo approccio è diventato sempre più difficile perché i valori nonce sono stati esauriti in meno di un secondo. Poiché le attrezzature di mining ASIC iniziarono “a spingere” e quindi a superare la frequenza TH/sec, il software di mining richiedeva più spazio per i valori nonce al fine di trovare blocchi validi. Il timestamp può essere allungato, ma spostarlo troppo lontano nel futuro potrebbe rendere il blocco invalido. Nell'intestazione del blocco era necessaria una nuova fonte di "modifica". La soluzione era usare la coinbase come fonte di valori extra nonce. Poiché lo script coinbase può archiviare tra 2 e 100 byte di dati, i miner hanno iniziato a utilizzare quello spazio come spazio extra nonce, consentendo loro di esplorare una gamma molto più ampia di valori di header del blocco per trovare blocchi validi. La coinbase è inclusa nel merkle tree, il che significa che qualsiasi modifica nello script coinbase fa cambiare la merkle root. 8 byte di extra nonce, più i 4 byte di "standard" nonce permettono ai minatori di esplorare un totale di 296 (8 seguito da 28 zeri) possibilità al secondo senza dover modificare il timestamp. Se, in futuro, i minatori dovessero attraversare tutte queste possibilità, potrebbero quindi modificare il timestamp. C'è anche più spazio nello script coinbase per la futura espansione di spazio extra nonce.

Mining Pools. In questo ambiente altamente competitivo, i singoli miner non hanno alcuna possibilità poiché la probabilità che trovino un blocco per compensare i costi dell'elettricità e dell'hardware è tremendamente bassa. I miner collaborano per formare pool, unendo il loro potere di hashing e condividendo la ricompensa tra migliaia di partecipanti. I blocchi vincenti pagano la ricompensa a un indirizzo bitcoin pool, piuttosto che a singoli miner. Il server del pool eseguirà periodicamente i pagamenti agli indirizzi bitcoin dei miner, una volta che la loro quota dei premi ha raggiunto una certa soglia. In genere, il server del pool addebita una percentuale dei premi per fornire il servizio di pool-mining.

I miner che partecipano a un pool dividono il lavoro di ricerca di una soluzione per un blocco candidato, guadagnando "quote" (share) per il loro contributo. Il pool di mining imposta un obiettivo di difficoltà inferiore per guadagnare una quota, in genere più di 1.000 volte più semplice della difficoltà della rete bitcoin. Quando qualcuno nel pool riesce a estrarre un blocco, il premio viene guadagnato dal pool e poi condiviso con tutti i minatori in proporzione al numero di quote che hanno contribuito allo sforzo.

La maggior parte dei pool di mining è "gestita" da una società o una persona che esegue un server di pool. Il proprietario del server del pool viene chiamato gestore e addebita ai miner una percentuale delle entrate.

I pool gestiti creano la possibilità di imbrogli da parte dell'operatore del pool, che potrebbe indirizzare lo sforzo del pool verso operazioni di doppia spesa o invalidare i blocchi. Inoltre, i server di pool centralizzati rappresentano un single-point-of-failure. Se il server della pool è inattivo o viene rallentato da un attacco denial-of-service, i miner del pool non possono minare. Nel 2011, per risolvere questi problemi di centralizzazione, è stato proposto e implementato un nuovo metodo di mining pool: P2Pool è un pool di mining peer-to-peer, senza un operatore centrale.

Attacchi al “Consensus”

Il meccanismo di consenso di Bitcoin è, almeno teoricamente, vulnerabile agli attacchi di miner (o pool) che tentano di usare il loro potere di hashing per fini disonesti o distruttivi. Come abbiamo visto, il meccanismo del consenso dipende dal fatto che la maggioranza dei miner agisce onestamente per interesse personale. È importante notare che gli attacchi al consenso possono influenzare solo il consenso futuro o, nel migliore dei casi, il passato più recente (decine di blocchi). Il registro di Bitcoin diventa sempre più immutabile con il passare del tempo. Mentre in teoria, un fork può essere raggiunto a qualsiasi profondità (height), in pratica, la potenza di calcolo necessaria per forzare un fork molto profondo è immensa, rendendo i vecchi blocchi praticamente immutabili. Gli attacchi al consenso non influiscono sulla sicurezza delle chiavi private e dell'algoritmo di firma (ECDSA). Un attacco di consenso non può sottrarre bitcoin, spendere bitcoin senza firme, reindirizzare bitcoin o modificare in altro modo transazioni passate o record di proprietà. Gli attacchi al consenso possono riguardare solo i blocchi più recenti e causare interruzioni di tipo denial-of-service sulla creazione di blocchi futuri. Uno scenario di attacco contro il meccanismo del consenso è chiamato "attacco al 51%". In questo scenario un gruppo di miner, controllando la maggioranza (51%) del potere di hashing della rete totale, collude per attaccare bitcoin. Con la possibilità di estrarre la maggior parte dei blocchi, i miner attaccanti possono causare "fork" deliberati nelle transazioni blockchain e double-spendere (doppia spesa) o eseguire attacchi denial-of-service contro transazioni o indirizzi specifici. Un attacco fork / double-spend è un attacco in cui l'attaccante fa sì che i blocchi precedentemente confermati vengano invalidati mediante la biforcazione sotto di essi e la ricomposizione in una catena alternativa. Con una potenza sufficiente, un utente malintenzionato può invalidare sei o più blocchi di fila, causando l'annullamento delle transazioni considerate immutabili (sei conferme). Una doppia spesa può essere effettuata solo sulle transazioni dell'hacker, per le quali l'attaccante può produrre una firma valida (doppio-spendere le proprie transazioni è redditizio se invalidando una transazione l'attaccante può ottenere un pagamento o un prodotto di cambio non reversibile senza pagarlo).

Un attacco a doppia spesa può avvenire in due modi: prima che una transazione sia confermata, o se l'attaccante sfrutta un fork per annullare diversi blocchi. Un attacco al 51% consente agli aggressori di raddoppiare le proprie transazioni nella nuova catena, annullando la transazione corrispondente nella vecchia catena.

Per proteggersi da questo tipo di attacco, un commerciante che vende oggetti di grande valore deve attendere almeno sei conferme prima di dare il prodotto all'acquirente. In alternativa, il commerciante deve utilizzare un account multi-firma di deposito a garanzia.

Oltre a un attacco a doppia spesa, l'altro scenario per un attacco di consenso consiste nel negare il servizio a partecipanti di bitcoin specifici (specifici indirizzi bitcoin). Un attaccante con la maggioranza del “potere” può semplicemente ignorare transazioni specifiche. Se sono incluse in un blocco minato da un altro minatore, l'attaccante può deliberatamente forkare e ri-minare quel blocco, escludendo di nuovo le transazioni specifiche. Questo tipo di attacco può comportare una “negazione del servizio” prolungata rispetto a uno specifico indirizzo o insieme di indirizzi fino a quando l'attaccante controlla la maggior parte della potenza di estrazione.

Nonostante il suo nome, lo scenario di attacco del 51% non richiede in realtà il 51% della potenza di hashing. In realtà, un tale attacco può essere tentato con una percentuale minore della potenza di hashing. La soglia del 51% è semplicemente il livello al quale un tale attacco ha una riuscita quasi garantita. Un attacco al consenso è essenzialmente un tiro alla fune per il prossimo blocco e il gruppo "più forte" ha più probabilità di vincere. Con meno potere di hashing, la probabilità di successo è ridotta, perché altri minatori controllano la generazione di alcuni blocchi con la loro "onesta" potenza di hashing. Un modo per vederlo è che più potere di hashing ha un attaccante, più lungo è il fork che può creare deliberatamente, più blocchi nel recente passato possono invalidare, o più blocchi in futuro che può controllare. La centralizzazione del controllo causata dai pool di mining ha introdotto il rischio di attacchi da parte di un gestore di pool di data mining. L'operatore del pool controlla la costruzione dei blocchi candidati e controlla anche quali transazioni sono incluse. Ciò fornisce al gestore del pool il potere di escludere le transazioni o introdurre transazioni a doppia spesa. Se tale abuso di potere è fatto in modo limitato e sottile, un operatore di pool potrebbe teoricamente trarre profitto da un attacco di consenso senza essere notato.

Tuttavia, non tutti gli aggressori saranno motivati dal profitto. Uno scenario di potenziale attacco è dove un attaccante intende interrompere la rete bitcoin senza la possibilità di trarre profitto da tale interruzione. Un attacco malevolo mirato a paralizzare bitcoin richiederebbe enormi investimenti e una pianificazione nascosta, ma potrebbe essere probabilmente lanciato da un attaccante ben finanziato e molto probabilmente sponsorizzato dallo stato. In alternativa, un aggressore ben finanziato potrebbe attaccare il consenso di Bitcoin accumulando simultaneamente hardware di mining, compromettendo gli operatori di pool e attaccando altri pool con denial-of-service. Tutti questi scenari sono teoricamente possibili, ma sempre più impraticabili in quanto la potenza di hashing complessiva della rete bitcoin continua a crescere esponenzialmente. I recenti progressi in Bitcoin, come l'estrazione di P2Pool, mirano a decentralizzare ulteriormente il controllo delle miniere, rendendo ancora più difficile attaccare il consenso. Indubbiamente, un serio attacco di consenso eroderebbe la fiducia nel bitcoin a breve termine, causando probabilmente un significativo calo dei prezzi. Tuttavia, la rete Bitcoin e il software sono in continua evoluzione, quindi gli attacchi del consenso sarebbero stati affrontati con contromisure immediate da parte della comunità bitcoin, rendendo i bitcoin più resistenti, più stabili e più robusti che mai.

Modificare le “Consensus Rules”

Le regole del consenso determinano la validità di transazioni e blocchi. Mentre nel breve periodo sono invariabili, così non è nel lungo periodo, ciò per evolvere e sviluppare il sistema Bitcoin, fixare bug, etc. Ciò richiede una decisa attività di coordinamento tra i partecipanti.

Hard Fork. In uno scenario di cambiamento delle regole di consenso il network può divergere su due catene differenti: ciò viene definito hard fork, poiché dopo il fork il network non riconverge  su una singola catena, ma due catene evolvono indipendentemente l’una dall’altra. Si ha un hard fork quando una parte del network opera con un differente set di consensus rules. Un nodo che non aggiorna alle nuove regole non è più in grado di partecipare al meccanismo di consenso ed è costretto a rimanere sull’altra catena. Nell’immagine dopo il fork al blocco 4 il network riconverge su una catena, ed il fork è “risolto”. 

Con il blocco 6 invece siamo di fronte ad un hard fork: ad esempio una nuova versione del client può essere stata rilasciata con una modifica delle regole di consenso (dal blocco 7 i miner che fanno girare la nuova implementazione accettano, ad esempio, un nuovo tipo di firma digitale). Per un miner che non fa girare la nuova implementazione, le transazioni firmate con la nuova firma, così come i blocchi che le contengono sono invalidi (ergo rigettano e non propagano). Dopo il primo blocco “doppio”, i miner sulla b continueranno a minare blocchi sulla nuova catena, che verranno invece ignorati dai miner sulla vecchia catena: anche qualora in un ipotetico blocco 8 non ci fossero transazioni con la nuova firma, quel blocco sarebbe sempre orfano sulla catena a perché il blocco genitore non sarebbe mai riconosciuto come valido.

Esempi di fork di software che hanno tentato di modificare le regole di consenso includono Bitcoin XT, Bitcoin Classic e, più recentemente, Bitcoin Unlimited. Tuttavia, nessuna di questi fork software ha provocato un hard fork. Mentre un fork del software è una condizione preliminare necessaria, non è di per sé sufficiente per un hard fork. Affinché un hard fork si verifichi, è necessario che l’implementazione concorrente venga adottata e le nuove regole attivate dai miner, wallet e nodi intermedi. Viceversa, ci sono numerose implementazioni alternative di Bitcoin Core che non cambiando le regole di consenso possono coesistere sulla rete e interoperare senza causare un hard fork.

Le regole di consenso possono differire in modi ovvi ed espliciti (convalida di transazioni o blocchi) o più sottili (implementazione delle regole di consenso per come si applicano agli script bitcoin o crittografiche come le firme digitali). Infine, le regole di consenso possono differire in modi imprevisti a causa di vincoli impliciti di consenso imposti da limitazioni di sistema o dettagli di implementazione (un esempio di quest'ultimo è stato l'imprevisto hard fork durante l'aggiornamento di Bitcoin Core da 0.7 a 0.8, causato da una limitazione dell'implementazione del DB di Berkeley utilizzata per memorizzare i blocchi).

Concettualmente, possiamo pensare a un hard fork come uno sviluppo in quattro fasi:

• un fork del software

• un fork di rete

• un fork di data mining

• un fork della catena.

Il processo inizia quando un'implementazione alternativa del client, con regole di consenso modificate, viene creata dagli sviluppatori. Questo questa implementazione è “deployata” nel network, una percentuale di miner, user (di wallet), e nodi potranno adottare e girare questa implementazione. Il fork risultante dipenderà dal fatto che le nuove regole di consenso si applichino a blocchi, transazioni o altri aspetti del sistema. Se le nuove regole di consenso riguardano le transazioni, un portafoglio che crea una transazione con le nuove regole può far accadere un fork della rete, seguito da un hard fork quando la transazione viene minata in un blocco. Se le nuove regole riguardano i blocchi, il processo di hard fork inizierà quando un blocco viene minato secondo le nuove regole.

In primo luogo, la rete si biforca. I nodi basati sull'implementazione originale delle regole di consenso rifiuteranno tutte le transazioni e i blocchi creati con le nuove regole. Inoltre, i nodi che seguono le regole di consenso originali verranno temporaneamente esclusi e disconnessi da tutti i nodi che inviano loro transazioni e blocchi non validi. Di conseguenza, la rete si dividerà in due: i vecchi nodi rimarranno collegati ai vecchi nodi e i nuovi nodi saranno collegati solo ai nuovi nodi. Una singola transazione o blocco basato sulle nuove regole si propagherà attraverso la rete e determinerà la partizione in due reti.

Finché i miner divergono su due catene differenti, il loro hashing power è splittato sulle due catene, e ciò potrebbe causare importanti disagi a seconda del momento in cui questo avviene (distanza dal periodo di retargeting della difficulty).

Gli hard fork sono considerati rischiosi perché costringono una minoranza a effettuare l'aggiornamento o a rimanere su una catena minoritaria. Il rischio di dividere l'intero sistema in due sistemi concorrenti è visto da molti come un rischio inaccettabile. Di conseguenza, molti sviluppatori sono riluttanti a utilizzare il meccanismo di hard fork per implementare gli aggiornamenti alle regole di consenso, a meno che non vi sia un supporto quasi unanime dell'intera rete. Tutte le proposte di hard fork che non hanno un sostegno quasi unanime sono considerate troppo "controverse" per tentare senza rischiare una partizione del sistema.

Soft Fork. Non tutte le modifiche alle regole del consenso determinano un hard fork. Solo le modifiche di consenso che sono incompatibili “in avanti” (forward-incompatible) causano un fork. Se la modifica è implementata in modo tale che un client non modificato vede ancora la transazione o il blocco come valido secondo le regole precedenti, la modifica può avvenire senza fork. Il termine soft fork è stato introdotto per distinguere questo metodo di aggiornamento da un hard fork. In pratica, un soft fork non è propriamente un fork: è una modifica compatibile “in avanti” con le regole di consenso che consente ai client non aggiornati di continuare a operare in accordo con le nuove regole. Un aspetto dei soft fork che non è immediatamente ovvio è che gli aggiornamenti possono essere utilizzati solo per vincolare le regole di consenso, non per estenderle. Per essere compatibili con il futuro, le transazioni e i blocchi creati con le nuove regole devono essere validi anche in base alle vecchie regole, ma non viceversa. Le nuove regole possono limitare solo ciò che è valido; in caso contrario, attivano un hard fork quando vengono respinti in base alle vecchie regole. I soft fork possono essere implementati in diversi modi: il termine non specifica un particolare metodo, piuttosto un insieme di metodi che hanno tutti una cosa in comune: non richiedono che tutti i nodi eseguano l'aggiornamento o forzino i nodi non aggiornati fuori dal consenso. Un numero di soft fork è stato implementato basandosi sulla reintrepetazione di NOP opcodes. Bitcoin Script aveva 10 opcodes riservati per futuri utilizzi, da NOP1 a NOP10. In base alle regole di consenso, la presenza di questi opcode in uno script viene interpretata come un operatore null-potent, nel senso che non hanno alcun effetto. L'esecuzione continua dopo l'opcode NOP come se non ci fosse. Un soft fork quindi può modificare la semantica di un codice NOP per dargli un nuovo significato. Ad esempio, BIP-65 (CHECKLOCKTIMEVERIFY) ha reinterpretato l'opcode NOP2. I client che implementano BIP-65 interpretano NOP2 come OP_CHECKLOCKTIMEVERIFY e impongono una regola di consenso assoluta di blocco su UTXO che contengono questo codice operativo nei loro script di blocco. Questa modifica è un soft fork poiché una transazione valida in BIP-65 è valida anche su qualsiasi client che non implementa (ignorando) BIP-65. Per i vecchi client, lo script contiene un codice NOP, che viene ignorato.

Recentemente un altro meccanismo di soft fork è stato introdotto non relato ai NOP opcodes per una specifica modifica del consenso: Segwit è un cambio nella struttura di una transazione, che sposta lo script di sblocco (testimone) dall’interno della transazione a una struttura di dati esterna (“segregandola”). Il meccanismo utilizzato è stato una modifica dello script di blocco di un UTXO creato sotto le regole segwit, così che i client non modificati vedano lo script di blocco come redimibile comunque con qualsiasi script di sblocco. Le principali problematiche dell’utilizzo di soft fork sono:

• “Debito tecnico”, ovvero il costo futuro di mantenimento del codice;

• “Validazione rilassata”, da parte dei nodi non aggiornati che validano rimanendo ciechi su alcune specifiche;

• “Aggiornamenti irreversibili”: le limitazioni introdotte con un aggiornamento diventano irreversibili.

Soft Fork e Block Version

Finché i soft fork permettono a client non-modificati di continuare ad operare dentro al consenso, il meccanismo per “attivare” un soft fork è rappresentato dai miner che segnalano la loro disponibilità: la maggioranza dei miner deve essere d'accordo sul fatto che siano pronti e disposti a far rispettare le nuove regole di consenso. Per coordinare le loro azioni, c'è un meccanismo di segnalazione che consente loro di mostrare il loro supporto per un cambiamento della regola del consenso. Questo meccanismo è stato introdotto con l'attivazione di BIP-34 (marzo 2013) e sostituito dall'attivazione di BIP-9 (luglio 2016).

BIP-34 Signaling and Activation. La prima implementazione, in BIP-34, utilizzava il campo version per consentire ai minatori di segnalare la disponibilità per una specifica modifica della regola del consenso. Prima del BIP-34, la version era impostata su "1" per convenzione non applicata per consenso. BIP-34 ha definito una modifica della regola del consenso che richiede che il campo coinbase (input) della transazione coinbase contenga l'height del blocco. Prima del BIP-34, la coinbase poteva contenere qualsiasi dato arbitrario che i miner avessero scelto di includere. Dopo l'attivazione di BIP-34, i blocchi validi devono contenere una specifica height all'inizio della coinbase e essere identificati con un numero di versione maggiore o uguale a "2." Per segnalare la modifica e l'attivazione di BIP-34, i miner impostano la versione del blocco su "2", anziché su "1." Questo non ha reso immediatamente i blocchi della versione "1" non validi. Una volta attivata, i blocchi con versione "1" non sarebbero più validi e tutti i blocchi di versione "2" dovrebbero contenere l'height del blocco nella coinbase per essere validi. BIP-34 ha definito un meccanismo di attivazione in due fasi, basato su una finestra a rotazione di 1000 blocchi. Un miner avrebbe segnalato la sua prontezza individuale per BIP-34 costruendo blocchi con "2" come numero di versione. A rigor di termini, questi blocchi non avrebbero dovuto ancora conformarsi alla nuova regola del consenso di includere l'height del blocco nella coinbase perché la regola del consenso non era ancora stata attivata. Le regole di consenso si sono attivate in due fasi:

• Se il 75% (750 dei più recenti 1000 blocchi) sono contrassegnati con la versione "2", i blocchi di versione "2" devono contenere l'height del blocco nella coinbase oppure vengono rifiutati come non validi. I blocchi della versione "1" sono ancora accettati dalla rete e non devono contenere l’height. Le vecchie e nuove regole di consenso coesistono durante questo periodo.

• Quando il 95% (950 dei più recenti 1000 blocchi) sono versione "2", i blocchi versione "1" non sono più considerati validi. I blocchi di versione "2" sono validi solo se contengono l'height del blocco nella coinbase (come per la soglia precedente).

Dopo aver segnalato e attivato con successo BIP-34, questo meccanismo è stato utilizzato altre due volte per attivare soft fork: BIP-66 e BIP-65, dopo il quale il meccanismo di segnalazione e attivazione di BIP-34 è stato ritirato e sostituito con il meccanismo di segnalazione BIP-9 descritto in seguito.

BIP-9 Signaling and Activation. BIP-34 permetteva di attivare un solo soft fork per volta (e soffriva di altre limitazioni). BIP-9 interpreta la version come un campo di bit invece di un intero. Poiché la version era originariamente utilizzata come un numero intero, versioni da 1 a 4, restano disponibili solo 29 bit da utilizzare come campo di bit. Questo lascia 29 bit che possono essere utilizzati per segnalare in modo indipendente e simultaneamente 29 proposte diverse. BIP-9 imposta anche un tempo massimo per la segnalazione e l'attivazione. In questo modo i miner non hanno bisogno di segnalare per sempre. Se una proposta non viene attivata entro il periodo TIMEOUT (definito nella proposta), la proposta viene considerata respinta. Dopo il TIMEOUT una funzione è stata attivata o rifiutata, il bit di segnalazione può essere riutilizzato per un'altra funzione senza confusione. Pertanto, fino a 29 cambiamenti possono essere segnalati in parallelo e dopo TIMEOUT i bit possono essere "riciclati" per proporre nuove modifiche.

A differenza di BIP-34, BIP-9 conta la segnalazione di attivazione a intervalli interi in base al periodo di retarget della difficulty. Per ogni periodo di retarget, se la somma dei blocchi che segnalano una proposta supera il 95% (1916 dei 2016), la proposta verrà attivata nel periodo successivo.

Le proposte iniziano nello stato DEFINED, una volta che i loro parametri sono noti (definiti) nel software bitcoin. Per i blocchi con MTP dopo l'ora di inizio, lo stato della proposta passa a STARTED. Se la soglia di voto viene superata entro un periodo di retarget e il timeout non è stato superato, lo stato della proposta passa a LOCKED_IN. Dopo un periodo di retargeting, la proposta diventa ACTIVE. Le proposte rimangono nello stato ATTIVO perennemente quando raggiungono quello stato. Se il timeout è trascorso prima del raggiungimento della soglia di voto, lo stato della proposta passa a FAILED, che indica una proposta respinta. Le proposte FALLITE rimangono in quello stato perpetuamente.

BIP-9 è stato implementato per la prima volta per l’attivazione di CHECKSEQUENCEVERIFY e BIP associate (68, 112, 113).

Per la sua stessa natura, Bitcoin stabilisce un livello molto alto di coordinamento e consenso per i cambiamenti al “Consensus”. Come sistema decentralizzato, non ha “autorità” che possa imporre la sua volontà ai partecipanti della rete. La “potenza” è diffusa tra miner, sviluppatori principali, sviluppatori di wallet, exchange, commercianti e utenti finali. Le decisioni non possono essere prese unilateralmente da nessuno di questi. La soglia del 95% per i soft fork riflette questa realtà. È importante riconoscere che non esiste una soluzione perfetta per lo sviluppo del consenso. Sia gli hard che i soft fork implicano compromessi. Per alcuni tipi di modifiche, i soft fork possono essere una scelta migliore; per altri, gli hard fork potrebbero essere una scelta migliore. Non c'è scelta perfetta; entrambi comportano rischi. L'unica caratteristica costante dello sviluppo del software “di consenso” è che il cambiamento è difficile, e ciò è forse la più grande forza del sistema.

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).