DLT e Applicazioni Industriali

Sono passati ormai più di dodici anni dall’attivazione di Bitcoin, la prima rete decentralizzata in grado di gestire transazioni economiche. 

Il progetto più noto, nato con questo obiettivo, è Ethereum. Il team che ha lanciato Ethereum affermava (e continua tutt’ora) che non solo la loro rete è più veloce di Bitcoin, ma è anche in grado di eseguire programmi in modo decentralizzato. Questi programmi sono noti con la definizione di Smartcontract. 

Gli Smartcontract effettivamente rivestono un ruolo importante nella potenziale adozione di una blockchain/DTL in ambito industriale: Bitcoin, nonostante l’enorme capitalizzazione, fornisce esclusivamente il servizio di spostamento di token tra indirizzi, mentre grazie agli smartcontract Ethereum fornisce anche un servizio decentralizzato di elaborazione dati.  

Poter inviare valore in modo sicuro con la stessa facilità con si manda una email è un servizio importantissimo per l’adozione in ambito industriale, ma potervi associare dei dati e rendere la rete capace di reagire a questi dati è decisamente ancora più utile. 

I limiti delle blockchain 
Purtroppo non ci è voluto molto per scoprire che le interessanti capacità di Ethereum sono insufficienti per gestire le richieste di un immenso mercato di utenti. Se Ethereum fornisse un adeguato livello di servizio ogni applicazione che oggi è progettata in modo classico, sarebbe già stata riprogettata e migrata su Ethereum. Ma non è così. 

Ethereum infatti è più veloce di Bitcoin ma non così veloce da poter gestire le richieste di milioni di utenti.  

Per quanto riguarda gli Smartcontract, segnalo una problematica ampiamente sottovalutata. Uno smartcontract può registrare un dato generico che può rappresentare un oggetto digitale, come ad esempio nel caso degli NFT. A differenza di quanto comunemente ritenuto, questa operazione non ottiene dalla rete lo stesso livello di servizio di un token. La creazione (mining) o lo spostamento di un token sono convalidati dall’intera rete che impedisce la creazione impropria di token e la doppia spesa.

Lo Smartcontract invece è specificatamente progettato per creare e registrare dati astratti, come un NFT, su cui la rete non può applicare alcuna logica di validazione. La rete pertanto si limita a notarizzare l’avvenuta esecuzione dello smartcontract e i suoi effetti. In pratica, se c’è un errore nello smartcontract e invece di un NFT ne vengono creati cinque, la rete non può farci nulla. 

C’è poi un ulteriore problema. Una delle caratteristiche fondamentali richiesta a qualsiasi componente che viene scelto per costruire un servizio o un prodotto complesso è avere un comportamento prevedibile. Ad esempio un attuatore ripeterà sempre lo stesso movimento ogni volta che riceverà lo stesso comando. Un computer impiegherà sempre lo stesso tempo ad eseguire un certo algoritmo, ecc. ecc. 

Le blockchain, da Bitcoin in poi senza eccezioni, hanno invece una caratteristica funzionale che produce una imprevedibilità: costo delle fee e il tempo di immissione nel registro di una transazione, sono variabili. 

In realtà questi due parametri sono legati tra loro ed essenzialmente implicano che non è possibile ottenere dalla rete decentralizzata un Service Level Agreement che supporti e garantisca le prestazioni un sistema costruito sulla blockchain. 

Questa limitazione deriva da una scelta architetturale definita dai progettisti di Bitcoin che tutti i progetti derivati hanno mantenuto: il sistema è sincrono. La sincronicità della rete che gestisce la blockchain è un modo per semplificare la realizzazione di varie componenti funzionali della rete. 

In primo luogo la creazione dei blocchi con una cadenza costante e limitata, ovvero sincrona, permette un’ampia partecipazione di nodi. Infatti, se la frequenza di produzione dei blocchi fosse elevata i requisiti computazionali dei nodi crescerebbero riducendone il numero in grado di partecipare attivamente alla gestione della blockchain. Una frequenza più elevata e maggiore dimensione dei blocchi, permetterebbero alla rete di produrre maggiori prestazioni (più transazioni per blocco ), ma ciò porterebbe all’aumento dello spazio disco necessario per conservare il registro sul nodo.  

E’ inoltre necessario che i nodi che gestiscono una blockchain siano sincronizzati anche per riuscire a validare i nuovi blocchi. Infatti quando un blocco viene pubblicato gli altri nodi lo possono convalidare rapidamente solo se hanno già ricevuto le transazioni che contiene e le hanno prevaliate.  

Infine è necessario che la frequenza di produzione di blocchi sia sincrona e quindi limitata per permettere una competizione tra i miners che creano i nuovi blocchi. Se infatti la frequenza fosse molto elevata pochi nodi avrebbero le risorse computazionali per creare un blocco valido con elevata frequenza.  

Quindi, per una blockchain la sincronizzazione dei nodi e una limitazione prestazionale sono requisiti funzionali senza i quali si possono concretizzare rischi di sicurezza limitabili solo con forme di centralizzazione. 

La sincronizzazione produce poi un effetto secondario che è quello da cui deriva il problema dell’indeterminatezza delle prestazioni percepite: gli utenti sono in competizione tra loro. 

