di Chiara D’Elia
Dal registro centralizzato a quello distribuito
Prima dell’avvento della blockchain, in relazione ai sistemi che già consentivano lo scambio di transazioni e informazioni, era prevalente il concetto di logica centralizzata.
Il centralized ledger (registro centralizzato) si basa su una logica e un rapporto rigorosamente centralizzati secondo lo schema uno-a-molti[1], ed ha come caratteristica fondamentale la presenza di una entità centrale – organizzazione o soggetto che sia – cui è attribuita la gestione del sistema e delle regole di accesso e verso cui è riposta la fiducia della comunità di riferimento, trattandosi di registri che rimangono chiusi e riservati rispetto a chi non è autorizzato a parteciparvi e/o ad utilizzarli. Dunque, c’era qualcuno che si occupava del data entry che nascevano come analogici, c’era qualcuno che gestiva i sistemi e c’era qualcuno che, centralmente, gestiva le estrazioni dei dati o la loro elaborazione. In questa lunghissima e importantissima fase dell’informatizzazione la digitalizzazione non ha cambiato i processi, ha velocizzato alcuni passaggi e ha semplificato determinati controlli e verifiche. Ma il dato ha continuato ad essere concepito come analogico e gestito con un paradigma di tipo analogico, anche se con strumenti digitali[2].
Al contrario, con il concetto di decentralized ledger si assiste a un fenomeno di decentralizzazione dell’informazione: essa non è più custodita da un’unica unità centrale, ma si sposta nelle periferie che assumono sempre più rilevanza nella transazione. Il registro decentralizzato ripropone la stessa logica della centralizzazione a livello locale con “satelliti” organizzati nella struttura uno-a-molti, che si relazionano a loro volta in una forma che ripete il modello uno-a-tanti. Anziché una grande unità centrale ne esistono molteplici di tal fatta, poiché la gestione e la fiducia si riferiscono ancora una volta ad un centro logicamente e localmente più prossimo ma ad ogni modo rispondente ad un criterio centralizzato, mentre le organizzazioni che si rifanno a questo genere di ledger definiscono una governance che stabilisce delle forme di coordinamento di tipo centralizzato[3]. In questo modello il codice[4] viene eseguito su una rete peer-to-peer di nodi e nessun singolo nodo ha il controllo sulla DApp[5].
La vera innovazione, però, è rappresentata dal passaggio al concetto di distributed ledger ovvero da un reale e completo criterio distribuito dove non esiste più nessun centro e dove la logica di governance è costruita attorno ad un nuovo concetto di fiducia tra tutti i soggetti. Nessuno (ma proprio nessuno) ha la possibilità di prevalere poiché il processo decisionale passa rigorosamente attraverso la costruzione del consenso tra tutti i partecipanti, ognuno dei quali ha le stesse informazioni degli altri. L’unico modo per prevalere sarebbe quindi operare sul meccanismo del consenso. L’immodificabilità deve essere intesa, infatti, da un punto di vista unilaterale (un singolo da solo non può modificare i dati), ma non è una caratteristica valida in assoluto: laddove si pervenisse a un controllo sulla maggioranza del consenso l’intervento diventerebbe possibile.
Appare evidente come con i registri distribuiti e condivisi si superi la necessità di ricorrere a queste autorità centrali, deputate ad attività di controllo e approvazione. Gli utenti di Internet possono agire come intermediari collettivi, amministrando i propri affari attraverso un database decentralizzato, condiviso e un software[6] automatizzato in un nuovo ecosistema digitale[7].
La decentralizzazione non è solo una conseguenza della scelta di una architettura di rete, ma ha anche risvolti filosofici ed economici importantissimi. L’assenza di un centro e una gerarchia fluida corrispondono ad una governance democratica proprio perché non c’è un consiglio di amministrazione, una banca o una istituzione, ma regole matematiche che attraverso la teoria dei giochi[8] concertano le aspettative di tutti gli attori che democraticamente sono chiamati a scegliere evoluzioni della blockchain esprimendo il 51% delle preferenze. La questione interessante è che la minoranza può abbandonare la scelta della maggioranza dividendo – con un intervento definito fork[9] – la blockchain in un nuovo progetto.
Chiaramente il passaggio dalle prime forme di registri digitali alle Distribuited Ledger Technology (d’ora in avanti DLT) è dovuto all’innovazione tecnologica che ha reso disponibili due fattori abilitanti: la crittografia e lo sviluppo di algoritmi di controllo e verifica di dati[10]. È solamente con le DLT infatti che si comincia a parlare di database distribuiti e condivisi: questi attributi si riferiscono al fatto che i database sono presenti contemporaneamente su molteplici device, ognuno dei quali è perfettamente sincronizzato sui medesimi documenti.
Le DLT prevedono pertanto un meccanismo di validazione[11] a sua volta distribuito basato sul concetto di consenso, vale a dire su meccanismi che governano anche questo tipo di partecipazione dei nodi. Le modalità di gestione del consenso, congiuntamente alle logiche di impostazione del registro, rappresentano due fra i principali punti qualificanti della carta d’identità delle tecnologie Distribuited Ledger. Ed è all’interno di questo insieme che trovano la loro collocazione le blockchain.
[1] Nell’analisi dei sistemi, una relazione uno-a-molti è un tipo di cardinalità che si riferisce alla relazione tra due entità A e B in cui un elemento di A può essere collegato a molti elementi di B, ma un membro di B è collegato a solo un elemento di A.
[2] Si pensi alla ferrea logica che impone per la maggioranza dei documenti che punteggiano la nostra vita personale e professionale alla necessità di una firma cartacea e di un controllo fisico e personale da parte di amministrazioni o di imprese.
[3] Ad oggi pare essere questa la dimensione di blockchain su cui si sta concentrando maggiormente il business.
[4] Il codice, più precisamente codice sorgente, in informatica, è il testo di un algoritmo di un programma scritto in un linguaggio di programmazione da parte di un programmatore in fase di programmazione, compreso all’interno di un file sorgente, che definisce il flusso di esecuzione del programma stesso, ovvero la sua codifica software.
[5] Le DApp, letteralmente decentralized applications, sono applicazioni simili alle app tradizionali, con la fondamentale differenza che al posto di appoggiarsi su server centralizzati sfruttano le piattaforme blockchain e il loro network distribuito. Le app tradizionali sono molto dipendenti da marketplace centralizzati a cui gli sviluppatori devono pagare fee elevate, soprattutto se vogliono utilizzare pagamenti in-app. Le DApp invece, sfruttando le funzionalità di pagamento già integrate nella blockchain, possono funzionare indipendentemente da marketplace centralizzati. Un’ulteriore peculiarità delle DApp è la gestione dei dati: una app tradizionale richiede i dati dell’utente per poter accedere ai servizi stessa (poi gestiti in un database centralizzato in mano allo sviluppatore della app stessa), nelle DApp l’utente utilizza il proprio “account” blockchain, ossia le proprie chiavi crittografiche, evitando così di esplicitare i propri dati personali. Le DApp presentano, quindi, alcuni vantaggi che possono potenzialmente risolvere alcuni problemi delle applicazioni centralizzate: sono resistenti, non esiste un single point of failure; sono immutabili, nessuno può modificare quello che avviene tramite l’applicazione; gli asset o le informazioni personali possono essere totalmente di proprietà degli utenti. Sfruttando queste caratteristiche, le opportunità di sviluppo sono molteplici. Alcuni esempi potrebbero essere: siti di informazione resistenti alla censura, social network in cui i dati non possano essere censurati e rimangano di proprietà degli utenti, piattaforme per la registrazione di copyright e proprietà di asset digitali o anche app di messaggistica decentralizzate..
[6] Software, traducibile come componente logico, programma informatico o supporto logico, in informatica ed elettronica è l’insieme delle componenti immateriali di un sistema elettronico di elaborazione.
[7] Inteso come ambiente informatico de-materializzato nel quale una data comunità opera ed interagisce.
[8] La Teoria dei Giochi è la disciplina che studia il comportamento di soggetti diversi con interessi diversi e con asimmetrie informative, per far sì che gli attori ottengano il massimo del guadagno e siano disincentivati a comportarsi scorrettamente.
[9] Una fork di una blockchain è un aggiornamento del software concordato collettivamente. Quando una parte della community è irremovibile su un particolare cambiamento di software, ma il resto del gruppo non è d’accordo, può decidere di seguire la propria strada. Quando ciò accade, avviene una fork. La catena si duplica e si divide, e le due comunità vanno per strade separate nell’implementazione delle loro soluzioni progettuali. In base alla natura della decisione presa, una fork può essere definito hard fork o soft fork. Una hard fork avviene quando la nuova soluzione proposta è incompatibile con la versione precedente del software. Il cambiamento è irreversibile. Di solito si tratta di un cambiamento radicale del protocollo di un network che rende validi i blocchi e le transazioni precedentemente non validi, o viceversa. In una hard fork, tutti i nodi o gli utenti devono aggiornare l’ultima versione del software del protocollo. Nell’altra tipologia di fork, la community decide all’unanimità di aggiornare il software. In questo caso, l’aggiornamento è compatibile con la vecchia versione e, per questo, prende il nome di soft fork.
[10] Tuttavia non si tratta di due fattori sconosciuto alla comunità scientifica: il punto è che grazie al progresso e all’evoluzione della tecnologia si è potuto passare dalla teoria alla pratica. Prima di allora non mancavano le idee e le soluzioni per fare questo salto verso una digitalizzazione nativa dei processi di accounting e di gestione dei Ledger, bensì mancavano soluzioni in grado di garantire alti livelli di sicurezza e modelli che permettessero di superare la rigida e tradizionale logica centralizzata.
[11] La validazione è un’attività di controllo mirata a confrontare il risultato di una fase del processo di sviluppo con i requisiti del prodotto – tipicamente con quanto stabilito dal contratto o, meglio, dal documento di analisi dei requisiti. Un comune esempio di validazione è il controllo che il prodotto finito abbia funzionalità e prestazioni conformi con quelle stabilite all’inizio del processo di sviluppo.