Hyperledger: Fabric, Sawthoot e Iroha in un breve confronto

Fonte: Immagine creata dall'autore

Premessa: tutti i framework Hyperledger sono appena arrivati (ad Aprile 2018) alla versione 1.0 o l’hanno superata da pochi mesi/meno di un anno. Significa che molto può cambiare in futuro ed il presente articolo potrebbe non essere aggiornato al momento della vostra lettura.

Tre framework a confronto

Hyperledger nasce come un progetto di sforzo comune a disposizione di realtà di tipo enterprise, dove la necessità principale è la riservatezza delle transazioni. Per questo motivo, tutti i framework in Hyperledger sono stati studiati per essere implementati come blockchain private. Solo Sawtooth al momento prevede anche la possibilità di configurare una blockchain permissionless (pubblica).

I framework che possiamo trovare nell’ecosistema Hyperledger sono 5: Sawtooth, Iroha, Fabric, Burrow ed infine Indy.

A completare la suite esistono dei tool o moduli, che grazie alla modularità dei progetti Hyperledger, possono essere incastonati nei framework ed utilizzati come complemento ad essi. Le componenti di base dei framework Hyperledger sono comuni a tutte le blockchain di terza generazione:

Un registro distribuito "append-only"
Un algoritmo di consenso per confermare i cambiamenti sul registro
Privacy delle transazioni attraverso la configurazione di permessi d’accesso (se blockchain privata o ibrida)
Smart contracts per processare le richieste di transazione.

Visto che ho avuto modo di leggere la documentazione per affrontare un caso di studio, ho voluto pubblicare questo confronto tra i framework Sawtooth, Iroha e Fabric nelle loro caratteristiche comuni sperando di fare una cosa utile e gradita.

A livello strutturale, i tre framework sono diversi, ognuno con il proprio "workflow", quindi per effettuare una scelta tecnica è chiaramente necessario basarsi anche sul contesto d’uso oltre che sul confronto delle caratteristiche in comune.

Sawtooth

Il framework Sawtooth, nel suo Core System è arrivato alla versione 1.0.2. Storage level: LMDB (mi è stato detto nel canale sawtooth della chat ufficiale di Hyperledger visto che nella documentazione non c’è traccia di questa informazione).

Smart Contracts

