La formazione del consenso nella blockchain in assenza di autorità centralizzate, il problema dei generali bizantini e prospettive future
di Andrea d’Anna
La blockchain è una tecnologia innovativa spesso definita come un registro digitale decentralizzato e distribuito, in grado di garantire la sicurezza ed immutabilità dei dati.
La blockchain si basa su un’organizzazione egualitaria e sul principio di reciprocità diretta tipico di una rete peer to peer che consente l’assenza di intermediari o di organi terzi di controllo al suo interno. Le transazioni vengono registrate dai nodi della rete all’interno dei blocchi che compongono la catena (e che danno il nome alla tecnologia stessa)[1].
Uno degli aspetti peculiari di tale tecnologia[2] è proprio la presenza di un sistema decentralizzato in cui determinati attori del network agiscono quali “validatori” delle operazioni compiute, superando cosi la necessità di doversi avvalere di terze parti fidate, storicamente deputate ad attività di controllo e approvazione (“autorità centralizzate”).
Nella blockchain (con particolare riferimento a blockchain permissionless o pubbliche[3]) l’assenza di autorità centralizzate determina infatti la necessità per i componenti del network di dover raggiungere un consenso diffuso in merito ai singoli “stati”[4] in cui la blockchain si trova, per poter procedere ad una corretta registrazione delle transazioni (ed in generale degli accordi contrattuali) all’interno dei blocchi e a rendere tali registrazioni definitive nel ledger.
Non bisogna dimenticare che per quanto la blockchain sia una tecnologia basata su regole matematiche e logiche informatiche, in assenza di un’autorità centralizzata, il compito di raggiungere un accordo sui singoli stati della catena deve comunque spettare a determinati soggetti aventi potere decisionale all’interno del network (tendenzialmente miner e full-node[5]).
Ecco, dunque, che il concetto di consenso viene a qualificarsi come processo attraverso il quale è possibile che i soggetti dotati di potere decisionale raggiungano un accordo sui singoli stati della blockchain in modo da costituire l’unica possibile verità sullo stato attuale della catena e su ciò che è accaduto[6].
Ci si interroga spesso su come sia possibile che in una blockchain permissionless in cui il network è composto da soggetti provenienti da differenti parti del mondo e che non si conoscono, si riesca a raggiungere un consenso distribuito, specialmente in presenza di possibili comportamenti scorretti da parte delle varie figure che compongono il network (specialmente i miner) data l’assenza di un’autorità centralizzata.
Il consenso rappresenta dunque un problema molto complesso ed è spesso associato al problema dei generali bizantini[7].
Il problema dei generali bizantini risulta utile per spiegare come nella blockchain permissionless si riesca a raggiungere il consenso in una situazione in cui uno o più nodi del network possano comunicare o ricevere informazioni diverse e/o non corrette.
Il problema dei generali bizantini prevede che un gruppo di generali, ciascuno al comando di una porzione dell’esercito bizantino, circondi una città. I generali devono decidere se attaccare o ritirarsi. L’importante non è la decisione finale in sé (attaccare o ritirarsi) ma raggiungere un consenso unanime affinché tutti i generali possano dar seguito ad una stessa decisione in modo coordinato, evitando conseguenze catastrofiche come ad esempio che alcuni soggetti attacchino mentre altri si ritirino. Generali disonesti potrebbero infatti decidere di comunicare selettivamente ad alcuni generali di attaccare e ad altri di ritirarsi.
Se si applica il problema dei generali bizantini al contesto della blockchain, ogni generale rappresenta un nodo del network dotato di potere decisionale ed il piano di attaccare o ritirarsi rappresenta la singola decisione che i nodi dotati di potere decisionale devono adottare in merito alla validazione o meno del blocco creato.
Al fine di risolvere i problemi legati alla formazione del consenso, soluzioni blockchain quali quella alla base della tecnologia Bitcoin hanno adottato un protocollo del consenso chiamato “Proof of work”[8] (“prova di lavoro”) al fine di rendere la blockchain “Bizantyne fault tolerant” (“tollerante ai guasti bizantini”).
Il Proof of Work richiede che i miner, al fine di creare il blocco successivo e guadagnare una ricompensa, dopo aver selezionato le transazioni da includere nel blocco competano per risolvere, mediante l’utilizzo di risorse informatiche, un problema basato sulla ricerca di un valore numerico estremamente difficile da trovare[9] ma che una volta trovato è facilmente verificabile dagli ulteriori nodi[10].
Il miner che riesce a risolvere il problema comunica il blocco creato agli altri nodi che verificano la correttezza della soluzione. Se il 51% dei nodi ritiene che la soluzione sia valida, il miner si aggiudica una ricompensa ed ottiene che il nuovo blocco venga aggiunto alla catena.
Il superamento del problema dei generali bizantini all’interno della blockchain avviene pertanto mediante una soluzione probabilistica[11]. Ciascun miner per arrivare ad una soluzione valida agli occhi degli ulteriori nodi deve operare una lunga serie di tentativi (che costituiscono una vera e propria “prova di lavoro” – Proof of Work).
Considerate le ingenti risorse richieste[12], i costi per sostenere l’attività di mining, la difficoltà ed il tempo necessario a risolvere il problema e la quasi totale impossibilità di indovinare la soluzione dopo pochi tentativi, il Proof of Work appare in grado di operare una forte selezione all’ingresso di per sé già idonea a limitare azioni in malafede legate alla gestione del consenso o volte a compromettere la sicurezza della rete anche ad opera di terze parti.
Bisogna tuttavia specificare che anche il Proof of Work presenta vulnerabilità, specialmente connesse all’attacco del 51% che si verifica quando un miner, o un blocco di miner in collusione, raggiungano il 51% della potenza di calcolo (“hashrate”) totale del network ottenendo cosi la possibilità di controllare più velocemente dei restanti miner tanto la generazione di nuovi blocchi quanto l’approvazione di nuove transazioni o causare fenomeni quali il double spending[13].
Ipotizzare un attacco del 51% all’interno di architetture blockchain di dimensioni notevoli risulta tuttavia alquanto difficile visto che l’aggiunta di un nodo al network incrementa la sicurezza del network e il tempo di transazione di 1/N[14]. Si segnala tuttavia che attacchi del 51% su blockchain di scala minore sono già occorsi[15].
A seguito della conversione in legge del D.L. 135/2018[16], sull’onda di un’imminente implementazione di tecnologie basate su registri distribuiti in Italia ci si è spesso chiesti se la blockchain in generale (e nello specifico l’utilizzo di algoritmi quale il Proof of Work per la gestione del consenso) consentano di sostituire figure professionali quali quelle di notai, banche ed ulteriori autorità centralizzate.
A distanza di più di un anno dalla conversione in legge del D.L. 135/2018 appare opportuno sottolineare come diverse soluzioni a base blockchain in Italia siano state adottate su modelli di tipo permissioned[17] e non permissionless, optando cosi per l’adozione di modelli che prevedano la presenza autorità centralizzate.
Società private hanno quindi implementato architetture blockchain volendo mantenere una forma di controllo sui partecipanti, richiedendo un’autorizzazione preventiva per l’accesso e decidendo a quali componenti del network spetti il potere decisionale, introducendo anche limitazioni alla capacità di leggere i contenuti registrati (di qualsiasi natura essi siano).
Tali modelli comportano inevitabilmente la perdita di alcuni vantaggi intrinseci a modelli di blockchain permissionless (ed in primis il modello definito da Satoshi Nakamoto), connessi alla assenza di censure ed alla completa trasparenza dei contenuti, in cambio una maggiore sicurezza del network connessa al riconoscimento di chi effettua le transazioni.
Ecco che di fronte all’adozione di modelli di blockchain permissionless anche le figure professionali quali ad esempio enti certificatori o notai potrebbero trarre nuove opportunità di business, diventando dei veri e propri nodi certificatori all’interno di network blockchain gestiti dalle imprese, come ad esempio nel progetto (in fase di sviluppo) di blockchain per professionisti che esercitano la figura di notaio, in partnership con IBM[18], dove i notai svolgeranno la funzione di “nodi” garantendo la certezza e la correttezza dei dati.
Appare, dunque, spontaneo domandarsi come mai si prediliga l’adozione di modelli maggiormente indirizzati a blockchain permissioned che permissionless.
Agli occhi di scrive la soluzione a tale risposta è sicuramente in parte connessa alle esigenze di business delle imprese che hanno maggior interesse a poter esercitare un’attività di “censura” e di controllo all’interno di una tecnologia nella quale sono raccolti dati ed informazioni connessi alle loro attività.
Sotto un’ulteriore prospettiva sembrerebbe inoltre che la portata innovativa di tale tecnologia sia stata tale da tradursi in un atteggiamento a tratti passivo da parte degli utenti che (come di fronte a diverse soluzioni digitali) hanno rinunciato a voler comprendere il pieno potenziale tecnologico della blockchain (almeno in questa prima fase) lasciando ampio margine decisionale alle imprese.
Chissà che il rilascio delle linee guida sulla blockchain da parte dell’Agenzia per l’Italia Digitale non possa stravolgere il quadro sopra delineato.
Note:
[1] Sul punto si veda Nanni F. A., Blockchain e GDPR, in antitesi by default, disponibile online all’indirizzo https://www.cyberlaws.it/2018/blockchain-e-gdpr-in-antitesi-by-default/.
[2] Per un approfondimento sulla storia e sul funzionamento della tecnologia blockchain si rimanda a Balbo A., La Blockchain e il suo funzionamento, disponibile online all’indirizzo https://www.cyberlaws.it/2018/blockchain-e-funzionamento/.
[3] Per blockchain permissionless o pubblica si intende una tipologia di blockchain a cui tutti i soggetti possono prendere parte senza limitazioni ed in cui non esiste una singola autorità centrale, a differenza della blockchain permissioned (per la definizione di blockchain permissioned si veda la nota 10).
[4] Per “stato” di una blockchain si intende la sua struttura e la sua composizione nel singolo momento di osservazione.
[5] Per miner si intendono i nodi deputati all’attività di mining ossia (in estrema sintesi) alla selezione delle transazioni da includere nei blocchi, alla risoluzione del puzzle, alla creazione di nuovi blocchi ed alla loro registrazione all’interno del ledger. Per full node si intendono nodi dotati di un potere di verifica del rispetto delle regole del network con riferimento alle transazioni ed ai contenuti dei blocchi – per maggiori informazioni si veda https://bitcoin.org/en/full-node.
[6] Sul punto si veda Chiap G., Ranalli J., Bianchi R., Blockchain tecnologia e applicazioni per il business, Ulrico Hoepli Editore, 2019.
[7] Sul punto si veda Bennett K., Rieger M., Lee E., Certified Blockchain Solution Architect (CBSA), Blockchain Training Alliance.
[8] L’algoritmo Proof of Work rappresenta una delle principali soluzioni adottate ai fini dell’adozione di meccanismi del consenso ma non l’unica. Si segnala infatti che ulteriori soluzioni blockchain prevedono ad oggi meccanismi diversi dal Proof of Work quali ad esempio “Proof of Stake”, “Delegated Proof of Stake”, “Proof of Activity” e “Proof of Authority”. Sul punto si veda Sarzana F., Ippolito S., Nicotra M., Diritto della blockchain, intelligenza artificiale ed IoT, Wolters Kluwer, 2018.
[9] La risoluzione del problema è ottenibile mediante l’esperimento da parte dei miner di tentativi casuali (“random guessing”) volti ad indovinare una soluzione estremamente difficile, nel rispetto di un vincolo di difficoltà imposto dal network.
[10] Sul punto si veda https://en.wikipedia.org/wiki/Hashcash.
[11] Sul punto si veda Poston H., Bennett K., Certified Blockchain Security Professional (CBSP), Blockchain Training Alliance.
[12] Si consideri che all’interno di Bitcoin l’enorme potenza di calcolo richiesta ai fini dell’attività di mining comporta il consumo di circa lo 0,3% dell’elettricità mondiale, con una spesa per elettricità ed hardware pari a circa 1 milione di dollari al giorno.
[13] Per approfondimenti sui concetti di attacco al 51% e double spending si veda https://en.wikipedia.org/wiki/Double-spending.
[14] Per “N” si intende il numero dei nodi del network blockchain.
[15] Sul punto si veda Sedgwick K., Verge Is Forced to Fork After Suffering a 51% Attack, consultabile online all’indirizzo https://www.bitcoininsider.org/article/22681/verge-forced-fork-after-suffering-51-attack.
[16] Sul punto si veda la definizione di tecnologie basate su registri distribuiti di cui all’articolo 8-ter “Tecnologie basate su registri distribuiti e smart contract” del D.L. 135/2018, coordinato con la legge di conversione 12/2019, recante disposizioni urgenti in materia di sostegno e semplificazione per le imprese e per la pubblica amministrazione, disponibile all’indirizzo https://www.gazzettaufficiale.it/eli/id/2019/02/12/19A00934/sg.
[17] Per blockchain privata o permissioned si intende una tipologia di blockchain (tipica di strutture industriali e consortili) all’interno della quale vi è un controllo più o meno centralizzato che in alcuni casi può divenire completamente deputato ad un organo privato, tale da limitare l’accesso alla tecnologia e/o richiedere una verifica dell’identità dei soggetti partecipanti al network.
[18] Sul punto si veda il comunicato stampa disponibile all’indirizzo: https://www.notariato.it/sites/default/files/cs_notarchain_13102017.pdf.
Bibliografia:
Balbo A., La Blockchain e il suo funzionamento, disponibile online all’indirizzo https://www.cyberlaws.it/2018/blockchain-e-funzionamento/
Bennett K., Rieger M., Lee E., Certified Blockchain Solution Architect (CBSA), Blockchain Training Alliance
Chiap G., Ranalli J., Bianchi R., Blockchain tecnologia e applicazioni per il business, Ulrico Hoepli Editore, 2019
Double-spending: https://en.wikipedia.org/wiki/Double-spending
Fullnode: https://bitcoin.org/en/full-node
Hashcash: https://en.wikipedia.org/wiki/Hashcash
Nanni F. A., Blockchain e GDPR, in antitesi by default, disponibile online all’indirizzo https://www.cyberlaws.it/2018/blockchain-e-gdpr-in-antitesi-by-default/
Notarchain: https://www.notariato.it/sites/default/files/cs_notarchain_13102017.pdf
Poston H., Bennett K., Certified Blockchain Security Professional (CBSP), Blockchain Training Alliance
Sarzana F., Ippolito S., Nicotra M., Diritto della blockchain, intelligenza artificiale ed IoT, Wolters Kluwer, 2018
Sedgwick K., Verge Is Forced to Fork After Suffering a 51% Attack, consultabile online all’indirizzo: https://www.bitcoininsider.org/article/22681/verge-forced-fork-after-suffering-51-attack
Autore:
