Ora scendiamo più nel dettaglio. Esistono diverse soluzioni per implementare blockchain aziendali. Hyperledger è un meta-progetto open source sotto l’egida della Linux Foundation che si propone di creare tecnologie blockchain interoperabili cross-industry. Ne esistono diverse varianti tra cui Sawtooth e Iroha, ognuna con caratteristiche e funzionalità peculiari. Un altro meta-progetto, non open source, per lo sviluppo di blockchain per il business è quello del consorzio R3 che propone il framework Corda.
Per questa introduzione ho scelto la soluzione IBM, che si compone di due moduli che operano a diverso livello, Hyperledger Composer e Hyperledger Fabric.
Hyperledger Composer è una suite di applicazioni ad alto livello che permette di progettare una rete di business; la terminologia usata è legata al mondo degli affari, del commercio e delle aziende rendendo più semplice e veloce questa prima fase di modellizzazione.
Si parte dalla struttura reale della business network che ruota intorno a un’azienda: se ne crea un modello che viene sviluppato e testato, usando API e architettura REST per dialogare con gli altri sistemi aziendali.
L‘architettura di Hyperledger Composer prevede quattro “moduli” che verranno integrati in un file finale con estensione .bna. Questo file sarà l’input per Hyperledger Fabric, il vero sistema blockchain, che sulla base di questo verrà implementata.
I moduli sono:
Model file, contiene definizioni e caratteristiche di partecipanti, asset e transazioni, le tre entità chiave di una business network. E’ di competenza del Business Analyst.
Access Control, che definisce i diversi tipi e livelli di autorizzazioni per i diversi partecipanti.
Script file, contiene essenzialmente i codici per eseguire le transazioni. E’ di competenza degli sviluppatori.
Query file, implementa i diversi tipi di interrogazioni che possono essere effettuate per “leggere” i dati registrati nella blockchain.
Facciamo un semplice esempio di progettazione di una business network, tanto per chiarire le idee.
Pensiamo alla supply chain della produzione di cioccolata.
I partecipanti alla nostra rete sono:
i coltivatori
l’importatore
l’azienda dolciaria
lo spedizioniere
Gli asset sono qualsiasi cosa abbia un valore e possa essere trasferito da un partecipante all’altro.
Ovviamente sono un asset le fave di cacao, ma ce ne sono altri. Una spedizione è un asset (che può “inglobare” le fave di cacao) come lo è un contratto tra importatore e azienda dolciaria per acquisto e invio di un lotto di fave di cacao.
Un asset “contratto” può essere identificato da questi parametri ed essere legato a questi partecipanti
Id contratto
Data arrivo
Penalità ritardi
-> spedizioniere
-> importatore
– > azienda dolciaria
Possono essere presenti altri parametri, come il range di temperatura ammissibile durante il trasporto. Rilevando attraverso sensori la temperatura durante tutto il viaggio, sulle navi, sui camion ecc. la si può monitorare, trasmettendo le informazioni alla blockchain. Se si oltrepassano i limiti stabiliti e scritti nel codice dell’asset, lo spedizioniere pagherà automaticamente una penalità.
Una spedizione può avere questi parametri e deve essere legata all’altro asset, il contratto.
Id spedizione
Status spedizione
-> contratto
A differenza di una blockchain pubblica, non tutti i partecipanti hanno accesso a ogni informazione. I trasportatori non possono accedere ai dati delle transazioni tra importatori e coltivatori. Quest’ultimi non sono autorizzati a visualizzare i dati di transazioni tra importatore e spedizionieri.
Le transazioni, scritte nello Script file, contengono le istruzioni per gestire e completare una transazione, i pagamenti e le eventuali clausole accessorie come quelle sulle penalità. In pratica si tratta di una serie di “se succede A esegui B altrimenti esegui C”.
E’ importante capire come i passaggi che tradizionalmente si accompagnano a un acquisto e una spedizione vengano gestiti tramite blockchain in automatico in un unico “ambiente” comune a tutte le parti in causa. Questa automatizzazione è ancor più spinta quanto più si utilizzano strumenti come quelli dell’IoT o comunque in grado di dialogare tra loro attraverso mobile, wi-fi, NFC, bluetooth.
Possiamo anche ipotizzare che vi siano altri partecipanti con funzioni di supervisione o controllo. Se la rete di business aderisce alle regole del commercio equo e solidale, un supervisore può essere autorizzato a visualizzare gli asset-contratti e le transazioni tra coltivatori e importatore per controllare che vi sia un adeguato compenso. Un ente governativo potrebbe accedere in lettura alla blockchain nel quadro del monitoraggio delle importazioni da particolari paesi. Un consorzio di qualità si accerterebbe della zona di provenienza delle fave di cacao e delle condizioni di trasporto. Tutti questi partecipanti potrebbero essere nodi della blockchain, anche se probabilmente non sarebbero dei validatori di blocchi, come vedremo tra poco.
Addentriamoci ora in aspetti più strettamente tecnici, di competenza di un ipotetico settore IT aziendale.
Hyperledger Fabric è il framework che implementa le funzionalità di base della blockchain IBM, gestendo le comunicazioni tra nodi, il meccanismo del consenso per la validazione delle transazioni, la creazione dei blocchi e via dicendo.
Esploriamo l’architettura, senza entrare troppo nei dettagli.
Il sistema centrale che implementa la blockchain esegue programmi chiamati chaincode (simili agli smart contracts), contiene dati di stato e ed esegue transazioni. Le applicazioni esterne possono, tramite API, connetersi a un nodo e compiere essenzialmente due operazioni: una semplice, leggere i dati della blockchain attraverso interrogazioni simili alle queries di un database e una più complessa, che prevede un aggiornamento della blockchain ovvero una richiesta di transazione.
I nodi sono entità logiche; su un server in realtà possono coesistere più nodi. Vale la pena ricordare che i nodi sono tecnicamente istanze della blockchain e della chaincode e risiedono nei server o nella cloud degli attori (autorizzati) della business network.
Vi sono tre tipi di nodi:
Peers, nodi che mantengono copia della blockchain e possono validare le transazioni.
Orderers, nodi di servizio che si occupano delle comunicazioni
Clients, che inviano le proposte di transazioni che dovranno essere approvate (dai peers validatori). I clients NON posseggono copia della blockchain.
Nell’esempio precedente un peer validatore potrebbe risiedere nei server dell’azienda o della sua filiale sudamericana, un client potrebbe essere un coltivatore che avvia — magari dal suo smartphone – la procedura di pagamento (transazione) da parte dell’importatore (nodo validatore) per un carico di fave di cacao.
Spesso i nodi peers utilizzano anche un database tradizionale, che conserva quel che viene definito “lo stato del mondo”, cioè gli ultimi dati memorizzati nella blockchain (nel registro immutabile): chi ha in quel momento in carico una spedizione, l’ultimo pagamento a un determinato coltivatore, l’ultimo arrivo di fave di cacao in azienda ecc. Il database rappresenta una “fotografia” al momento attuale dello stato delle transazioni; viene utilizzato per aumentare l’efficienza e il veloce recupero delle informazioni ma non è — in linea teorica — indispensabile perché dal ledger (libro mastro) si può sempre ricostruire la storia delle transazioni fino all’ultima confermata (commit). Da notare che la blockchain contiene anche le transazioni non approvate.
Caratteristica importante dell’architettura Hyperledger Fabric sono i canali (channels); visto che un’azienda può fare parte di diverse reti di business, è necessario che vengano utilizzati canali sicuri e indipendenti in cui far fluire le informazioni. Ciascun canale è anche lo spazio protetto in cui valgono le credenziali e le autorizzazioni, limitate a quella rete di business. Pensate ai canali come gruppi Whatsapp distinti in cui dialogare con alcune persone ma non con altre. Un partecipante può inoltre essere un validatore in una rete di business, un client in un’altra, un peer non validatore in un’altra ancora.
Passiamo alla gestione delle transazioni e alla creazione dei blocchi della catena. Qui occorre un po’ di pazienza e di attenzione.
Riprendiamo sempre il nostro esempio dell’azienda dolciaria e del suo delizioso cioccolato. Immaginiamo che i nodi peer siano
La sede centrale dell’azienda
La filiale sudamericana
L’importatore
La società di spedizioni
La cooperativa dei coltivatori
I nodi validatori sono i primi tre.
I clients sono i coltivatori. Potrebbero anche essere peer, in un altro modello.
Un coltivatore vuole vendere un lotto di fave di cacao. Invia tramite smartphone la richiesta di transazione alla rete; lo fa tramite il suo peer di riferimento, in questo caso quello della cooperativa che “firma” digitalmente la richiesta.
Questa viene passata agli altri peers, in particolare ai validatori che si accertano che la richiesta sia “ben formata”, che il client sia autorizzato a effettuare la transazione, che la firma digitale sia autentica, che non sia già stata presentata ecc. I validatori inviano attraverso la rete la loro risposta alla richiesta.
L’applicazione del client raccoglie le risposte e controlla che siano state rispettate le regole di approvazione (per esempio che o il nodo “sede centrale” o il nodo “filiale” abbia approvato la transazione). Se un validatore non approva la richiesta o il client non riceve tutte le validazioni necessarie, la proposta di transazione viene abbandonata e nulla viene alterato nella blockchain o nel database di stato. Altrimenti il cliente invia transazione e approvazioni associate all’Ordering Service. Questa applicazione di servizio ordina e raggruppa le transazioni in blocchi e le spedisce a tutti i peers della rete.
I peers controllano il blocco, cioè le transazioni e le risposte associate e le “taggano” come valide o non valide; solo a questo punto i peers aggiungono il blocco alla loro copia della blockchain e aggiornano il database sul nuovo “stato del mondo”.
Il client riceverà una notifica che lo avviserà che la transazione è stata approvata (o non approvata).
Step 2 — Invio richiesta, costruzione blocco con altre transazioni (TX), registrazione su blockchain e aggiornamento DB (solo se blocco approvato), avviso client TX registrata — Basato su schema IBM.com
La procedura — definita consensus – può apparire complicata ma in effetti ricalca quella classica, con fasi di avvio, controllo e verifica, firma e approvazione; la differenza è che tutto avviene automaticamente, in tempi estremamente veloci, con dati coerenti condivisi tra le parti in causa e memorizzati in maniera sicura e inalterabile. Niente email, niente fax (eh sì…), nessun plico, nessuna telefonata, nessun ritardo, nessuna discordanza sui dati.
Per l’approvazione di una transazione possono essere definite regole più complesse. Solo per fare un esempio, ai voti dei validatori possono essere assegnati “pesi”: la transazione viene validata solo se i voti complessivi raggiungono una certo valore (peso).
In questo wiki si stanno raccogliendo casi d’uso di Hyperledger: in alcuni casi vi sono informazioni dettagliate, in altri meno. Ma del resto è un work in progress.
Un’ultima informazione “di servizio” su Hyperledger. La IBM ha attivato, per ora solo negli Stati Uniti, una soluzione di blockchain preconfigurata — basata su IBM Cloud — con due piani a disposizione: lo “Starter Plan”, per sviluppo e test, e l’”Enterprise Plan” per la produzione. Il primo, gratuito al momento, permette di sviluppare e testare una soluzione con due organizzazioni, quindi due nodi e un canale. La seconda fornisce tutta l’infrastruttura per gestire una blockchain in un contesto reale. E’ una soluzione interessante, perché, una volta messa a punto, si possono invitare gli altri partecipanti alla business network a diventare nodi, collegandosi alla propria istanza nel cloud IBM: questa contiene la propria copia della blockchain e il codice necessario per le funzione tipiche di un peer, in particolare la validazione di transazioni e il commit dei blocchi.
