La blockchain, da sola, non è immutabile (parte 1 di 2)

decentralizzazione e consenso, da soli, non bastano a sostenere un livello adeguato di immutabilità senza l’aiuto di un cryptoasset

la voce immutabile nel Vocabolari Treccani (versione online)

L’attenzione che le tecnologie basate su registri distribuiti (Distributed Ledger Technologies o DLT) stanno ricevendo ha iniziato, da qualche tempo, ad accompagnarsi con affermazioni tanto più generali quanto più discutibili circa le loro (vere o presunte) potenzialità teoriche ed applicative.
Di tutti gli equivoci che noto essere oramai in ampia circolazione, il più strategico, a mio avviso, è certamente quello che riguarda l’immutabilità del registro (una caratteristica che sarebbe offerta gratis dalla nuova tecnologia), che rappresenta, di fatto, l’architrave che da sola può reggere il peso della fattiva realizzabilità delle applicazioni immaginate ad ampio spettro nel pubblico e nel privato (dall’ambito legale, a quello medico o all’e-government, ad esempio).

Nello specifico, non credo di essere esattamente il solo a leggere in giro continuamente che la blockchain (il modello cui si ispirano altre DLT e spesso confusa con le DLT in genere) è come un libro mastro le cui scritture, una volta validate, risultano poi perfettamente immutabili.
In moltissime esposizioni, si trovano usate (parzialmente a sproposito, come vedremo più avanti nel dettaglio) espressioni incredibilmente forti ad indicare la non-falsificabilità (unfalsifiability) del registro, il suo essere inalterabile o a prova di danneggiamento (temper-proof), o a riguardo del fatto che possa consegnare “attività di certificazione al di là di ogni ragionevole dubbio” come si legge, ad esempio, in una recente review delle iniziative intraprese dal governo italiano in materia.

Di più, la supposta immutabilità della blockchain viene spesso divulgata come una motivazione distintiva per promuovere la nuova scelta tecnologica.
A leggere in giro, non si capisce davvero cosa mai abbia tenuto occupati gli informatici fino a non molto tempo fa, se solo si fosse davvero scoperta una maniera di gestire i dati che, pur operando in un ambienti potenzialmente ostili, ci metta tuttavia perfettamente al riparo da ogni alterazione non voluta degli stessi, permettendoci, naturalmente, allo stesso tempo, di aggiungere in tutta sicurezza le scritture valide.

Naturalmente non è così, nemmeno lontanamente; e questo è un caso evidente in cui la comunicazione informatica può generare mostri.
In moltissimi non hanno frequentazione con la matematica e l’informatica, ma non per questo possiamo raccontare loro uno stato delle cose a questo livello di inesattezza: è, prima di tutto, una questione di rispetto e di divulgazione consapevole; rapidamente, poi, finisce anche per diventare una questione di serietà comunicativa.

Ora, la blockchain e Bitcoin sono un’idea estremamente interessante (e che l’autore prende molto sul serio); e qui davvero non si tratta di rompere nessun ghiaccio, quanto di esporre di nuovo qualcosa di ampiamente già scritto e verificabile da chiunque: l’affermazione che la blockchain sia immutabile, così enunciata, è falsa.
E lo è tanto più se la blockchain viene considerata come un pezzo staccabile a piacere dai cryptoasset (ad esempio, da Bitcoin) con i quali è stata concepita, laddove blockchain e cryptoasset sono da considerarsi parte integrante di una stessa costruzione.
Di più, come in ogni accoppiata che si rispetti, si può discutere quali dei due sia più a servizio dell’altro, ma isolare le 2 componenti non è comunque da ritenersi una operazione facile o indolore.
Considerare la blockchain da sola, significa, nell’immediato, isolarla dal suo cryptoasset che serve innanzitutto a metterla in sicurezza.
Anzi, dal punto di visto economico, questa è probabilmente la più autentica sorgente di valore per il cryptoasset, che esibisce un valore intrinseco, proprio perché serve fondamentalmente a migliorare il livello di immutabilità del registro su cui opera.

Lo scopo di questa nota è di cercare di spiegare brevemente il motivo per cui la blockchain, da sola, non può garantire una perfetta immutabilità, esplorando, allo stesso tempo, cosa si può fare per aumentare il livello di immutabilità gestibile da una blockchain (un punto che non è così poi lontano, con ogni probabilità, dalle stesse motivazioni che hanno condotto alla creazione di Bitcoin come un cryptoasset registrato su blockchain).
L’esposizione parte illustrando l’immutabilità per registri distribuiti e decentralizzati, declinandola poi nel caso della blockchain, per arrivare poi a discutere l’importanza strategica dei cryptoassets (come Bitcoin) nel raggiungimento di un livello di immutabilità accettabile.
Inutile sottolineare quanto importante e decisivo può essere il livello di immutabilità che un registro può riuscire a raggiungere: gran parte delle applicazioni (se non tutte) più o meno immaginate ne dipendono in modo essenziale.

Da subito mi preme far notare che:

• stiamo naturalmente parlando delle blockchain propriamente dette, basate un un registro distribuito e decentralizzato (non importa se pubbliche o private, permissioned o meno); non stiamo parlando invece di costruzioni di blockchain nell’industria, dove il termine blockchain è usato principalmente per finalità di comunicazione, ma che funzionano secondo altri principi; è il caso, ad esempio, di Hyperledger Fabric, che risolve il suo consenso con Kafka: qui il registro è partizionato ma non è né distribuito né decentralizzato tra i partecipanti; questo, per inciso, non toglie informaticamente nulla alla soluzione (che può essere spesso anche preferibile in molti contesti), tuttavia, non può essere certamente assimilata sotto alcun aspetto ad una blockchain propriamente detta;
• il ragionamento esposto qui di seguito non è originale dell’autore ed è molto probabile che si possa ritrovare già esposto (anche in modo molto migliore, magari) nella letteratura informatica disponibile.
  Piuttosto, il mio contributo vuole focalizzarsi su una esposizione il più possibile piana ed elementare che permetta anche ai non informatici di farsi un’idea adeguatamente corretta su questo importante argomento.

Immutabilità per registri distribuiti e decentralizzati

Partiamo dalle parole; immutabile può utilmente significare: non più alterabile, non modificabile, che si conserva nel tempo sempre ben integro e riconoscibile come tale. La voce nel vocabolario Treccani commenta utilmente “detto in genere di cose astratte: … con i. affetto”, che è esattamente l’accezione del termine che si rivelerà utile.

Alterazioni e aggiunte Parleremo della (im)possibilità che un registro decentralizzato non subisca alterazioni alle sue scritture già convalidate (potendo subire, naturalmente, l’aggiunta di nuove scritture valide).
Di conseguenza, è utile distinguere fin d’ora le azioni sul registro che sostituiscono qualcosa di già scritto con altra scrittura (e parliamo, appunto, di alterazioni o modifiche) dalle azioni che aggiungono altre scritture al registro senza alterare alcuna delle scritture già presenti (e parliamo, magari, di aggiunte, append in inglese).
In particolare, useremo il termine alterazione per indicare una qualunque modifica ai dati, a prescindere dalla natura della stessa (se intenzionale o meno, autorizzata o meno; e parlare magari rispettivamente di degrado o di manomissione).

Scrivibilità Entrambe le azioni (di alterazione e di aggiunta) scrivono sul registro, che quindi, naturalmente, deve essere scrivibile. Non sembri ovvio quindi precisare che il problema dunque non è quello di garantire la non-modificabilità del registro attraverso la sua non-scrivibilità: ci serve un registro scrivibile per aggiunte valide, ma su cui non possa essere alterato ciò che è già stato scritto.

Soluzione software In ultimo, il punto di vista al quale lavoriamo è quello di una soluzione software, non hardware, ovvero, non cerchiamo una tecnologia che renda fisicamente impossibili riscritture (è interessante, ma è altro argomento).

In che senso un libro mastro può essere immutabile

Qui di seguito, libro mastro o registro (cfr. inglese ledger) sta ad indicare l’oggetto (il database) che raccoglie i dati che ci interessano.
E non dobbiamo necessariamente pensare ad un libro mastro informatico, anzi, può essere molto utile seguire il ragionamento pensando ad un libro mastro composto da comunissimi fogli di carta: per quanto concerne la nostra esposizione, l’unica differenza che intercorre tra la carta e un computer è che il contenuto scritto su carta risulta molto più difficile da alterare senza lasciare traccia (o, almeno, questo vale senz’altro per me).

Immutabilità in senso astratto Ora, vediamo prima in che senso una scrittura su un libro mastro potrebbe non essere più alterabile. Chiaramente questa affermazione non può avere un senso letterale, perché, naturalmente, non possiamo assumere che, qualunque sia la forma scelta per il libro mastro, esso non sia fisicamente alterabile (se non altro perché deve essere scrivibile). Chiarissimo per un libro mastro cartaceo, dobbiamo naturalmente assumere lo stesso per uno informatico (ipotizzare che i dati su un computer non vengano mai alterati sarebbe una assunzione assai imprudente, se non addirittura pericolosa).

Resta piuttosto da capire se e come sia possibile parlare di immutabilità del libro mastro o registro anche in presenza della possibilità che esso sia materialmente e fisicamente alterabile (sembra un controsenso, come tutte le buone idee, peraltro).

L’idea è che possiamo parlare molto meglio di immutabilità se vediamo le scritture che vorremmo immutabili in senso un po’ più astratto (come suggerito, appunto, dalla definizione da vocabolario), non legato alla loro concretezza fisica (inchiostro sulla carta o bytes su un supporto di storage di una qualche natura), ma al loro contenuto come insieme astratto di lettere o di bytes (nell’esempio cartaceo, stiamo affermando che non ci importa della grafia con la quale è stato scritto un certo contenuto ma solo del contenuto stesso).
Il concetto di decentralizzazione aiuta a rendere questa idea efficace.

Decentralizzazione e repliche

Come probabilmente già sapete, l’architettura di base per la blockchain prevede che il registro sia distribuito e decentralizzato su più nodi. Tuttavia, per ora, non pensiamo alla blockchain, pensiamo solo ad un libro mastro distribuito e decentralizzato, qualunque tipo di dati contenga e qualunque sia la loro organizzazione (per ora non importa che tenga i suoi dati organizzati in catene di blocchi oppure secondo altri criteri).

Distribuito e decentralizzato La prima e più fondamentale assunzione sul libro mastro è quindi di natura architetturale: che esso sia distribuito, perché replicato in più repliche, e decentralizzato, perché tutte le repliche hanno lo stesso ruolo: non c’è una replica master, prima inter pares, le repliche sono tutte pari (peers) tra loro. In conseguenza di questo, è estremamente importante osservare che, sotto questa assunzione:

il registro non esiste come oggetto singolo, ma solo come oggetto distribuito e decentralizzato, collezione di repliche tutte pari tra loro.

Se il libro mastro è cartaceo, della forma di un volume, si avrà quindi, ad esempio, una collezione di volumi distribuita in più biblioteche; nel caso informatico, il libro mastro sarà invece distribuito su un insieme di nodi, possibilmente anch’essi sparsi geograficamente.
E’ importante notare che:

• alle repliche non viene necessariamente chiesto di essere tutte identiche tra loro: vedremo questo in dettaglio più avanti; ma, nel seguire il ragionamento possiamo, all’inizio, benissimo assumere che si tratti di repliche tutte identiche tra loro;
• le repliche non sono copie di una stessa versione master del registro; del registro non esiste una master copy, un’originale, del registro esistono sono repliche (anche in questo caso, è comprensibile che, in questo momento, non si veda l’immediata utilità di un insieme di repliche non necessariamente identiche che non vengono da una unica copia master, ma tutto questo potrà essere più chiaro solo più avanti)
• stiamo parlando di oggetti distribuiti perché replicati, non di oggetti distribuiti perché suddivisi (ad esempio, si può distribuire un libro mastro su più volumi predisponendo un volume per lettera, esattamente come si usava fare anni fa per le enciclopedie: ecco questo non è l’oggetto distribuito di cui stiamo parlando; noi stiamo parlando di un’enciclopedia contenuta tutta in un volume, di cui consideriamo tante sue repliche)
• ogni replica del libro mastro è, possibilmente, sotto un diverso controllo e ogni replica subisce il suo controllo in modo possibilmente molto diverso (nel caso cartaceo, c’è chi lo terrà in cassaforte e chi sotto la pioggia; così come nel caso informatico, c’è chi lo conserverà in modo appropriato e sicuro, e chi meno)
• dobbiamo ammettere che le repliche siano tutte ispezionabili da parte dei loro rispettivi amministratori (se non altro perché sono questi ultimi ad avere il controllo sulle repliche)