Infatti, se un blocco può contenere un numero limitato di transazioni e i blocchi vengono prodotti con cadenza regolare indipendentemente dalla quantità di transazioni immesse in rete dagli utenti, si può formare una coda transazioni in attesa di essere selezionate dai miners e inserite in un blocco. I miners dovrebbero scegliere le transazioni da inserire in un blocco in ordine di arrivo tuttavia, visto che le fee costituiscono parte della remunerazione, sono incentivati a privilegiare le transazioni che pagano più. Gli utenti sono quindi indotti a pagare più fee per avere migliori prestazioni. In casi estremi una transazione che non paga sufficienti fee potrebbe rimanere in coda anche per giorni. 

Ovviamente tutto ciò non è stato deciso per caso. I progettisti di Bitcoin sapevano benissimo gli effetti di questa scelta, anzi, li hanno voluti. Infatti la scarsità dei blocchi prodotti in modo sincrono, produce una conseguente scarsità dei nuovi token creati da ogni blocco, scarsità da cui deriva loro un valore (idealmente proporzionale al costo computazionale necessario per produrre il blocco). Inoltre, quando tutti i bitcoin saranno stati creati, allora solo le fee saranno l’unica forma di ricompensa ai miners.  

Quindi la competizione tra gli utenti che porta a un aumento delle fee supporta l’ipotesi che anche dopo la fine del processo di creazione dei bitcoin i miners saranno comunque incentivati a supportare la rete: più utenti la useranno, maggiore saranno le fee, maggiore la ricompensa per i miners, quindi maggiore incentivo a partecipare alla sicurezza della rete. 

Per correttezza e completezza va considerato che tutti i problemi fino a qui descritti, usando Bitcoin come esempio, sono comuni a tutte le blockchain. Per aggirare i limiti prestazionali sono stati attivati numerosi progetti, definiti “di layer 2”, come ad esempio Lighting Network. Si tratta sostanzialmente di applicazioni indipendenti dalla rete che scrivono nel registro distribuito (di Bitcoin nel caso di Lighting Network) informazioni essenziali per il loro funzionamento sicuro. 

Sicuramente alcune di queste soluzioni Layer 2 avranno successo e Lighting Network ha questo potenziale, ma c’è un problema: se la sicurezza delle applicazioni Layer 2 deriva da quella del Layer 1, allora il Layer 2 può fornire solo servizi analoghi a quelli, sicuri, offerti dal Layer 1. Ad esempio Lighting Network supporta esclusivamente la stessa (e unica) applicazione fornita dalla sottostante rete Bitcoin, ovvero lo spostamento di token. 

Per ora ogni tentativo di creare delle soluzioni Layer 2 che forniscano altri servizi non ha avuto successo e la motivazione è abbastanza comprensibile: mentre lo spostamento di token è un’operazione basata su un processo stocastico markoviano in cui lo stato successivo processo è casuale ma dipendente dallo stato precedente, scambiare dati derivati da un generico processo stocastico non markoviano non permette di condividere uno stato verificabile.  

Per rendere affidabile un Layer 2 che gestisce dati prodotti da una generica applicazione occorre un Layer 1 molto performante ed economico sul quale memorizzare gli stessi dati rendendoli così immutabili. Questo requisito non può essere soddisfatto da una normale blockchain. 

Usare un registro distribuito non solo per spostare valore 
Occorre notare che tutte le criticità descritte per Bitcoin non sono affatto un problema. Se per inviare una ingente quantità di denaro occorre attendere qualche ora ma si spende qualche decina di dollari il risultato, rispetto ai sistemi tradizionali, è comunque straordinario. 

Il problema nasce quando si vuole usare la rete per applicazioni industriali, quindi inviare anche dati e possibilmente farli elaborare da uno smartcontract. Per questo tipo di utilizzo la variabilità del comportamento o del costo della rete diventa un fattore critico. 

Questo problema spiega la nascita delle blockchain private che non avendo bisogno di incentivare la partecipazione di miners indipendenti non necessitano di creare competizione tra chi gestisce e utilizza la rete. Basta attivare un certo numero di nodi e dimensionarli per gestire il volume di traffico derivante dalla dimensione e frequenza dei blocchi, parametri decisi per soddisfare le esigenze delle applicazioni client già note.  

Purtroppo però una rete realizzata con questo approccio non è decentralizzata e quindi non produce alcuna garanzia che i dati memorizzati nel registro non possano essere modificati da chi gestisce i nodi e soprattutto non fornisce alcuna garanzia che l’intera rete possa essere fermata impedendo al client di inserire nuove transazioni o di accedere al registro per consultazione. Insomma, una blockchain privata è solo un brutto e lento database gestito da un’entità centralizzata. 
 
C’è poi un problema molto importante che sconsiglia di usare blockchain private anche i quei casi in cui i nodi possono essere gestiti da soggetti indipendenti come ad esempio nell’ambito di un consorzio di aziende. In questo scenario applicativo in teoria tutti gli attori hanno l’interesse a supportare la rete senza ottenere una remunerazione diretta. Tuttavia se nessuno controlla i nodi è possibile che uno dei consorziati decida di aumentare le prestazioni del proprio nodo rendendolo capace di produrre più blocchi degli altri.

Apparentemente questa ipotesi non ha razionale, ma in realtà dipende dall’applicazione: se poter inserire maggiori dati nel registro produce un vantaggio al consorziato, allora avere un nodo più potente, che ad esempio può selezionare i propri dati e inserirli per primi nel registro, diviene conveniente e rompe l’equilibrio tra i consorziati. 

In poche parole le blockchain private non sono sicure, o sono costose o entrambe le cose. 

Arrivederci alla prossima puntata!