Sawtooth espande il concetto di smart contract portandolo a farlo diventare un processore di transazioni (transaction processor) dove risiede la business logic. La particolarità sta nel fatto che sono creabili tramite template predefiniti chiamati “transaction families”. Sono disponibili varie transaction families come “Settings” o “Identity”, ognuna con il proprio scopo. Gli smart contract possono essere scritti in diversi linguaggi: Python, Javascript, Rust, C++ e Go. Inoltre esiste la possibilità di utilizzare smart contract scritti nei linguaggi consentiti dalle Virtual Machines Java ed Ethereum (grazie al progetto Seth https://github.com/hyperledger/sawtooth-seth). Con la dovuta configurazione, è quindi possibile utilizzare uno smart contract scritto in Solidity.

Algoritmo di consenso

Ha PoET (Proof of Elapsed Time) come algoritmo di consenso, sebbene siano disponibili anche il “Dev_mode” che facilita l’utilizzo da parte dei programmatori ed i test, il “PoET-Simulator” che però NON è Byzantine Fault Tolerant (BFT) ed infine “RAFT” che però è ancora in fase di sviluppo.

Gestione della Privacy

Ad oggi ci sono due metodi generalmente adottati per preservare la privacy in una blockchain:

Suddividere i domini: il metodo di gestione della privacy implementato da Fabric prevede un modello a canali (Channels), dove ogni canale vive di vita propria. Lo svantaggio di questo modello è la creazione di un numero di “sub-chains” e il trasferimento di assets tra queste sub-chains è impegnativo e comporta problemi di privacy.

Criptare il dato: gli svantaggi possono includere la necessità di hardware fidato o limitazioni di performance e usabilità con tecniche crittografiche avanzate.

Al momento nel progetto Sawtooth non è indicato un approccio univoco al mantenimento della privacy.

In Sawtooth sono configurabili sia ruoli che policy per definire i permessi in modo flessibile.

Unicità

Le caratteristiche "confrontabili" che distinguono Sawtooth da Iroha e Fabric sono l’esecuzione parallela delle transazioni e la possibilità di impostare la blockchain permissionless. Per quanto riguarda le transazioni, molte blockchain hanno la necessità di eseguire le transazioni in serie per garantire un ordinamento consistente in ogni nodo nella rete. Sawtooth include un processo parallelo avanzato che divide le transazioni in flussi paralleli.

Fonte: Immagine creata dall'autore

Iroha

Il framework Iroha si avvicina ad essere rilasciato nella versione 1.0. Iroha offrirà una serie di funziolità tra cui: la gestione di assets complessi, la gestione di account utenti, una tassonomia basata su “sub-chains”, un sistema di gestione di permessi degli utenti. Lo storage level è composto da tre diversi componenti: Redis (block index), Flat files (block store) e PostgreSQL (world state view).

Smart Contracts

Al momento sono ancora in una fase di design, ma saranno supportati in futuro. https://github.com/hyperledger/iroha/issues/249

Algoritmo di consenso

Iroha offre un algoritmo BFT, attualmente ancora in fase di sviluppo, che si chiama YAC (Yet Another Consensus) il quale compie sia l’operazione di ordinamento che l’operazione di consenso.

Gestione della Privacy

La gestione dei permessi in Iroha rende flessibile la risposta anche a necessità complesse da studiare caso per caso.

Unicità

Rispetto a Sawtooth e Fabric, Iroha ha a disposizione librerie per lo sviluppo per Android, iOS, Scala e .NET. https://github.com/hyperledger?utf8=%E2%9C%93&q=iroha

Fonte: Immagine creata dall'autore

Fabric

Il framework Fabric è il più maturo del gruppo, è stato il primo ad arrivare alla release 1.0 annunciata l’11 luglio 2017 (https://www.hyperledger.org/announcements/2017/07/11/hyperledger-announces-production-ready-hyperledger-fabric-1-0). Attualmente la versione stabile è la 1.0.5. Storage level: lo state database può essere LevelDB (default) o CouchDB e può essere ricreato in qualsiasi momento visto che si tratta solo di una vista indicizzata della blockchain (memorizzata su altri file).

Smart Contracts

In Fabric prendono il nome di “chaincode” e attualmente possono essere scritti in linguaggio Go o Java. Gli smart contract risiedono sui nodi chiamati “endorsing peer”, i quali hanno il compito di validare le transazioni.

Algoritmo di consenso

Il consenso in una rete Fabric è raggiunto tramite 3 steps: l’appoggio alle transazioni (transaction endorsment), l’ordinamento delle transazioni in un blocco (ordering) e la validazione prima della conseguente scrittura sul registro (validation e commitment). La fase di ordering è un modulo che può essere sostituito a seconda delle necessità. Attualmente, sono disponibili due algoritmi di ordinamento. Gli algoritmi sono: SOLO (utilizzabile durante lo sviluppo) e Kafka (default, sebbene NON sia BFT).

Ci sono proposte di algoritmi di ordinamento BFT per Fabric, ma ancora non sono supportate ufficialmente.

https://jira.hyperledger.org/browse/FAB-378

https://github.com/jcs47/hyperledger-bftsmart (per v. 1.1)

Gestione della Privacy

Oltra alla gestione dell’autenticazione dei peers (e degli utenti) nella rete tramite MSPs (vedi paragrafo successivo), Fabric prevede un modello a canali (Channels) per la divulgazione delle informazioni che sono condivisibili solo tra gli attori coinvolti nel canale. Una sorta di “sub-chain” per ogni canale.

Unicità

Il componente Membership Service Provider (MSP) rende unico Fabric nella gestione delle autorizzazioni di accesso alla blockchain ed i relativi channels. MSP definisce i ruoli con i quali le varie identità sono validate e autenticate, oltre a definire i permessi di accesso alla rete. MSP fa uso di una CA (Certification Authority) interna di default (Fabric-CA) per verificare gli utenti ma è possibile scambiarla con una CA esterna. All’interno di una rete Fabric possono coesistere più MSP.