190214_Hyperledger - Lesson 03

Avviso – Queste lezioni sono il frutto del MOOC che ho svolto per conseguire il relativo certificato.

PS: l’uso di tecnologie nuove porta con se nuovi termini. Al sopraggiungere di essi ho provato a tradurli in italiano per una migliore comprensione. Successivamente ho usato il termine in inglese per assecondarne l’introduzione nell’uso abitudinario.

Per la fine della Lezione 3, capiremo:

  • Capire le basi di Hyperledger Iroha;

  • Discutere i componenti cruciali dell’architettura di Hyperledger Iroha quali:

    1. l’algoritmo di consenso YAC (Yet Another Consensus);

    2. i peers;

    3. i clienti e la memorizzazione del blocco del registro Ametsuchi.

Hyperledger Iroha

Hyperledger Iroha è un framework blockchain e uno dei progetti Hyperledger ospitati da The Linux Foundation. Hyperledger Iroha ha avuto un contribuito iniziale da Soramitsu, Hitachi, NTT Data e Colu.

Hyperledger Iroha è progettato per essere semplice e facile da integrare in progetti infrastrutturali che richiedono la tecnologia dei registri distribuiti.

Hyperroger Iroha presenta una struttura semplice, moderna, domain-driven C++ design, enfatizzata sullo sviluppo di applicazioni mobili e l’algoritmo di consenso YAC.

190214_Hyperledger - Lesson 03-02 - Iroha_logo

Hyperledger Iroha cerca di contribuire con tre obiettivi principali a:

  • fornire un ambiente per gli sviluppatori C++ per contribuire a Hyperledger;

  • fornire un’infrastruttura per il supporto di applicazioni mobili e Web;

  • fornire una struttura per introdurre le API e un nuovo algoritmo di consenso che possa potenzialmente essere incorporato in altri framework in futuro.

L’architettura principale di Hyperledger Iroha è stata ispirata da Hyperledger Fabric, che vedremo di seguito.

I creatori di Hyperroger Iroha hanno sottolineato l’importanza di questa struttura nel soddisfare la necessità di interfacce user-friendly. In tal modo, hanno creato un framework con molte funzioni di definizione, tra cui una semplice costruzione, un moderno design C++, con un’enfasi sullo sviluppo di applicazioni mobili e un nuovo algoritmo di consenso bizantino Fault Tolerance basato sulla catena, chiamato Sumeragi.

Forse la caratteristica più significativa di Hyperledger Iroha è la sua capacità di essere liberamente interoperabile con altri progetti di Hyperledger.

Le librerie open source iOS Android e JavaScript consentono agli sviluppatori di creare convenientemente funzioni per eseguire operazioni comuni.

Panoramica sull'architettura

Lo schema seguente mostra una vista architettonica stratificata dei diversi componenti che compongono Hyperledger Iroha. I quattro livelli sono: API, Peer Interaction, Chain Business Logic e Storage.

190214_Hyperledger - Lesson 03-03 - Iroha-architecture

I componenti sono:

  • le classi del Model sono entità di sistema;

  • il Torii (il gate) fornisce le interfacce di input e output per i client. Si tratta di un singolo server gRPC che viene utilizzato dai client per interagire con i peer attraverso la rete. La chiamata RPC del client è non bloccante, rendendo Torii un server asincrono. Entrambi i comandi (le transazioni) e le query (accesso in lettura) vengono eseguiti tramite questa interfaccia;

  • il Network comprende l’interazione con la rete dei peer;

  • il Consenso è responsabile dei peer che concordano sul contenuto della catena nella rete (network). Il meccanismo di consenso utilizzato da Iroha è YAC (Yet Another Consensus), che è un pratico algoritmo tollerante all’errore bizantino basato sul voto per l’hash del blocco;

  • il Simulatore genera un’istantanea temporanea di archiviazione per convalidare le transazioni eseguendole contro questa istantanea e formando una proposta verificata, che consiste solo di transazioni valide;

  • le classi del Validatore controllano le regole di business e la validità (formato corretto) delle transazioni o delle query. Esistono due diversi tipi di convalida che si verificano in Hyperroger Iroha:

    1. la Validazione Stateless è una forma di convalida più rapida, che esegue controlli dello schema e della firma della transazione;
    2. la Validazione Stateful è una forma di convalida più lenta, che controlla le autorizzazioni e la vista corrente dello stato del mondo, che è lo stato più recente e più reale della catena, per vedere se sono possibili le regole e le politiche aziendali desiderate. Ad esempio, un account dispone di fondi sufficienti da trasferire?
  • il Sincronizzatore aiuta a sincronizzare i nuovi peer nel sistema o i peer temporaneamente disconnessi;
  • Ametsuchi è la memorizzazione del blocco del registro che consiste in un indice di blocco (attualmente Redis), una memorizzazione del blocco (attualmente file piatti) e un componente di visualizzazione dello stato del mondo (attualmente PostgreSQL).

