Introduzione

Continuiamo a parlare di Blockchain intervallando gli articoli di Matteo Baccan con questa riflessione che riprende il filo — o meglio, visto l’argomento, “la catena” — del discorso introdotto nel primo articolo [1] di questa serie.

In quelle pagine, avevo voluto fare un’introduzione di base sulla tecnologia e differenziare tra Blockchain pubblico e privato. Questa volta la mia digressione andrà sull’adozione di Blockchain all’interno di un progetto.

Riassumiamo brevemente le caratteristiche della tecnologia che ci interessano in questo contesto:

• il suo funzionamento è consolidato;
• è un database distribuito su ogni nodo;
• è in sola modalità “append”;
• non possono essere eliminati i dati:
• pubblico (non permissioned) o privato (permissioned).

Nell’affrontare un progetto che intenda utilizzare questa tecnologia è bene tenere presenti le caratteristiche di cui sopra per determinare se e quale tecnologia utilizzare.

Ha senso utilizzare la tecnologia?

Recentemente con alcune persone, tra colleghi ed esperti di PKI, mi sono imbattuto in discussioni relativa al fatto di utilizzare la tecnologia Blockchain, sia essa pubblica o privata, all’interno delle applicazioni “corporate”.

I punti che più tipicamente vengono messi in evidenza sono:

• la Blockchain privata non ha senso, perché sono pochi i nodi;
• si potrebbe risolvere il problema con un database distribuito o un web service;
• se si usa la Blockchain per fare “timestamp”, è possibile aggregare più transazioni insieme e salvarle in una Blockchain pubblica;
• si può risolvere il problema della firma digitale usando soluzioni PKI o PGP.

La domanda sostanziale quindi diventa: “Ha senso utilizzare la tecnologia blockchain per un progetto?”.

La risposta è difficile da determinare, perché lo hype che gira attorno alla tecnologia è tale da offuscare il buon senso e la capacità di raziocinio. Pur da sostenitore del valore della Blockchain, in 8 casi su 10 mi sono trovato a dover dimostrare per quale ragione non avesse senso utilizzare la tecnologia in un progetto. Ma questa volta mi concentrerò sulle ragioni che mi hanno portato a far partire gli altri due.

Primo fattore: tipologia di dato

Il primo elemento su cui fare un’analisi è il fatto di avere un sistema in cui i dati salvati non possono essere cambiati nel tempo: una volta salvati, non possono essere eliminati, e diventano quindi in un modo o nell’altro, accessibili.

Questo rende l’applicazione potenzialmente fallimentare in alcune circostanze, poiché salvare i dati e non poterli eliminare potrebbe essere inapplicabile. Per esempio, salvare a tempo indeterminato indirizzi e-mail o informazioni anagrafiche non sarebbe possibile nel 99% dei casi.

Determinare cosa vada all’interno di un database basato su blockchain diventa quindi un fattore fondamentale per l’adottabilità della soluzione. Gli esempi più tipici di dati che possono essere salvati all’interno di un database basato su blockchain comprendono:

• hash;
• movimenti di asset (più tipicamente criptovalute);
• stringhe di testo (solo blockchain private);
• transazioni verso Smart Contract.

Hash

In particolare, la questione più discussa nella mia esperienza è quella degli hash, ossia salvare all’interno di una Blockchain una stringa alfanumerica o binaria — tipo uno sha256 [2] — con il fine di “marcatura temporale” di un dato o un gruppo di dati.

Un esempio di questa funzionalità potrebbe essere un flusso del tipo:

1. creo un file (per esempio un file di log di sistema);
2. genero uno sha256 del file;
3. salvo lo sha256 all’interno di una blockchain pubblica.

Dentro la blockchain avremo una serie di transazioni, all’interno delle quali troveremo un elenco di hash anonimi, privi di riferimento se non quello della data. Avendo il file originale in mano, è possibile risalire allo hash; ma dallo hash non è possibile risalire nemmeno al nome del file originale o capire su quale sistema sia stato originato.

Se il numero di transazioni è elevato, il problema che si potrebbe porre è quello della capacità massima della rete. La soluzione in questo caso diventa più complicata concettualmente:

1. per ogni file ho un hash;
2. una volta al giorno creo un hash degli hash concatenati;
3. salvo il risultato in blockchain.

In questo caso l’idea di marcatura temporale viene meno in quanto l’unico riferimento orario disponibile è quello della transazione in cui ho salvato le informazioni aggregate. Sempre in questo caso, la riconducibilità al dato originale è ancora più complessa, se non impossibile in caso di condizioni particolari: per esempio, se perdo l’archivio con le associazioni dei gruppi di hash.

Il valore della marcatura temporale