L’importanza della decentralizzazione

Per questo paragrafo, partiamo dall’assunto che le repliche del registro (così distribuito) partano tutte identiche tra loro e vediamo come la tecnica di decentralizzare il registro in repliche tutte pari ci aiuta a formulare, da sola, un concetto di immutabilità un po’ più astratto (e quindi molto più concreto, sotto molti aspetti).

L’idea di base è che sia più facile salvaguardare l’immutabilità di un libro mastro che è distribuito e decentralizzato in più repliche, perché, se solo alcune (poche rispetto al totale) di queste repliche subissero delle alterazioni (non volute), allora potremmo usare le altre repliche per ripristinare i dati corretti laddove alterati.

Ora, non per sminuire l’idea, ma mi sembra un po’ eccessivo che qualcosa del genere non sia mai venuta in mente a nessuno nei secoli: se di un documento ne ho varie copie, per alterarlo ci vorrà un po’ di lavoro in più.
Per un libro mastro cartaceo, distribuirlo tra tante biblioteche nel mondo richiederà molto lavoro, ma ne sarà necessario almeno altrettanto, per provare ad alterarlo (nel senso di manometterlo), perché servirà di coordinare delle azioni di manomissione su più vasta scala.
Un libro mastro informatico, invece, si distribuisce in un attimo su una collezione di nodi anche geograficamente molto sparsa, tuttavia, parimenti, la tecnologia ci permette di scalare bene anche la quantità e la qualità delle possibili azioni di alterazione.
Abbiamo comunque l’intuizione che, se sono sempre pochi (rispetto al totale) le repliche che hanno subito una alterazione, allora possiamo sempre salvare l’immutabilità del libro mastro.

Ipotesi di alterazione perfetta Da osservare che stiamo lavorando nell’ipotesi che la manomissione (l’alterazione non voluta) sia perfetta, non individuabile di per sé, ma solamente per differenza di contenuto rispetto ad un altra copia (non manomessa o, magari, diversamente manomessa).
Non stiamo parlando di quanto sia ben imitata la grafia (nell’esempio cartaceo). Di conseguenza, sempre nella stessa ipotesi (pochi nodi ha subito una alterazione), possiamo notare che, prima ancora di poter eventualmente recuperare il contenuto corretto, possiamo sopratutto avere contezza che una qualche alterazione sia avvenuta e dove (perché abbiamo, appunto, molte altre repliche a riferimento).

Ora dobbiamo quindi capire come fare, specialmente se il libro mastro è informatico, a costruire un sistema in cui tutti i nodi che (ospitano le repliche) siano naturalmente disponibili ad accogliere aggiunte valide, ma, nel caso di alterazioni non volute, allora, al limite solamente pochi nodi possano essere attaccati con successo. Ma vediamo prima, su quanti nodi possiamo sopportare un attacco.

Immutabilità e maggioranza