Partecipanti all'interno della rete (network)

Ci sono tre partecipanti principali all’interno di un network Iroha di Hyperledger:

  • i Client sono in grado di:

    1. Interrogare i dati a cui hanno accesso / permesso
    2. Esegui un’azione che cambia lo stato, la “transazione”, che consiste in operazioni atomiche, chiamate “comandi”. Ad esempio, in una singola transazione, un utente può trasferire fondi a tre persone (tre comandi separati). Ma, se non ha abbastanza fondi per coprirli tutti, l’intera transazione sarà respinta.

  • i Peer mantengono lo stato corrente e la propria copia del registro condiviso. Un peer è una singola entità nella rete e ha un indirizzo, una identità e una fiducia. Hyperledger Iroha è progettato in modo che un singolo peer possa essere un singolo computer o ridimensionato per un cluster, il che significa che diversi computer vengono utilizzati per la memorizzazione, gli indici, la convalida e la logica peer-to-peer

  • il Servizio di Ordinamento ordina le transazioni in un ordine noto. Ci sono alcune opzioni per l’algoritmo utilizzato dal servizio di ordinazione. Kafka è considerato un buon candidato.

Nozioni di base sul flusso di una transazione (Parte I)

Passaggio 1: un client crea e invia una transazione al gate Torii, che indirizza la transazione a un peer responsabile della esecuzione della Validazione Stateless.

190214_Hyperledger - Lesson 03-04 - Step_1_of_Iroha_Transaction_Flow

Passaggio 2: Dopo che il peer esegue la Validazione Stateless, la transazione viene prima inviata al gate degli ordini, che è responsabile della scelta della corretta strategia di connessione al servizio di ordinamento.

190214_Hyperledger - Lesson 03-05 - Step_2_of_Iroha_Transaction_Flow

Passaggio 3: il servizio di ordinamento mette in ordine le transazioni e le inoltra ai peer nella rete di consenso sotto forma di proposte. Una proposta è un blocco senza segno condiviso dal servizio di ordinamento, che contiene un lotto di transazioni ordinate.

Le proposte vengono inoltrate solo quando il servizio di ordinamento ha accumulato abbastanza transazioni o è trascorso un certo periodo di tempo dall’ultima proposta. Ciò impedisce al servizio di ordinamento di inviare proposte vuote.

190214_Hyperledger - Lesson 03-06 - Step_3_of_Iroha_Transaction_Flow

Nozioni di base sul flusso di una transazione (Parte II)

Passaggio 4: Ogni peer verifica i contenuti della proposta (validazione stateful) nel simulatore e crea un blocco che consiste solo di transazioni verificate. Questo blocco viene quindi inviato al gate di consenso che esegue la logica di consenso YAC.

190214_Hyperledger - Lesson 03-07 - Step_4_of_Iroha_transaction_flow

Passaggio 5: viene determinato un elenco ordinato di peer e viene eletto un leader in base alla logica del consenso YAC. Ogni peer lancia un voto firmando e inviando il blocco proposto al leader.

190214_Hyperledger - Lesson 03-08 - Step_5_of_Iroha_transaction_flow

Passaggio 6: Se il leader riceve un numero sufficiente di blocchi proposti firmati (vale a dire più di due terzi dei peer), inizia a inviare un messaggio di commit (impegno), indicando che questo blocco deve essere aggiunto alla catena di ciascun peer che partecipa al consenso. Una volta inviato il messaggio di commit (impegno), il blocco proposto diventa il blocco successivo nella catena di ogni peer tramite il sincronizzatore.

190214_Hyperledger - Lesson 03-09 - Step_6_of_Iroha_Transaction_flow

YAC (Yet Another Consensus) - Funzioni di consenso

Hyperroger Iroha implementa attualmente un algoritmo di consenso chiamato YAC (Yet Another Consensus), che si basa sul voto per l’hash del blocco. Il consenso implica l’adozione di blocchi dopo la loro convalida, la collaborazione con altri blocchi per decidere sul commit (impegno) e la propagazione di commit (impegno) tra pari. Il consenso YAC svolge due funzioni: ordinamento e consenso.