Il principio dietro al quale si utilizza un sistema di marcatura temporale, è quello di poter dimostrare la data di esecuzione di un’operazione, in questo caso di aver creato un file di log. La motivazione che spinge l’adozione di un tale sistema è quella di dare una sostanza “legale” al dato [3], quindi deve essere verificabile anche da una terza parte, che potrebbe non avere la competenza per comprendere in modo approfondito i tecnicismi dei sistemi di hashing.

Ne consegue che la presenza di un hash privo di associazioni o, peggio, dello “hash di un aggregato di hash” — è persino un delirio il modo in cui chiamarlo… — sia difficilmente sostenibile in sede legale.

La soluzione potrebbe essere, per esempio, salvare una stringa di informazioni più articolate, magari inserendo il nome del file e/o del sistema che lo ha generato. In questo modo, il payload diventa più lungo — con un “costo” di transazione maggiore in un blockchain pubblico — ma assume comunque un significato più intelligibile.

Secondo fattore: distribuzione

Il bello dei sistemi distribuiti è che permettono di avere una resilienza enorme in caso di guasto o problema. Questa è forse la funzionalità più facile da descrivere e comprendere.

Se uno dei “nodi” dovesse venire a mancare per un guasto o malfunzionamento, è possibile continuare a operare utilizzando quelli rimasti. Di fatto, si tratta di una soluzione di “alta affidabilità” intrinseca nel sistema.

Parlando di blockchain privata, è possibile avere più nodi in replica, ovviamente, tra di loro che operano indipendentemente ma che replicano tra di loro tutti i dati. Supponiamo — seguendo gli esempi precedenti — che un’azienda abbia più sedi sul territorio; ogni sede potrebbe avere un nodo blockchain all’interno del quale vengono salvati gli hash — e nomi di log e sistemi! — dei file di log dei sistemi più critici. In caso di guasto di uno dei nodi blockchain, le operazioni potrebbero continuare grazie alla presenza degli altri.

Terzo fattore: fiducia

Quello della fiducia è decisamente l’aspetto più difficile da spiegare e comprendere, e si potrebbe persino dire che trascende la tecnologia per essere una questione più “filosofica”.

Riprendendo il whitepaper originale di Satoshi Nakamoto, la tecnologia blockchain è nata per risolvere un problema di fiducia nei sistemi bancari, decentralizzando la gestione degli account (conti correnti). A questo punto non ci sarebbe più stato solo un singolo intermediario a gestire le transazioni, ma lo avrebbero fatto sostanzialmente tutti grazie al sistema di “consenso”.

La tecnologia blockchain in ambito corporate ha senso, a mio avviso, in due casi di implementazione:

1. di un sistema che offra un certo livello di “trasparenza” sulle operazioni;
2. di un meccanismo di scambio di informazioni tra più parti.

Il primo esempio potrebbe essere quello di avere un sistema solido e trasparente per la gestione del credito di un account. Di fatto una funzionalità nativa nel sistema blockchain (il Bitcoin) che permette di tracciare in modo affidabile il bilancio di un account (wallet) e le operazioni che vengono eseguite su di esso. Il risultato è quello di poter dare sempre la trasparenza in ogni momento sulle operazioni eseguite su un determinato account.

Nel secondo caso, invece, potrebbero essere coinvolte più parti (aziende) che utilizzano il sistema blockchain per scambiare informazioni in modo trasparente e non alterabile. Per esempio,

• un produttore di apparecchiature potrebbe inserire nel sistema i numeri di serie dei propri prodotti (asset);
• il distributore riceve i prodotti e aggiorna le informazioni sul magazzino;
• il rivenditore vende i prodotti e aggiorna le informazioni sulla data di vendita;
• il cliente finale può chiedere a chiunque — anche a un altro rivenditore — la validità della garanzia del prodotto, sulla base dei dati salvati di volta in volta nella blockchain.

In questo caso, concettualmente solo il produttore può creare un nuovo prodotto; tuttavia l’intero “ecosistema” ha i dati necessari per gestire i prodotti sul mercato.

Conclusione

Il paradigma dei sistemi basati su tecnologia blockchain è quello di togliere i dati da un singolo punto di riferimento e darli a tutte le porzioni coinvolte. La domanda “perché dovrei dare i miei dati a qualcun altro?” è più che legittima, tuttavia lo scambio di dati è alla base del funzionamento del blockchain.

Del resto, ogni nodo di un blockchain pubblico, a bordo del proprio dispositivo, ha una copia intera di tutti i dati, ossia lo stato di tutti gli account dell’intera rete. In pratica è come se tutti avessero una copia aggiornata dello stato dei conti correnti in una singola valuta.

Come descritto nei punti precedenti, è una questione di fiducia e trasparenza: sia essa nei confronti degli utenti finali (consumatori) per gestire i servizi o ricevere su di essi, sia essa tra attori diversi, per una gestione controllata del rischio di contraffazione dei dati, il punto fondamentale attorno alla blockchain rischia di essere confuso: non è un fattore meramente tecnologico.

È un fattore di fiducia. Nella tecnologia.