Facciamo il caso in cui su uno o più nodi alcuni dati nelle repliche del libro mastro siano stati manomessi (una alterazione non voluta).
Nel caso in cui, ad esempio, il nostro ecosistema sia composto da 3 nodi (pochi, per ora, ma serve solo per illustrare il concetto), se 1 solo dei 3 nodi del sistema venisse manomesso, noi potremmo facilmente recuperare l’integrità originaria del libro mastro usando il fatto che esso è ancora conservato, identico, sugli altri 2 nodi. Possiamo senz’altro scoprire su quale nodo è avvenuta l’alterazione, se non altro perché possiamo identificare i 2 nodi che hanno una replica identica (tra loro) del libro mastro (di cui, ricordiamo, non esiste un originale).
Se, invece, i nodi manomessi fossero 2, ci troveremmo con un vero problema: non avremmo più nessun criterio elementare per capire quale siano i nodi manomessi. Di più, se 2 nodi fossero stati manomessi in modo da essere identici tra loro, proprio per quanto appena osservato, noi saremmo indotti a pensare che l’attacco sia avvenuto sul nodo rimanente che, quindi, sarebbe da noi probabilmente ‘corretto’ secondo le indicazioni degli altri 2. Un disastro.

Più in generale, se assumiamo che ad essere manomessi fossero una minoranza di nodi, potremmo ancora salvaguardare l’immutabilità del libro mastro, tenendo a riferimento le repliche conservate nella maggioranza dei nodi. Ragionando in modo simile, se troviamo repliche identiche (tra loro)su una maggioranza di nodi, e se assumiamo che la manomissione sia avvenuta su una minoranza di nodi, allora possiamo decretare che le repliche conservate sulla maggioranza dei nodi non sono manomesse.
E se non sappiamo nulla sulla quantità di nodi manomessi, se non possiamo assumere che siano una minoranza ? Come facciamo a sapere quali nodi conterranno una replica non manomessa del registro ? Qui il problema non è facile e non abbiamo, apparentemente, nessun criterio. Tuttavia, da questo breve ragionamento emerge che:

una forma conveniente di immutabilità, impossibile da ottenere letteralmente e fisicamente per ogni singola specifica replica, risulta così raggiungile da una architettura distribuita e decentralizzata, sotto la (per nulla ovvia) ipotesi che sia sempre una minoranza di nodi a subire attacchi di manomissione.

Specificatamente, immutabilità viene ora a significare che il contenuto in dati può essere salvato, reso, appunto, immutabile (ovvero, reso non mutabile nel tempo) anche se le specifiche repliche potrebbero, nel tempo, subire attacchi di alterazione, che verrebbero però corretti in tempo utile sempre che non venga attaccata una maggioranza di nodi su una scala temporale in cui l’azione di correzione non sia effettuabile.

Anche se non abbiamo ancora parlato di blockchain, possiamo comunque già arrivare ad un punto importante: che la nozione di maggioranza (o, più precisamente, il consenso che da essa ne esce formato: in questo caso dell’identità tra le repliche) sembra avere un ruolo di primo piano in questo discorso sull’immutabilità.
La maggioranza forma un consenso in quanto, se le repliche si possono riconoscere identiche tra loro, il loro consenso identifica il contenuto dati che vogliamo riconoscere come valido.

Immutabilità e onestà comportamentale

In quanto finora svolto, abbiamo immaginato un attacco di alterazione ai nodi del nostro registro. Ma il ragionamento può essere svolto in modo del tutto analogo se, invece, si ipotizza un comportamento non onesto da parte di 1 o più nodi (che, ricordiamo, sono sotto il controllo di diversi proprietari e possono manifestare gestioni anche molto diverse tra loro).
Anche senza subire un attacco, un nodo potrebbe volere alterare volontariamente il contenuto in dati della sua replica o un gruppo di nodi (magari sotto uno stesso gestore o all’interno di un cartello di gestori) potrebbero accordarsi per alterare, anche ripetutamente nel tempo, le loro repliche.

Onestà della maggioranza Le conclusioni sull’importanza della maggioranza a garanzia dell’immutabilità del contenuto del registro (non delle sue singole repliche) restano comunque immutate.
Potreste quindi uscirne molto rassicurati se credete che, in un sistema composto da moltissimi nodi (anche fortemente differenziati), la maggioranza di essi si comporterà sempre e comunque in modo onesto.
Se invece, al contrario, siete dello stesso parere di Biante di Priene (il saggio che scrisse Οἱ πλεῖστοι κακοί la maggioranza è cattiva all’entrata dell’Oracolo di Delfi), probabilmente non ne uscirete con lo stesso livello di conforto.

