La forcazione della blockchain (Accoto 2018)

La forcazione della blockchain tra storia del registro e politica del protocollo (Accoto 2018)

Una fork -che ho tradotto con ‘forcazione’- è una condizione architetturale critica propria delle reti decentralizzate permissionless (come, ad esempio, Bitcoin o Ethereum). Ma è anche molto più di un elemento di vulnerabilità tecnologica: indesiderata e al tempo stesso inevitabile, una forcazione è l’evento ciclico che negozia e istanzia la storia del registro e il governo del protocollo. Un forking event è, cioè, il momento tecnico -connesso alla duplice e distinta occasione di accodamento dei dati nel registro e di aggiornamento delle funzionalità del protocollo- in cui rischiano periodicamente di collassare, da un lato, la maintenance storica della verità del mondo (cioè, il suo regime documentale) e, dall’altro, la governance politica della rete decentralizzata (vale a dire, il suo regime istituzionale).

Sono due dimensioni estremamente rilevanti per una futura economia e società decentralizzata fondata su reti e mercati aperti ed automatizzati fault-tolerant. Converrà allora qui approfondire, sia pure in sintesi, gli aspetti operativi implicati nell’emergenza di una forcazione per comprenderne meglio la sua portata. Chiariamo anzitutto perché si definisce “forcazione”. Il concetto si riferisce all’evento sociotecnico, accidentale o intenzionale, per cui la catena dei blocchi originaria (ad esempio quella di Bitcoin costruita energeticamente nel tempo accodando in un’unica sequenza irreversibile le transazioni) si scinde in ramificazioni temporanee e/o permanenti. In/da quell’istante, la blockchain perde la configurazione unilineare a catena per somigliare di più ad un albero ramificato.

Nella prospettiva della rete decentralizzata di Nakamoto i cui nodi competono per scrivere la verità del mondo (cioè per pubblicare nel registro condiviso i blocchi di dati validati), questi fenomeni di forcazione sono eventi da considerare ‘naturali’ o meglio connaturati alle logiche e alle dinamiche di una rete alla pari. Al contempo, sono criticità che la rete decentralizzata deve saper e poter gestire in modo da evitare copie diseguali della storia con versioni disallineate sugli stati del mondo ad un dato istante. Col tempo, abbiamo imparato a riconoscere due tipologie fondamentali di forcazioni: quelle connesse al registro (nelle fasi di accodamento di nuovi dati nel ledger) e quelle derivanti dal protocollo (nelle fasi di introduzione di nuove regole di consenso).

Forcazioni della storia del registro

Poiché più nodi competono per determinare quale sarà il nuovo blocco di dati da accodare alla catena, può accadere e accade in effetti di frequente che due blocchi (es. a, b) vengano minati (validati via prova del lavoro) contemporaneamente da due diversi nodi, pubblicati nell’arco di pochi secondi e aggiunti alla catena di blocchi esistente. A questo punto e per alcuni minuti a causa del ritardo della propagazione, la rete decentralizzata farà esperienza di due diverse catene di blocchi entrambe temporaneamente valide (catena+a vs catena+b). In/per una catena, ad es., la mia transazione sarà stata validata e pubblicata (in quanto inclusa nel blocco a); in/per l’altra catena, invece, la mia transazione risulterà ancora in sospeso e non pubblicata (perché non inclusa nel blocco b).

Si avranno, dunque, due blockchain che pubblicheranno in rete due storie del registro differenti. Per qualche minuto, nodi diversi della rete avranno viste diverse rispetto al registro (e allo stato del mondo) da considerare come valido: per alcuni nodi sarà la catena+a, per altri nodi la catena+b. Si tratta di forcazioni cosiddette regolari o ‘naturali’ in quanto accadono di frequente nel corso delle operazioni di accodamento dati. Questo stato ramificato -momentaneamente inconsistente- della blockchain deve, però, essere ricondotto ad una, nuovamente unica e lineare, catena di blocchi pena l’inconsistenza delle informazioni.

Questo avviene attraverso un processo di convergenza computazionale (ricordiamo infatti che in una rete decentralizzata fault-tolerant non c’è nessuna autorità centralizzata unificante che possa decretare la verità e correttezza delle informazioni). Poiché, però, il processo di generazione e accodamento dei blocchi alla catena è continuativo, l’arrivo e la validazione di un nuovo blocco (diciamo un blocco c, successivo ai due che hanno causato la forcazione temporanea) permetterà di creare una catena più lunga tra le due formate. Sarà questa la catena che i nodi riconosceranno (fork choice) come quella unica su cui convergere tutti (ad esempio, il ramo temporaneo catena+a+c).

Più lunga è qui da intendersi, tecnicamente, come la catena che ha richiesto la maggiore spesa energetica computazionale cumulativa (prova del lavoro fino a quel momento) per essere prodotta. Di norma, nel tempo di creazione di un nuovo blocco, la forcazione momentanea viene risolta: il ramo della catena con minore lavoro computazionale -la catena+b nel nostro caso- verrà abbandonato come orfano da tutti i nodi a favore della catena più ‘lavorata’ (implicitamente più sicura e vera). Nella blockchain di Bitcoin, ad es, un intervallo di dieci minuti è stata la scelta di network design fatta dall’origine per bilanciare un’adeguata velocità delle transazioni e una contenuta probabilità delle forcazioni.

Ma cosa accade, invece, quando si tratta non di accodare le transazioni sul registro, ma di cambiare le regole del consenso?

Forcazioni del governo del protocollo

