4. Hyperledger Fabric

Questo argomento è stato trattato in blockchains

---

Hyperledger Fabric è un ledger distribuito e permissioned.

Funzioni

Hyperledger Fabric nasce per soddisfare casi d’uso diversi, che un ledger permissionless non può. In particolare, nel contesto aziendale, si ha che:

• gli utenti possono essere identificati o identificabili;
• le reti devono essere permissioned;
• le prestazioni devono essere adeguate adeguate per un alto valore in throughput di transazioni;
• è necessaria bassa latenza nella conferma della transazione;
• deve essere garantita la privacy e la confidenzialità delle transazioni e dei dati aziendali.

Le funzioni che Hyperledger Fabric offre, sono:

• realizzazione di un ledger permissioned;
• ledger altamente modulare;
• consenso configurabile, sostituibile ed estendibile;
• supporto a smart contract in più linguaggi (Go, Java, JavaScript);
• bassa latenza;
• modello di endorsement flessibile per raggiungere il consenso dalle organizzazioni richieste ¹.

Permissioned vs Permissionless

In una blockchain permissionless, chiunque può parteciparvi e ogni partecipante è anonimo. Non c’è altra fiducia se non che lo stato della blockchain, prima di una certa profondità, è immutabile. Per mitigare l’assenza di fiducia, le blockchain permissionless tipicamente impiegano incentivi economici.

Al contrario, in una blockchain permissioned, si opera considerando un insieme di di partecipanti identificati e selezionati, che operano sotto un modello di governance che garantisce un certo grado di sicurezza. Si possono dunque utilizzare protocolli di consenso Crash Fault Tolerant (CFT) o Byzatine Fault Tolerant (BFT) che non richiedono mining costante.

In un contesto permissioned, il rischio di partecipanti che introducono codice malevolo intenzionalmente mediante uno smart contract diminuisce, poiché i partecipanti si conoscono tra di loro e tutte le azioni sono registrate sulla blockchain.

Privacy e Confidenzialità

In una blockchain permissionless che sfrutta PoW come modello di consenso, le transazioni sono eseguite su ogni nodo e non può esserci confidenzialità né per i contratti stessi, né per i dati delle transazioni che processano.

In un contesto permissioned che sfrutta diverse forme di consenso si possono esplorare approcci che restringono la distribuzione di informazioni confidenziali esclusivamente ai nodi autorizzati.

Canali

Un canale è simile a una sottorete privata su cui avviene la comunicazione tra due o più membri specifici della rete, con lo scopo di effettuare transazioni che siano private e confidenziali.

Ogni transazione sulla rete è eseguita su un canale, in cui ogni parte deve essere autenticata e autorizzata per effettuare transazioni su quel canale. Un’organizzazione può poi far parte di più canali allo stesso tempo.

Attori coinvolti

• client: l’applicazione che interagisce con la blockchain;
• peer: nodo che effettua transazioni e mantiene lo stato e una copia del ledger;
• ordered un servizio responsabile per ordinare transazioni, creare un nuovo blocco di transazioni ordinate e distribuire il blocco appena creato a tutti i pari sul canale di interesse;
• certificate authority: responsabile per la gestione dei certificati utente;
• membership service provider: gestisce identità e permessi.

Certificate Authority

Le Certificate Authorities emettono dei certificati x.509 che possono essere usati per identificare i membri che appartengono a un’organizzazione. I certificati emessi dalle CA sono anche usati per firmare le transazioni per indicare che un’organizzazione approva (endorses) il risultato di una transazione, una precondizione affinché sia accettata sul ledger.

Peers

Divisi in:

• committing peer: conserva solo un ledger locale;
• endorsing peer: fa l’endorsement di una transazione prima che questa sia oggetto di commit. Ogni chaincode ² specifica una endorsement policy che si riferisce a un insieme di endorsing peer e definisce quali peer devono concordare sul risultato di una transazione prima che questa possa essere aggiunta.

Ledger

I componenti interni del registro includono:

• blockchain: mantiene la cronologia di tutte le transazioni di ogni chaincode su un particolare canale;
• world state: mantiene lo stato corrente delle variabili di ogni specifico chaincode.

Join Nodes

I peer sono un elemento fondamentale della rete perché ospitano il ledger e i chaincode. Dunque, sono uno dei punti fisici presso i quali le organizzazioni che svolgono le transazioni su un canale si collegano al canale stesso. Un peer può appartenere a tanti canali quanti l’organizzazione ritiene appropriati.

Chaincode

Con chaincode ci si riferisce agli smart contract che definiscono la business logic e le regole di una rete blockchain. Mentre si rilascia il chaincode, un amministratore può definire una endorsement policy per il chaincode.

Endorsement Policy

La politica di endorsement definisce i nodi peer su un canale che devono eseguire le transazioni allegate a un’applicazione specifica e le combinazioni delle risposte richieste (endorsements).

Una policy può richiedere che una transazione riceva l’endorsement da un numero minimo, una percentuale minima oppure da tutti gli endorsing peers che sono assegnati a uno specifico chaincode.

Le policy possono essere redatte sulla base dell’applicazione e sul livello di resilienza desiderato contro un comportamento errato degli endorsing peer. Una transazione che viene inviata deve soddisfare la policy di endorsement prima di essere segnata come valida dai committing peers.

Funzionamento generale

• CAx: le certificate authorities;
• L1: il ledger condiviso;
• S5: il chaincode;
• Px: i vari peers;
• C1: il canale di comunicazione;
• Ax: le varie applicazioni;
• O: ordering service.

Il modello seguito da Hyperledger Fabric è un modello execute-order-validate:

• proposta della transazione & simulazione della transazione: l’applicazione invia una proposta a degli endorsing peers specifici, contenente la funzione da chiamare con gli argomenti necessari. Ogni endorsing peer eseguirà lo smart contract, ma in un ambiente simulato senza l’aggiornamento del ledger, salvando un read set (i dati a cui si è avuto accesso) e un write set (i cambiamenti che avverrebbero);
• endorsement & invio: gli endorsing peers inviano i risultati della simulazione al client in forma di Endorsed Proposal Response, includendoci la firma digitale. Una volta che il client ha raggiunto un numero di firme sufficienti a soddisfare la policy di endorsement, invia in broadcast la transazione all’ordering service;
• ordering e final commitment: l’orderer riceve le transazioni da più client, le ordina in maniera cronologica e le “impacchetta” in un nuovo blocco, quindi manda il broadcast il blocco a tutti i committing peers sul canale di interesse. Ogni committing peer valida il blocco, controllando le firme per l’endorsement e si assicura che il read set non sia cambiato dalla simulazione, prevenendo il double-spending. A questo punto, le transazioni sono permanentemente scritte sul ledger e il world state è aggiornato. I client sono notificati del completamento della transazione.

Consenso

L’algoritmo di consenso è deterministico: ogni blocco validato dai peers ha la garanzia di essere finale e correto.

Il determinismo è garantito dall’ordering service; quello tipicamente consigliato è Raft, che è Crash Fault Tolerant basato sull’implementazione del protocollo Raft.

Footnotes

1. Significa che, in Hyperledger Fabric, il consenso non si ottiene tramite un unico algoritmo globale (come PoW o PoS), ma attraverso un modello di endorsement flessibile che permette di definire quali organizzazioni devono approvare una transazione affinché sia considerata valida. ↩

2. È il programma che contiene la logica applicativa. È l’equivalente, per Hyperledger Fabric, degli smart contract. ↩