Onestà di un software Ma perché, sopratutto nel caso informatico, ha senso ipotizzare comportamenti disonesti da parte, addirittura, di una maggioranza dei nodi partecipanti al sistema del registro ? Per provare a rispondere bisogna almeno tenere presente che:

• i nodi, per fare il loro lavoro, sono equipaggiati di un software che, in linea di principio, può essere stato sviluppato in maniera del tutto indipendente (sia per comportarsi in modo corretto, secondo le specifiche, sia per deviare consapevolmente dalle specifiche), ma che più spesso è basato su un stesso software che, di conseguenza, correla il comportamento dei nodi nel bene e nel male (ad esempio, nel caso del network di Bitcoin, gran parte dei nodi girano lo stesso software; cfr., ad esempio, qui https://coin.dance/nodes)
• più spesso, i vari nodi hanno utilizzato parti comuni nel loro software in uso, usualmente sviluppate da terze parti o comunque non completamente sotto il loro controllo; non è impossibile che alcune parti comuni (spesso molto di base) possano agire come iniettori di correlazione, azionando, in situazioni particolari, comportamenti non previsti (più o meno indotti volontariamente) e di impatto simile su molti nodi contemporaneamente;
• anche il software sviluppato (il più rigidamente possibile) in modo da comportarsi secondo le specifiche del registro può contenere (o, meglio, conterrà certamente) bug più o meno latenti al suo interno o può essere oggetto essere stesso di un attacco di manomissione; il fatto che dei nodi possano alterare il comportamento di altri (via generici malware) è uno dei fattori da tenere presente nell’ecosistema.

Di conseguenza, ipotizzare comportamenti disonesti (o comunque fuori dalle specifiche di funzionamento del registro) è, più che doveroso, inevitabile.
Non importa, a questo livello, se stiamo pensando ad un registro distribuito e decentralizzato totalmente pubblico (e così partecipabile da chiunque) o ad un registro che accetti solo partecipazioni autorizzate o ad un registro completamento privato sotto il controllo di una singola entità.
L’onestà comportamentale dei singoli nodi partecipanti dipende dal software in uso almeno quanto dalle intenzioni del gestore. Quindi, certamente la possibilità (o meno) di esercitare una qualche forma di controllo sui nodi, può certamente aiutare a calmierare i rischi menzionati qui sopra, ma non ad escluderli.

Validazione delle nuove scritture

Abbiamo appena visto come un registro distribuito e decentralizzato possa difendere l’immutabilità dei suoi dati nel caso in cui (al più) una minoranza dei suoi nodi si comporti in modo disonesto (o sia indotta a farlo, perché attaccata).
Il discorso fatto vale tuttavia anche (e sopratutto) per la gestione delle attività attese del registro: abbiamo voglia che il registro funzioni bene ed accolga nuove scritture su di esso e abbiamo necessità che queste nuove scritture siano validate e rese quindi permanenti (il più possibile).

Scrivere su il registro Ma come si scrive su un registro distribuito e decentralizzato su più repliche ? Se il registro fosse concentrato in un solo volume fisico, oppure in un solo nodo, sarebbe naturalmente sufficiente aggiungere la nuova scrittura nella copia originale del registro. Ma essendo molto conveniente, come abbiamo appena visto, tenere il registro distribuito e decentralizzato su più repliche, vale la pena di seguire questa impostazione, così, per scriverlo, dovremmo immaginare di scrivere su tutte le repliche.

Nessun meccanismo esogeno Per farlo potremmo invocare un meccanismo esterno al registro, che ha l’autorità di aggiungere nuove scritture a tutte le repliche del registro; tuttavia, operando in questo modo, distruggeremmo l’autarchia della rete di nodi che partecipa al registro, introducendo un nodo non pari con gli altri, oppure, peggio, non endogeno al sistema dei pari.
Uno principi della blockchain vuole che il sistema dei partecipanti resti un sistema di peers e che le tutte scritture siano verificabili da ciascun partecipante, indipendentemente.

Proposte di scrittura Di conseguenza, anche le operazioni che aggiungono nuove scritture al registro non possono che essere gestite se non dalla stessa rete di nodi partecipante al registro stesso.
Così, si può immaginare che da un nodo parta l’iniziativa di proposta per una nuova scrittura, che il nodo proponente ritiene valida, e che questa proposta di scrittura percoli attraverso la rete dei peers in modo da raggiungere tutti gli altri nodi, che a loro volta possono (e debbono) validare il contenuto della proposta e aggiungerla alla loro replica.

Questa idea può funzionare molto bene (vedremo poco più avanti nel caso della blockchain di Bitcoin come, di fatto, questa idea funziona), ma, vedete immediatamente che può essere essa stessa l’obiettivo delle stesse identiche osservazioni fatte finora.
Dobbiamo avere fiducia che il nodo proponente faccia una proposta valida e che questa proposta si propaghi (inalterata) davvero a tutti i nodi e che questi la processino in tutta onestà di comportamento e secondo le specifiche del registro. Ma, in questo caso, c’è anche dell’altro.
C’è la concreta possibilità che più nodi facciano contemporaneamente proposte tutte valide se considerate singolarmente, ma possibilmente non più tali se considerate nell’insieme, ovvero, svolte secondo un ordine qualsiasi.

Validazione e correzione Inoltre, se ci concentriamo sul lavoro di convalida dei nodi (quello già evidenziato quando poco sopra abbiamo immaginato attacchi o comportamenti disonesti), è naturalmente necessario che i nodi stessi gestiscano il lavoro di discovery di eventuali disallineamenti tra le repliche e ogni conseguente correzione di quest’ultime (riallineando la replica che contiene le alterazioni non valide con la replica presente nei nodi onesti o non attaccati).

Tempo Questa azione è esplicitamente volta a contrastare mutazioni non validate del registro e, anch’essa, non può che essere svolta dagli stessi nodi che partecipano al registro distribuito e decentralizzato.
Naturalmente, questa azione richiede tempo (instrinsecamente) ed è per questo che non può servire a contrastare un ipotetico comportamento collettivo simultaneo di una maggioranza di nodi.
Il tempo è una componente essenziale nella gestione dei registri distribuiti e decentralizzati e lo si vede meglio nella blockchain, dove il mining dei blocchi (che è il lavoro continuo necessario a mettere la rete nella migliore condizione di sicurezza possibile) scandisce il vero tempo di sistema.

Numeri Abbiamo evidenziato come una maggioranza di nodi in un registro può essere a guarda della sua immutabilità; proprio per questo bisogna fare caso ai numeri: ad esempio, ad oggi, il network di Bitcoin è composto da circa 10000 nodi (cfr. su https://bitnodes.earn.com/). Il registro quindi è molto decentralizzato (questo è il numero dei nodi che hanno una replica della blockchain, non il numero dei miners, che vedremo più avanti).
Avere un’idea di questo numero serve ora sola a rendersi conto che questo tipo di impostazione (registro distribuito e decentralizzato) non è necessariamente interessante a qualunque scala: nel caso di poche decine di nodi, i rischi di instabilità del sistema sono naturalmente maggiori.

La seconda parte di questo articolo continuerà il discorso esaminando più da vicino il caso della blockchain e, dalla necessità del lavoro di mining (che verrà lì spiegato), proverà a trarre delle osservazioni sul livello di immutabilità che può essere raggiunto in una blockchain e sulla opportunità (e, forse, a ben vedere, necessità) dell’esistenza di un cryptoasset associato alla blockchain.

Segue qui con la seconda parte.

Marcello Paris is currently at UniCredit, R&D dept.
email: marcello.paris@gmail.com
LinkedIn: https://www.linkedin.com/in/marcelloparis/
Twitter: https://twitter.com/marcellop71

Disclaimer The content of this article is solely the responsibility of the author.
The views expressed here are those of the author and strictly personal,
and do not necessarily reflect in any way the views of the UniCredit Group.