Hyperledger è un complesso di progetti open source nato con finalità differenti da Bitcoin, pertanto avente una struttura del tutto diversa.
In un precedente articolo si è detto che le critiche mosse ad Hyperledger dai fans di Bitcoin derivano:
- dalla superiorità attribuita alla blockchain “di Nakamoto” in quanto l’unica in grado di garantire, per le sue caratteristiche, reale trasparenza sulla gestione del protocollo e tendenziale immutabilità del dato;
- dall’assimilazione di Hyperledger ad una blockchain, nonostante le sue caratteristiche siano differenti e, dunque, ritenute non in idonee a garantire i medesimi benefici.
Con questo approfondimento tenterò, attraverso un’analisi comparativa, di dipanare alcuni dubbi che fomentano la polemica Hyperledger vs Bitcoin e non consentono di costruire un dibattito proficuo alla valutazione dei campi di applicazione attuali e futuri dell’una e dell’altra tecnologia.
Il primo nodo da sciogliere è l’assunto alla base della diatriba.
Non si comprende cioè sulla base di quali elementi Bitcoin debba essere considerato il punto di riferimento per antonomasia fra le blockchain, quando è noto invece che ogni protocollo vada ricalcato sulle specifiche caratteristiche di un business.
Considerato il suo utilizzo e il successo della criptovaluta che costituisce la reward per i contributor, forse potremmo citarlo come riferimento di blockchain per la creazione di asset digitali o per attività finanziare in genere.
Non si comprende invece quale utilizzo potrebbe avere nel processo di certificazione di qualità di un prodotto tessile o agro alimentare, che si compone di operazioni che Bitcoin non è studiato per effettuare.
Allora forse, quando si prende a riferimento Bitcoin in contrapposizione ad Hyperledger, si intendono precisamente la pubblicità delle informazioni (seppur in modalità pseudonima) e l’astratta assenza di requisiti di partecipazione (c.d. permissionless)?
Bene, sarebbe opportuno che la critica venisse espressa in modo puntuale tanto quanto, dall’altra parte, IBM spiega il proprio progetto, da ultimo nel paper sulla tutela del made in Italy, attraverso un articolo sottoposto alla peer review e nel quale si spiegasse, fra le altre cose, in che modo si possa conciliare l’assenza di logging e auditing con la legge, per operazioni di certificazione e/o trasferimento di asset digitali suscettibili di valutazione economica.
E’ fondamentale tener presente, infatti, che Bitcoin è stato reso disponibile alla Rete da un anonimo noto col nome di Satoshi Nakamoto e non vi è un ente di riferimento al quale imputare diritti e obblighi di legge.
Soggetti identificabili che vogliano implementare una soluzione di business su base blockchain sono invece pienamente tenuti al rispetto delle normative nazionali ed europee e, di conseguenza, devono implementare meccanismi di autenticazione degli utenti qualora gli offrano un servizio in cambio di una controprestazione economica.
Forse, dunque, il dibattito intorno ad Hyperledger e Bitcoin, si fonda su una non corretta o piena conoscenza delle complesse dinamiche economiche, giuridiche e tecniche che vi ruotano attorno; in definitiva, potrebbe fondarsi in parte proprio su una non corretta percezione del significato di blockchain.
Da qui la necessità di stabilire, prima d’ogni cosa, un vocabolario condiviso fra coloro che vogliano intavolare una discussione su questi temi, chiarendo il significato di:
- distribuzione e decentralizzazione;
- permissioned, permissionless e hybrid;
- privato e pubblico;
- consenso (POW, POS, DPOS, POET e POA);
- nodo e miner (sempreché esista);
- byzantine fault tolerance.
Distribuzione
Si riferisce alla condivisione del Ledger, dunque al numero di nodi (device) che, almeno sotto il profilo della lettura, partecipano al network.
Il numero dei nodi, anche se determinante per assicurare l’immodificabilità del dato e la sicurezza, non è l’unico elemento caratterizzante poiché entrano in gioco anche altre variabili come l’architettura del network e il meccanismo di consenso implementato ossia, semplificando, il sistema per consentire ai vari utenti (cc.dd. actor), che potrebbero anche non conoscersi, di collaborare fra loro.
Decentralizzazione
Con questo termine ci si riferisce all’architettura del network e al grado di partecipazione decisionale, nella gestione quotidiana ed evolutiva, riconosciuto ai vari utenti/device (cc.dd. actor).
Una blockchain, sotto questo profilo, può essere più o meno decentralizzata.
In particolare, potremmo individuare tre macro architetture in considerazione del numero di ruoli esperibili dagli actor e del rapporto che li lega l’uno all’altro:
“orizzontale”
gli actor svolgono tutti il medesimo ruolo;
“competitiva”
gli actor svolgono generalmente due ruoli differenti:
– condividere il ledger;
– validare i records che vengono caricati sul ledger in cambio di una reward;
“consortile” e/o “federale”
gli actor svolgono differenti e molteplici ruoli, ragion per cui la parità si realizza esclusivamente fra quelli del medesimo tipo.
I pian operativi, dunque, variano a seconda delle tipologie di nodi (es. Hyperledger Fabric).
Permissioned, permissionless e hybrid
Tali definizioni riguardano la presenza o meno di requisiti formali per l’accesso e la partecipazione al network.
La distinzione è sfuggevole, poiché, come si dirà in seguito prendendo a riferimento Bitcoin, anche reti che astrattamente non presentano requisiti, in concreto li hanno.
Le reti permissioned risultano più facilmente implementabili dai vari contributor, non solo in ragione del fatto che la loro identità è accertata ma altresì del fatto che spesso tale strutturazione coincide con l’attribuzione di privilegi gestionali in capo ad una pletora di nodi (in altri termini, spesso, permissioned ed architettura consortile/federale coincidono).
Le reti permissionless, per converso, non presentano formalmente requisiti di accesso e partecipazione e risultano meno scalabili una volta strutturate poiché coincidono spesso con architetture “orizzontali”, in cui cioè il consenso è distribuito paritariamente fra tutti i contributor su un unico piano operativo.
In ragione delle loro caratteristiche (informatiche ed economiche), le reti permissionless hanno attualmente un numero di nodi ben maggior di quello delle reti permissioned.
Nel tentativo di garantire un giusto compromesso fra le due strutturazioni e consentire ad aziende che vogliano impiegare in modo agevole tali tecnologie per specifiche finalità, senza tuttavia attenuare la trasparenza nei confronti degli utenti, sono recentemente sorte reti ibride, ossia permissioned (secondo varie architetture) ma sottoposte alla “vigilanza” o più correttamente governance di blockchain totalmente permissionless (es. Ethereum).
Sotto questo profilo, particolarmente interessante potrebbe essere l’integrazione, attualmente in discussione, proprio della blockchain di Ethereum in Hyperledger, per mezzo del progetto Pantheon.
Pubblico e privato
Tali espressioni si riferiscono alla consultabilità del ledger.
Privata è ad esempio la blockchain in sperimentazione da parte dell’ABI, pubblica invece Bitcoin.
Sono quindi concetti che non coincidono necessariamente con i precedenti, potendosi avere ad esempio una blockchain permissioned ma liberamente consultabile in modalità pseudonima.
Consenso
Occorre anzitutto distinguere il protocollo dall’algoritmo di consenso.
Con protocollo si identifica l’organizzazione di una blockchain, l’insieme di regole primarie.
L’algoritmo invece può essere definito come il meccanismo attraverso cui un network blockchain raggiunge il consenso o, più chiaramente, ciò che garantisce il rispetto delle regole definite nel protocollo, che tutte le transazioni avvengano correttamente e le medesime criptovalute non possano essere spese più di una volta (c.d. double spending).
Ad esempio, il protocollo Bitcoin definisce:
- il modo in cui i nodi interagiscono;
- come i dati devono essere trasmessi tra loro;
- quali sono i requisiti per convalidare un blocco con successo.
L’algoritmo di consenso, invece, ha il compito di:
- verificare i bilanci e le firme;
- confermare le transazioni;
- eseguire effettivamente la convalida dei blocchi – e tutto questo dipende dal consenso del network.
Come intuibile gli algoritmi di consenso sono di vitale importanza per mantenere l’integrità e la sicurezza del network di una criptovaluta.
Ve ne sono taluni cc.dd. byzantine fault tolerant (Proof of Work di Bitcoin, Proof of Stake di Ethereum, Delegated Proof of Stake di Eos) altri no (Proof of Authority di Hyperledger Fabric e Proof of Elapsed Time di Hyperledger SawTooth).
La distinzione è rilevante perché:
- i primi sono in grado di risolvere eventuali conflitti generati in contesti in cui gli actor non sono identificati e non vi è sostanziale distinzione fra loro, dunque, “orizzontali” o “competitivi”.
Per questo prevedono di default l’uso di criptovalute per incentivare la partecipazione al network da parte di coloro che vogliano offrire un contributo più rilevante per validare le operazioni;
- i secondi sono studiati per operare in contesti più verticali/consortili/federati come la P.A., la Supply Chain e nel c.d. InsurTech, in cui gli actor sono identificati e, in ragione delle caratteristiche di coloro che li gestiscono, gli sono attribuiti ruoli diversi. Per tali ragioni, non prevedono ordinariamente l’uso di asset digitali.
Riassumendo con degli esempi:
- in Bitcoin distinguiamo nodi (coloro che detengono una copia del ledger) e miner (coloro che offrono potenza computazionale per validare transazioni e che hanno un ruolo politico nell’evoluzione del network, ossia nelle decisioni che la community prende circa le implementazioni da apportare. Un eventuale contrasto insanabile in proposito può determinare un c.d. fork). La blockchain è:
- pubblica, in quanto chiunque può consultarla;
- permissionless in lettura ma non, in concreto, in scrittura giacché, sebbene non siano previsti requisiti formali per divenire miner, in concreto solo chi è dotato di ingentissime risorse economiche può farlo.
- oggi sufficientemente distribuita;
- astrattamente decentralizzata ma tendente come ogni altra alla centralizzazione (per l’accumulo di hashpower in capo a poche entità);
- intrinsecamente legata ai bitcoin, ossia alla reward concessa ai miner – per l’hashpower speso per validare le transazioni e minare i blocchi (POW) – dunque, specificatamente finalizzata alla creazione e allo scambio di un asset digitale.
- Hyperledger, come detto, è un complesso di progetti in sviluppo continuo da parte di una florida comunità supportata da IBM. Linux Foundation mette a disposizione liberamente i propri progetti e consente di implementarli in modo del tutto originale, utilizzarli così come vengono proposti, con protocolli di consenso già impostati (POA e POET), o creare soluzioni ibride. La scelta dipende ovviamente sia dallo scopo che si intende perseguire, sia dal budget a disposizione, sia infine dalle capacità degli ingegneri e dei programmatori. Perché, certamente, sviluppare una soluzione ETH in C++, non equivale a sviluppare una soluzione originale con Hyperledger.
- Hyperledger Fabric è uno specifico progetto, studiato per la gestione di processi fra “Autorità”, ossia enti posti al vertice di una catena certificatrice e, in quanto tali, preposti ad attestare agli utenti la veridicità delle operazioni compiute presso di essi. Immaginando che venga utilizzato per la gestione dei processi della P.A.. ne risulterebbe pressappoco la seguente architettura.
In questo caso, è evidente che il meccanismo di consenso DEVE essere diverso, semplicemente perché finalizzato a gestire processi fra soggetti che non hanno le medesime qualità e funzioni:
- cittadini;
- ufficiali pubblici che attestano un dato;
- Uffici;
- Comuni;
- Province;
- Regioni;
- Ministeri;
- Stati.
Il sistema è permissioned, giacché prevede di default sistemi di logging e auditing – che, si ribadisce, salvo realizzare un protocollo in modo anonimo e donarlo alla Rete, ogni impresa o P.A. deve adottare per essere conforme alla legge nella fornitura di un servizio a fronte di una contro prestazione – e può essere pubblico (in modalità pseudonima).
In proposito, uno dei progetti in sviluppo per consentire agli utenti di visionare la tipologia di operazioni effettuate dalla sotto rete di riferimento, dunque ad esempio l’efficienza di un ufficio, è Explorer.
Hyperledger non prevede necessariamente l’uso di criptovalute, più precisamente token, poiché non ve n’è la necessità considerato l’ambito applicativo.
Un ulteriore paragone utile a comprendere l’utilizzabilità di Hyperledger Fabric può essere quello fra il “Caso Walmart” e il “Caso made in Italy“.
Nel modello Walmart non v’è competizione fra aziende differenti, atta a garantire il controllo reciproco della qualità delle operazioni effettuate.
I vari elementi della catena/filiera, in altri termini, conducono unicamente a Walmart, con la conseguenza che non è il sistema utilizzato ad inficiare la qualità delle informazioni ma la sua specifica applicazione.
Nel sistema made in Italy, invece, in ottica di progressivo sviluppo, potremmo avere molteplici Nodi Autorità (aziende certificatrici), molteplici nodi brand, molteplici filiere l’una in competizione con l’altra.
Ritornando quindi alla domanda posta nell’articolo precedente, in un sistema siffatto chi dovrebbe certificare il certificatore?
NESSUNO.
E nel caso in cui sostituissimo del tutto l’umano certificatore, saremmo certi di aver effettivamente attenuato il “problema fiducia” e di non averlo invece semplicemente spostato in capo ad altri soggetti?
NO.
Al momento, infatti, i certificatori sono umani, italiani e individuabili.
L’uso massivo delle macchine, oltre a gravare sulle aziende che dovrebbero adottarle (se imposto repentinamente) e determinare un’impennata dei rischi di cyber security, imporrebbe di fidarsi comunque delle certification authorities informatiche, delle aziende produttrici di software e hardware, pressoché tutte made in U.S.A e Cina.
Dal che discende una ulteriore domanda, rivolta in particolare a coloro che hanno recentemente affermato che un progetto di tutela del made in Italy dovrebbe essere proprio italiano:
allo stato attuale siamo realmente in grado di far fronte al costoso e complesso aggiornamento tecnologico e culturale che un modello del genere ci imporrebbe qualora venisse realizzato totalmente in Italia?
SICURAMENTE NON NELL’IMMEDIATO.
Punto invece che va indispensabilmente approfondito è quello del valore e dell’uso dei dati derivanti dall’adozione di Hyperledger Fabric per la tutela del made in Italy, poiché nella sperimentazione effettuata, il sistema è stato reso disponibile in cloud.
CONCLUSIONE
Posto che entrambi i sistemi (Hyperledger e Bitcoin) sono P2P, la decentralizzazione assume forme differenti, idonee a svolgere compiti diversi.
L’evoluzione decennale del protocollo Bitcoin, inoltre, insegna che nonostante l’assenza formale di pre-requisiti di partecipazione e la proiezione verso la decentralizzazione, l’uso concreto fattone dagli utenti può determinare una forte limitazione di tali caratteristiche.
La dinamicità degli strumenti informatici e la multidisciplinarietà delle applicazioni, impone ampia conoscenza e un approccio intellettuale aperto e flessibile.
Criticare un progetto con cognizione significa quindi non solo averlo esaminato approfonditamente ma aver considerato le molteplici variabili economiche, giuridiche e tecnopolitiche che entrano in gioco.
Si ringrazia Pierluigi Riti, Lead Security Information Engineer at Mastercard, per la revisione dell’articolo e l’avv. Paolo Nardella, per il proficuo confronto che ne ha ispirato la redazione.