In occasione della modifica delle regole di consenso del protocollo in una rete decentralizzata alla pari, può accadere ed effettivamente accade che possano generarsi forcazioni della blockchain. Anche in questo caso ovviamente non è possibile affidarsi ad un’autorità centrale che decida e imponga a tutti i nodi della rete il passaggio alla nuova versione del codice. Necessarie e generative, queste forcazioni sono però al contempo rischiose. Necessarie perché sono disegnate e implementate per migliorare le performance della rete decentralizzata (almeno nei casi benevoli). Comunque rischiose perché intervengono a modificare un’ecologia di architetture computazionali, regole procedurali e agentività nodali (tra nodi minatori, nodi clienti, …) in dinamico, precario e complesso equilibrio.

Possono essere innescate da progetti di sviluppo software migliorativi della rete blockchain (es. rimediare ad un errore o limite del codice) oppure dalla volontà di creare una scissione della catena di blocchi (per creare -ad esempio- un nuovo criptoservizio) o da attacchi malevoli intenzionalmente tesi a frodare, colludere o manipolare (nel caso di un double spending o di un denial-of-service). In ogni caso è implicata una questione vitale: quella della governance del protocollo e delle relative politiche di orchestrazione e gestione decentralizzata del cambiamento del codice. La forcazione del codice (pratica per altro comune nella comunità dell’open source software) ha storicamente assunto due forme abbastanza distinte: hard e soft fork.

– Soft fork

Una forcazione soft è un aggiornamento “limitativo” del protocollo (del suo codice, delle regole o delle sue operazioni). Potrebbe non essere considerata propriamente una forcazione, in quanto il mancato aggiornamento da parte dei nodi della rete non impedisce loro di continuare ad operare dentro un’unica catena. Questi ultimi, quindi, non sono tecnicamente (e politicamente) forzati ad adeguarsi per rimanere nodi attivi della rete. Il meccanismo per l’attivazione di una forcazione soft è la segnalazione (signaling) con cui esplicitano alla rete di essere propensi e pronti ad accogliere l’aggiornamento.

Se tutti i nodi aggiornano, non si ha vera fork; se la maggioranza dei nodi aggiorna, la nuova catena prevale e la precedente viene abbandonata; se la maggioranza non concorda sull’aggiornamento, la nuova catena non sopravvive. Le forcazioni soft sono, comunque, retrocompatibili e, di norma, preferite in quanto meno rischiose per gli equilibri politici della rete decentralizzata. Tuttavia, non sono considerate prive di vulnerabilità anche in relazione ai metodi operativi specifici con cui si opera l’aggiornamento. Tra le criticità, possiamo indicare, ad esempio, la crescita della complessità del codice (con rischio errori o gravosi costi di manutenzione) e l’irreversibilità delle modifiche (in caso di difetti del nuovo codice, la probabilità di perdita di dati e valori è molto alta).

– Hard fork

Una forcazione hard è, invece, un aggiornamento “estensivo” del protocollo (del suo codice, delle regole, delle sue operazioni). La nuova versione, cioè, introduce delle nuove funzionalità che prima erano considerate invalide. Può dare vita propriamente una forcazione, in quanto il mancato aggiornamento da parte dei nodi della rete impedisce loro di continuare ad operare dentro la blockchain e forca la catena tra nodi con protocollo aggiornato e nodi con vecchia versione. Questi ultimi, pertanto, sono tecnicamente (e politicamente) forzati ad adeguarsi, nel caso, per poter continuare la propria partecipazione. Le forcazioni hard non sono retrocompatibili e si cerca di evitarle pianificando -in accordo con la maggioranza dei nodi/maggiore potenza computazionale (planned hard fork)- il cambio delle regole in modo che non avvenga la scissione.

Se tuttavia, non vi è accordo tra i nodi (contentious hard fork), le forcazioni hard danno vita a catene di blocchi distinte e la scissione diventa permanente con due blockchain -due stati e due verità del mondo- che evolveranno distintamente. In questo caso, l’evento di forking segna una separazione irreversibile e incompatibile. Per fare un esempio, molte delle criptomonete alternative ai bitcoin sono nate come forcazione della catena di blocchi originata da Satoshi Nakamoto. In breve, una scissione (chain split) implica: una forcazione del codice (due versioni del software), del consenso (due meccanismi di validazione), della rete (due insiemi di nodi), dell’energia (due potenze di hashing), del registro (due catene dei blocchi).

Operativamente, quando si propone e si genera una modifica del codice propagandola in rete, i nodi sono chiamati a decidere se accettare o meno questo aggiornamento del protocollo. L’accettazione o meno innesca automaticamente e in sequenza comportamenti nodali vincolanti: dal rifiuto di riconoscere i blocchi e le transazioni create con le nuove regole di validazione alla disconnessione dai nodi che non hanno aggiornato il codice. Questo creerà una partizione permanente della rete tra nodi aggiornati e nodi non aggiornati e, conseguentemente, anche tra le due rispettive potenze computazionali.

Queste meccaniche -che abbiamo cercato qui di semplificare al massimo- implicano e innescano articolate sociodinamiche di rete in termini di connessioni e dipendenze, meccanismi di incentivi e disincentivi, pratiche di coercizione e adesione, conflitti tra visioni diverse sull’evoluzione del protocollo. Dinamiche, per altro, in continua evoluzione. Con questa nota introduttiva alla questione della governance di un sistema di rete alla pari, ci interessava anche soprattutto dare un’idea della relazione tra immutabilità e cambiamento nei criptosistemi. Una overview che accenna alla complessità delle tecnoecologie decentralizzate al di là dei facili miti sull’immutabilità della blockchain. Dialetticamente –si direbbe- un’immutabilità che viene preservata attraverso il cambiamento.

[Accoto 2018, work in progress – continua …]