L’ordinamento è responsabile dell’ordine di tutte le transazioni, del confezionamento in proposte e dell’invio ai peer del network. Il servizio di ordinamento è un endpoint per impostare un ordine di transazioni e la loro trasmissione (in una forma di proposta). L’ordinamento non è responsabile per l’esecuzione dello stato di convalida delle transazioni.

Nota: attualmente il servizio di ordinamento è un singolo punto di errore che esegue l’ordine e, pertanto, Hyperledger Iroha non è né resistente agli errori di blocco né tollerante all’errore bizantino.

Il consenso è responsabile per l’accordo sui blocchi basati sulla stessa proposta.

La validazione è una parte importante del flusso di transazioni, tuttavia è separata dal processo di consenso.

YAC - Passaggi per un consenso positivo

Passaggio 1: il servizio di ordinamento condivide una proposta per tutti i peer. Una proposta è un blocco senza segno creato e condiviso con i peer del network dal servizio di ordinamento. Contiene un lotto di transazioni ordinate.

Passaggio 2: I peer calcolano l’hash di una proposta verificata e lo firmano. La tupla <Hash, Signature> risultante viene chiamata votazione.

Passaggio 3: in base agli hash creati nel passaggio precedente, ciascun peer elabora un elenco di ordinazioni o un ordine di peer. Per fare ciò, la funzione di ordinamento dovrà avere conoscenza di tutti i peer che votano nella rete e si basa sull’hash del blocco proposto. Il primo peer nell’elenco è chiamato leader. Il leader è responsabile della raccolta di voti da altri colleghi e dell’invio del messaggio di commit (impegno).

Passaggio 4: Ogni peer vota. Il leader raccoglie tutti i voti e determina la maggioranza dei voti per un certo hash. Il leader invia un messaggio di commit (impegno) che contiene i voti del blocco di commit (impegno). Questa risposta è chiamata commit (impegno).

Passaggio 5: Dopo aver ricevuto il commit (impegno), i peer verificano il commit (impegno) e aggiungono il blocco al registro. A questo punto, il consenso è completo.

YAC - Mancato raggiungimento del consenso

Abbiamo appena coperto i passaggi necessari per raggiungere un consenso positivo, ma ci sono anche casi in cui può verificarsi un errore. Di seguito, tratteremo un paio dei casi di fallimento: rottura del leader e transazioni errate dal servizio di ordinamento.

Nel caso di una rottura del leader, il leader può agire ingiustamente nella raccolta di voti, o prende il leader troppo a lungo per rispondere con un commit (impegno). In tali situazioni, gli altri peer impostano un tempo per ricevere un messaggio di commit (impegno) dal leader. Se il timer scade, il peer successivo nella lista ordini diventa il nuovo leader.

In caso di transazioni errate dal servizio di ordinamento esso può inoltrare transazioni che non superano la stateless validation. Per correggere tutto ciò, i peer dovrebbero rimuovere tali transazioni dalla proposta e calcolare ulteriormente l’hash dal resto delle transazioni nella proposta.

Librerie mobili

Una delle caratteristiche più importanti di Hyperledger Iroha è il suo obiettivo nel fornire librerie mobili.

Uno dei principali obiettivi di Hyperledger Iroha è la creazione di un sistema di registro distribuito che possa essere facilmente utilizzato dalle applicazioni. Per ottenere ciò, Hyperledger Iroha offre librerie software open source per iOS, Android e Javascript. Queste librerie consentono una compatibilità semplice non solo con Hyperledger Iroha, ma anche, potenzialmente, con altre reti tramite funzioni API flessibili.

Se vuoi dare un’occhiata, queste librerie sono tutte open source e disponibili su Github:

Relazione con Hyperledger Fabric e Hyperledger Sawtooth

Uno degli obiettivi principali di Hyperledger in futuro è quello di avere progetti meno disgiunti e più librerie che possono essere utilizzate insieme come componenti. Con questa visione in mente, Hyperledger Iroha vuole eventualmente fornire i seguenti componenti C ++ che possono essere utilizzati da altri progetti Hyperledger:

  • Libreria di consenso YAC

  • Libreria di firma digitale Ed25519

  • Libreria di hashing SHA-3

  • Libreria di serializzazione delle transazioni Iroha

  • Libreria di comunicazione P2P

  • Libreria iOS

  • Libreria Android

  • Libreria JavaScript

  • Suite Blockchain Explorer / Data Visualization.