190214_Hyperledger - Lesson 04

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 4, capiremo:

  • Comprendere le basi di Hyperledger Sawtooth

  • Utilizzare la dimostrazione di uno scenario per evidenziare gli aspetti di Hyperledger Sawtooth

  • Comprendere le componenti cruciali di Hyperledger Sawtooth, inclusi l’algoritmo di consenso Proof of Elapsed Time, i processori di transazione, i batch e i validatori

  • Configurare una rete Hyperledger Sawtooth eseguibile e testare un’applicazione.

Una dimostrazione di scenario

Secondo il World Economic Forum:

“La pesca illegale, non dichiarata e non regolamentata rappresenta una perdita di circa 26 milioni di tonnellate per un valore di circa 24 miliardi di $ di pescato all’anno”

Ogni anno nel mondo vengono spesi tre trilioni di $ in risorse costiere marine e industrie. La pesca marina impiega oltre 200 milioni di persone, dalla pesca, alla lavorazione, alla spedizione, alle vendite.

Fino al 40% dei nostri oceani sono pesantemente colpiti dalla pesca illegale. Ogni anno vengono venduti cinque milioni di tonnellate di tonno, con un valore stimato di 40 miliardi di dollari. Si tratta di un settore enorme, che potrebbe beneficiare enormemente dell’innovazione e della trasparenza.

Con la dichiarazione di tracciabilità del tonno del 2020 ben in mente**, il nostro obiettivo è eliminare la pesca illegale, non dichiarata e non regolamentata.

Useremo, quindi, Hyperledger Sawtooth per portare trasparenza e chiarezza ad un esempio reale del mondo: la filiera della pesca del tonno. Descriveremo come migliorare la pesca del tonno, partendo dalla fonte, la pescatrice Sarah, e il processo con cui il suo tonno finisce nel ristorante di Miriam. Nel frattempo, avremo altre parti coinvolte, come il gestore del tonno e i regolatori, che verificheranno la validità dei dati e la sostenibilità della pesca del tonno.

Utilizzeremo il framework Hyperledger Sawtooth per tenere traccia di ogni parte di questo processo.

Introduciamo ora, in questa dimostrazione di scenario la gerarchia degli attori all’interno del network e al modo in cui questi attori interagiscono tra loro. Quando Sarah pesca il tonno da un’area designata dell’oceano, li etichetta tutti e prende nota della loro provenienza, passando oltre. Nel network Sawtooth, i regolatori, i gestori e i ristoratori possono confermare se una particolare spedizione di tonno è stata approvata in modo sostenibile e legale.

Definizione degli Attori

Sarah: la pescatrice di tonno che pesca il tonno sostenibilmente e legalmente

Impianto di trasformazione del tonno: trasforma e confeziona il tonno dopo che è stato pescato

Regolatori: verificano che il tonno sia stato pescato legalmente e in modo sostenibile

Miriam: proprietario di ristorante che fungerà da destinatario in questo scenario.

190214_Hyperledger - Lesson 04-02 - Sawtooth_demonstrated_scenario

Presentazione degli elementi di Hyperledger Sawtooth

Hyperledger è una piattaforma modulare per la creazione di reti e l’esecuzione di applicazioni di registri distribuiti. Sawtooth semplifica lo sviluppo delle applicazioni separando il sistema principale dal livello dell’applicazione. Gli sviluppatori di applicazioni possono specificare la logica di business per le loro applicazioni, utilizzando i linguaggi di programmazione di loro scelta, senza la necessità di conoscere il progetto di base del sistema principale.

I validatori Sawtooth convalidano le transazioni. I validatori sono responsabili della combinazione di lotti di transazioni in blocchi, della loro presentazione al registro e dell’approvazione dei blocchi validi in base all’algoritmo di consenso della rete.

Le applicazioni Sawtooth sono applicazioni distribuite, come i smart contract, che sono separate dal framework principale. Un’applicazione fornisce una famiglia di transazioni per definire le operazioni che possono essere applicate alle transazioni e il significato dei contenuti della transazione. Un’applicazione è costituita sia da un processore di transazione (la logica lato server) che uno o più client (per l’utilizzo dal Web, riga di comando CLI o applicazioni mobili).

I processori delle transazioni forniscono la logica di business lato server. La maggior parte dei nodi esegue diversi processori di transazione, uno per ogni caso d’uso specifico o applicazione. Ogni nodo nel network Sawtooth deve eseguire un insieme identico di processori di transazione.

I batch (lotti) sono gruppi di transazioni che sono presentate insieme. Un lotto può contenere una singola transazione o più transazioni correlate che sono tutte committed (impegnate) per essere dichiarate insieme. Se una transazione fallisce, anche le altre transazioni in quel lotto falliscono.

Il livello di rete è responsabile della comunicazione tra i validatori in una rete Sawtooth Hyperledger, tra cui l’esecuzione della connettività iniziale, l’individuazione dei peer e la gestione dei messaggi.

Lo stato globale contiene lo stato corrente del registro e una catena di chiamate di transazione. Lo stato di tutte le applicazioni in esecuzione sulla rete è rappresentato su ciascun nodo. Il processo di convalida della transazione su ciascun nodo garantisce che le stesse transazioni generino lo stesso stato di transizioni e che i dati del registro risultante siano gli stessi per tutti i partecipanti della rete. Lo stato è suddiviso in spazi dei nomi specifici delle applicazioni, che consentono agli autori delle applicazioni la flessibilità di definire, condividere e riutilizzare i dati dello stato globale tra i gestori delle transazioni.

Prova del Tempo Trascorso (Proof of Elapsed Time – PoET) è un algoritmo di consenso in Hyperledger Sawtooth che implementa il consenso basato sul tempo. PoET riduce il consumo di energia su reti distribuite di grandi dimensioni rispetto ad altri algoritmi come la Prova di Lavoro (Proof of Work – PoW).

Perchè Sawtooth?

Miriam è la proprietaria di un ristorante alla ricerca di tonno di alta qualità che sia stato cacciato in modo responsabile. Ogni volta che Miriam compra il tonno lei non potrà mai essere sicura se possa fidarsi o no che il tonno che sta acquistando sia stato pescato in modo sostenibile e legale, data l’importanza della pesca al tonno illegale e non dichiarata. Fortunatamente Hyperledger Sawtooth può essere di aiuto!

Hyperledger Sawtooth è l’ideale per questo scenario grazie alla sua capacità di tracciare la provenienza e il viaggio di un bene (in questo caso, il tonno). La possibilità di raggruppare le transazioni dei lotti consente di inserire tutto il tonno all’interno di una battuta di pesca nel suo complesso. L’accordo sullo stato distribuito, il nuovo algoritmo di consenso e la logica di business disaccoppiata dal livello consensuale consentono a Miriam di essere sicura che sta acquistando il tonno catturato legalmente.

La Catena di Approvvigionamento (Supply Chain)

Hyperledger Sawtooth è estremamente scalabile e in grado di resistere ad una elevata capacità di trasmissione (throughput) di dati, il che lo rende una grande opzione per scenari di supply chain di produzione.

Inizieremo con Sarah, la nostra pescatrice di tonno con licenza, che vende il suo tonno in più ristoranti. Sarah opera come un’impresa privata, e fa spesso affari internazionali. Attraverso un’applicazione, Sarah è in grado di ottenere l’accesso a una rete blockchain Hyperledger Sawtooth composta da altri pescatori, oltre ad impianti di trasformazione, regolatori e proprietari di ristoranti. Sarah, così come gli impianti di trasformazione, hanno la possibilità di aggiungere e aggiornare le informazioni del registro mentre il tonno passa attraverso la catena di approvvigionamento, mentre i regolatori e i ristoranti hanno accesso in lettura ai registri.

Il bene (asset) Tonno

Ad ogni pesca, Sarah registra alcune informazioni su ogni singolo tonno, tra cui un numero identificativo univoco (ID), la posizione e l’ora della pesca, il suo peso e chi ha catturato il pesce. Per semplicità, ci atteniamo a questi attributi dei dati. Tuttavia, in un’applicazione reale, molti altri dettagli sarebbero registrati, dalla tossicologia, ad altre caratteristiche fisiche, come la temperatura del tonno.

Questi dettagli vengono salvati nello stato globale come coppie chiave/valore basate sulle specifiche di un’applicazione Sawtooth, mentre il processore di transazione consente all’applicazione di Sarah di creare effettivamente una transazione sul registro.

Si prega di vedere l’esempio di seguito:

var tuna = {
__id: ‘0002’,
__holder: “Sarah”,
__location: {latitude: ’15 .623036831528264 ‘, longitude:’ -158.466796875 ‘},
__when: ‘20170635123546’,
__weight: ’58lbs’
}

Registrazione di una pesca

Dopo che Sarah ha pescato il suo tonno e registrato i dati per ogni tonno, è in grado di trattare una retata di tonno come un singolo lotto di transazioni. Come promemoria, un lotto è un gruppo di transazioni che si impegnano ad essere dichiarate insieme. Usando un lotto, Sarah è in grado di registrare molti tonni insieme, pur essendo in grado di specificare i dati per ciascun tonno. Se una delle transazioni di tonno non è valida, l’intera spedizione viene invalidata; cioè, nessun tonno all’interno del lotto di tonno è convalidato.

Raggiungere il Consenso

Dopo che un lotto di molte transazioni è stato inviato al network, l’algoritmo di consenso del network sceglie un nodo per pubblicare questo lotto come blocco sul registro (possibilmente insieme ad altri lotti). Se viene utilizzato l’algoritmo di consenso Proof of Elapsed Time – PoET, il validatore con il tempo di attesa più breve pubblica il blocco della transazione. (Ne parleremo più dettagliatamente più avanti nel corso.) Il blocco della transazione viene quindi trasmesso ai nodi di pubblicazione.

Ogni nodo all’interno del network riceve il blocco della transazione e i validatori verificano se la transazione è valida o meno. Se la transazione viene convalidata, lo stato globale viene aggiornato.

Hyperledger Sawtooth fornisce un accordo completo sullo stato distribuito, in cui ogni nodo del sistema ha la stessa comprensione delle informazioni. Con la maturazione della catena di approvvigionamento, i dati memorizzati rimangono coerenti attraverso il network.

Una volta regolato lo stato globale, l’impianto di trasformazione, il regolatore e Miriam sono in grado di vedere i dettagli della pesca e chi è il detentore attuale, mantenendo così la catena di approvvigionamento trasparente e verificabile.

Altri attori nella catena di approvvigionamento

Prima che il tonno di Sarah possa raggiungere il ristorante di Miriam, deve passare attraverso un impianto di lavorazione del tonno. Inoltre, i regolatori dovranno verificare e visualizzare i dettagli dal registro. Pertanto, entrambe le parti otterranno l’accesso a questa blockchain Sawtooth. I regolatori dovranno interrogare il registro mastro per confermare che Sarah sta legalmente pescando il suo pesce. Allo stesso tempo, gli impianti di lavorazione del tonno dovranno registrare la loro lavorazione e spedizione del tonno sul registro.

Riepilogo del flusso della catena di approvvigionamento

Ora facciamo il riepilogo del flusso della transazione.

190214_Hyperledger - Lesson 04-03 - Sarah_uses_the_client_application_to_record_all_caught_tuna_to_the_ledger

Sarah pesca un tonno e usa l’applicazione client per registrare tutti i dettagli sul pescato. Un’intera pescata di tonno può essere trattata come un lotto di transazioni, con ogni singolo tonno registrato come una transazione all’interno del lotto.

190214_Hyperledger - Lesson 04-04 - The_processing_plant_may_use_the_client_application_to_query_the_ledger

Dopo che i dettagli della cattura sono stati salvati nel registro e il tonno è passato lungo la catena di approvvigionamento, l’impianto di elaborazione può utilizzare l’applicazione client per interrogare il registro per i dettagli su catture specifiche, come il peso. L’impianto di lavorazione aggiungerà dettagli che riguardano la data e l’ora di elaborazione, nonché altre informazioni pertinenti.

190214_Hyperledger - Lesson 04-05 - Regulators_may_use_the_client_application_to_query_the_ledger__to_verify_legitimacy

Mentre il tonno passa lungo la catena di approvvigionamento, i regolatori possono utilizzare l’applicazione client per interrogare il registro per i dettagli su catture specifiche, come il proprietario e l’ubicazione del pescato, per verificarne la legittimità.

190214_Hyperledger - Lesson 04-06 - Miriam_can_use_the_client_application_to_query_the_ledger

Infine, quando il tonno arriva al ristorante di Miriam, Miriam è in grado di utilizzare l’applicazione client per interrogare il registro, per assicurarsi che Sarah fosse sincera nel suo resoconto di dove ogni pesce è stato acquistato. Questo, a sua volta, garantisce che il ristorante di Miriam serva i propri clienti un tonno pescato in modo sostenibile.

Componenti chiave e Flusso di Transazione

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

Hyperledger Sawtooth è un framework blockchain con potenzialità nell’IoT, nella produzione, nella finanza e nell’impresa. Hyperledger Sawtooth supporta diversi requisiti, tra cui sia distribuzioni con permesso che senza permesso e un algoritmo di consenso collegabile. Questo framework fornisce anche un algoritmo di consenso rivoluzionario, Proof of Elapsed Time (PoET), che consente versatilità e scalabilità adatte a una varietà di soluzioni.

Hyperledger Sawtooth supporta molti requisiti infrastrutturali diversi, come ad esempio:

  • Infrastruttura con permesso e senza permesso
  • Architettura modulare blockchain
  • Scalabilità, che è utile per reti blockchain più grandi a causa di un throughput più elevato
  • Molte lingue per la logica delle transazioni
  • Governance on-chain che consente ai peer di votare sulla configurazione blockchain
  • Un avanzato motore di esecuzione delle transazioni in grado di elaborare transazioni in parallelo per accelerare la creazione e la convalida dei blocchi
  • Supporto contrattuale di Ethereum con Seth, che consente ai partecipanti di eseguire contratti intelligenti Solidity e di integrarsi con gli strumenti di Ethereum
  • Il consenso dinamico consente di aggiornare o scambiare al volo il protocollo di consenso della blockchain man mano che la rete cresce.

Transazione del Lotto

In Hyperledger Sawtooth, i lotti (batch) sono gruppi di transazioni che si impegnano ad essere dichiarati insieme. Se non è possibile eseguire il commit (l’impegno) di una transazione nel batch (lotto), nessuna delle transazioni viene impegnata. Di conseguenza le transazioni dei lotti sono spesso descritti come un’unità atomica di cambiamento, dal momento che un gruppo di transazioni viene considerato come una sola, e sono impegnate nello stato come una sola. Ogni singola transazione in Hyperledger Sawtooth viene inviata all’interno di un lotto.

I lotti possono contenere un minimo di una singola transazione.

Quando una transazione viene creata da un client, il lotto viene inviato al validatore (che approfondiremo nella prossima lezione). Le transazioni sono organizzate in un lotto nell’ordine in cui devono essere eseguite. Il validatore quindi, a sua volta, applica ogni transazione all’interno del lotto, portando a una modifica dello stato globale. Il lotto è committed (impegnato) nello stato. Se una transazione all’interno del batch non è valida, nessuna delle transazioni all’interno di quel batch viene impegnata.

In sintesi, la transazione dei lotti consente di applicare un gruppo di transazioni in un ordine specifico e, in caso contrario, nessuna delle transazioni viene applicata. Questo è uno strumento potente che può essere utilizzato da molte soluzioni aziendali, in quanto fornisce maggiore efficienza e controllo per gli utenti finali.

Validatori

In qualsiasi rete blockchain, la modifica dello stato globale richiede la creazione e l’applicazione di una transazione. In Hyperledger Sawtooth, i validatori applicano transazioni di lotti che causano cambiamenti nello stato. Più specificamente, i validatori raggruppano i lotti in blocchi, inviano i blocchi e assicurano che le transazioni generino cambiamenti di stato coerenti tra tutti i partecipanti alla rete.

Per iniziare, un utente crea un batch contenente una o più transazioni e lo invia a un validatore, solitamente tramite un client che comunica con un REST API. Il validatore controlla quindi le transazioni e applica il batch se tutte le transazioni sono considerate valide, determinando una modifica dello stato. In termini del nostro scenario dimostrato, Sarah, la pescatrice di tonno, crea un lotto per registrare informazioni su un gruppo di pesche di tonno. Il validatore applica quindi le transazioni e lo stato viene aggiornato se sono presenti tutti gli attributi appropriati: un numero ID univoco, la posizione e l’ora della pesca, il peso e chi ha pescato il pesce. Se uno di questi elementi manca, le transazioni all’interno del batch non verranno applicate e lo stato non verrà aggiornato.

190214_Hyperledger - Lesson 04-07 - Hyperledger_Sawtooth_Components

Interfaccia del Consenso

Una caratteristica chiave di Hyperledger Sawtooth è la sua flessibilità nel consentire diversi algoritmi di consenso. Come promemoria, l’algoritmo di consenso determina quale nodo sulla rete pubblicherà il blocco successivo sul registro. Hyperledger Sawtooth fornisce un’interfaccia astratta che supporta algoritmi sia in stile PBFT che in stile Nakamoto. Il consenso in Hyperledger Sawtooth è modulare, il che significa che l’algoritmo di consenso può essere facilmente modificato.

Attualmente, Hyperledger Sawtooth supporta le seguenti implementazioni di consenso:

  • Proof of Elapsed Time (Prova di tempo trascorso), o PoET, un algoritmo di consenso in stile Nakamoto progettato per essere un protocollo di livello produttivo in grado di supportare network di grandi dimensioni.
  • Dev mode, un algoritmo a leader casuale, semplificato, utile per lo sviluppo e il test su reti a nodo singolo o di piccole dimensioni.

PoET è disponibile in due versioni:

  • PoET-SGX, che si affida a Intel® Software Guard Extensions (SGX) per implementare un sistema di lotterie leader-election
  • Simulatore PoET, che è l’algoritmo di consenso del PoET implementato su un simulatore SGX.

Introduzione a Proof of Elapsed Time (PoET)

L’algoritmo di consenso Proof of Elapsed Time (PoET) determina in modo imparziale chi impegnerà una transazione nello stato usando una funzione di lotteria che elegge un leader tra molti nodi distribuiti diversi.

L’algoritmo PoET di Hyperledger Sawtooth si differenzia dall’algoritmo Proof of Work implementato dalla blockchain di Bitcoin in quanto PoW si basa su enormi quantità di energia (computazionale), mentre PoET è in grado di assicurare fiducia e casualità nell’eleggere un leader senza l’elevato consumo energetico. PoET consente maggiore scalabilità e partecipazione, poiché ogni nodo della rete ha le stesse opportunità di creare il prossimo blocco sulla catena.

Come funziona PoET

Per iniziare, ogni validatore all’interno del network richiede un tempo di attesa da un’enclave o da una funzione attendibile. È qui che entra in gioco il “Tempo trascorso”. Il validatore con il tempo di attesa più breve per un blocco specifico viene nominato leader e crea il blocco da impegnare nel registro. Di conseguenza, viene eletto un leader veramente casuale, e la quantità di potenza o tipo di hardware che hai non ti darà un vantaggio. Usando semplici funzioni, la rete può verificare che il validatore vincente abbia effettivamente “vinto”, dimostrando che ha avuto il tempo di attesa più breve prima di assumere la posizione di leadership.

Fork

Se PoET fornisce molti vantaggi e aiuta enormemente con la scalabilità, esso ha un suo lato negativo: il problema delle Fork (biforcazioni della blockchain). L’algoritmo PoET può portare alla biforcazione, in cui due “vincitori” propongono un blocco. Ogni fork deve essere risolto dai validatori e ciò comporta un ritardo nel raggiungimento della coerenza attraverso la rete.

Applicazioni Sawtooth

Come in ogni framework blockchain, gli aggiornamenti delle transazioni devono essere approvati e condivisi tra molte parti non fidate. In Hyperledger Sawtooth, la logica di business per un’applicazione, il modello di dati utilizzato per registrare e archiviare i dati di stato e la logica del client sono definiti come un’applicazione Sawtooth, detta anche famiglia di transazioni. Un’applicazione è composta sia da un processore di transazione (la logica lato server) che da uno o più client (per l’utilizzo dal Web, dalla riga di comando CLI o dalle applicazioni mobili).

Una famiglia di transazioni definisce un insieme di operazioni o tipi di transazione consentiti sui libri mastro condivisi. Ciò consente flessibilità nel livello di versatilità e rischio esistente su una rete. Le famiglie di transazioni possono fornire contratti intelligenti “più sicuri”, in quanto specificano un insieme predefinito di modelli di contratto intelligenti accettabili, al contrario di programmare contratti intelligenti da zero.

190214_Hyperledger - Lesson 04-08 - Sawtooth_Application

Processore di Transazione

Un processore di transazione fornisce la logica di business lato server che opera su risorse all’interno di una rete. Poiché Hyperledger Sawtooth separa il livello applicativo dal livello di consenso e core framework, le aziende sono in grado di sviluppare processori di transazione che fanno esattamente ciò di cui hanno bisogno le loro applicazioni.

Ogni nodo all’interno della rete Hyperledger Sawtooth esegue almeno un processore di transazione (la maggior parte delle reti ne esegue diverse). Ogni processore di transazione gestisce le proprie transazioni in entrata inviate dai clienti autorizzati. Hyperledger Sawtooth consente agli sviluppatori di applicazioni di specificare uno spazio dei nomi per ogni processore di transazione (un intervallo di indirizzi specifici dell’applicazione in stato), che offre flessibilità nella definizione, condivisione e riutilizzo dei dati tra processori di transazione. L’utilizzo dello spazio dei nomi nello stato globale consente ai programmatori di concentrarsi sullo sviluppo della logica dell’applicazione, anziché costruire meccanismi di comunicazione tra processori di transazione.

I processori di transazione di Sawtooth di Hyperledger possono essere scritti in una varietà di lingue, tra cui Javascript, Java, Rust, Python e Go, che consentono alle aziende di creare liberamente le proprie applicazioni. Hyperledger Sawtooth fornisce SDK in diverse lingue comuni.

Più avanti in questa lezione, nella sezione Scrittura di un’applicazione, esploreremo esattamente come i processori di transazione interagiscono con un client e altri componenti di Sawtooth Hyperledger.

Nodo Sawtooth

Ogni organizzazione che accede alla rete Hyperledger Sawtooth esegue almeno un nodo di convalida e riceve blocchi trasmessi da nodi peer.

Ogni nodo di validazione esegue le seguenti operazioni:

  • Il processo di validazione
  • Il REST API (opzionale) in ascolto di richieste quali post di transazione o query di stato
  • Uno o più processori di transazione

Una REST API su ciascun nodo è facoltativa. I client possono utilizzare un a REST API esterna o comunicare direttamente con il validatore utilizzando ZeroMQ e buffer di protocollo (protobufs).

190214_Hyperledger - Lesson 04-09 - Sawtooth_Network

Installare Hyperledger Sawtooth

Prerequisiti tecnici

Per una installazione con successo di Hyperledger Sawtooth, è necessario avere I seguenti software installati sul tuo computer: cURL, Git, Docker, and Docker Compose. Per maggiori dettagli sui prerequisiti leggere i Requisiti Tecnici nelle Lezioni precedenti.

Installazione di Hyperledger Sawtooth

Hyperledger Sawtooth è una suite che consente la creazione e l’utilizzo di un registro distribuito. L’installazione di Hyperledger Sawtooth coinvolgerà l’aggiunta di chiavi di firma per il creatore del software nel nostro ambiente, incluso il repository che contiene il codice nel nostro sistema e che esegue un tipico aggiornamento / installazione.

Un nodo di convalida Sawtooth Hyperledger può essere eseguito sia da pre-built Docker images, sia nativamente utilizzando Ubuntu 16.04. In questo tutorial, dimostreremo come configurare Hyperledger Sawtooth usando Docker.

Il nostro esempio in ambiente Sawtooth è un singolo nodo di validazione che utilizza il consenso Dev mode, una REST API, tre processori di transazione e un contenitore client.

Avvio di Hyperledger Sawtooth

Innanzitutto, scarica il seguente file Docker Compose sawtooth-default.yaml:

https://raw.githubusercontent.com/hyperledger/education/master/LFS171x/sawtooth-material/sawtooth-default.yaml

Aprire una finestra di terminale.

Modificare la directory di lavoro nella stessa directory in cui è salvato il file Docker Compose
sawtooth-default.yaml.

Nota: assicurarsi di non avere altro in esecuzione sulla porta 8008 o sulla porta 4004. Inoltre, assicurati che Docker sia in esecuzione sul dispositivo prima di eseguire i comandi di questa sezione. Altrimenti, quando esegue docker-compose nel passaggio successivo, si otterrà un errore simile a quello seguente:

ERROR: Couldn’t connect to Docker daemon.
You might need to start Docker for Mac.

Eseguire il seguente comando:

$ docker-compose -f sawtooth-default.yaml up

Questo comando scaricherà Docker images che comprende la demo dell’ambiente Hyperledger Sawtooth. Il download richiederà alcuni minuti. Il terminale inizierà a visualizzare i container che si registrano e creano i blocchi iniziali.

Accesso al container del client

Il container del client viene utilizzato per eseguire comandi Sawtooth, che vengono utilizzati per configurare la rete Sawtooth ed eseguire le funzioni client dalla riga di comando.

Aprire una nuova finestra di terminale e andare alla directory in cui è stato salvato il file Docker Compose sawtooth-default.yaml

Accedere al container client eseguendo il seguente comando:

$ docker exec –it sawtooth-shell-default bash

Nel terminale verrà visualizzato qualcosa di simile al seguente:

root@75b380886502:/#

L’ambiente è ora configurato e si può iniziare a sperimentare con la rete. Ma prima, bisogna confermare che il proprio validatore è attivo e funzionante e raggiungibile dal container del client. Per fare ciò, eseguire il seguente comando:

$ curl http://rest-api:8008/blocks

Dopo aver eseguito questo comando, dovrebbe apparire una risposta dell’oggetto json con “data”, matrice di lotto, intestazione, ecc.

Per verificare la connettività dall’host del computer container Docker, eseguire il seguente comando in una nuova finestra di terminale (non è necessario che sia la stessa directory menzionata in precedenza in questa sezione):

$ curl http://localhost:8008/blocks

Dopo aver eseguito questo comando, si dovrebbe vedere una risposta dell’oggetto json con “data”, matrice di lotto, intestazione, ecc.

Arresto di Hyperledger Sawtooth

Per prima cosa, premi Ctrl+C dalla finestra in cui hai eseguito originariamente docker-compose.

Nel terminale, vedrai i container fermarsi. Quindi, eseguire il seguente comando:

$ docker-compose -f sawtooth-default.yaml down

Scrivere un'Applicazione

Applicazioni

In un’applicazione Sawtooth, il libro mastro memorizzerà lo stato del sistema, oltre alla registrazione immutabile delle transazioni che hanno creato tale stato. Un’applicazione è in genere costituita da due parti:

  • Applicazione client
    Invia le transazioni alla blockchain, in genere tramite l’API REST di Sawtooth.
    Fornisce un’interfaccia utente per l’applicazione. Un client può essere un’interfaccia a riga di comando, una pagina Web, un’app mobile, un sensore IoT o la maggior parte degli altri tipi di interfaccia in grado di inviare richieste HTTP.
  • Processore di transazioni
    Codifica la logica aziendale dell’applicazione.
    Comunica con il validatore, che invia le transazioni ricevute dal client al processore di transazione per la convalida.

Finora, in questo capitolo, abbiamo trattato i componenti del framework Hyperledger Sawtooth, compreso l’algoritmo di verifica della durata del tempo trascorso, famiglie di transazioni e lotti.
Abbiamo anche installato e attivato la nostra rete di test e abbiamo analizzato un esempio dimostrativo di come Sawtooth sia unico.

Ora è il momento di combinare ciò che abbiamo imparato in un esempio codificato.
Gli SDK Sawtooth offrono supporto per sviluppatori di famiglie di transazioni per Javascript, Python, C, C ++, Java e Go.
Per creare la nostra semplice applicazione, utilizzeremo l’SDK Javascript, che fornisce funzionalità client e fornisce il processo di apportare modifiche alla blockchain.
Se desideri approfondire maggiormente questi dettagli pesanti, i dettagli tecnici, tieniti aggiornato su un futuro corso su Sawtooth.
Ora, prima di entrare in questa sezione, vorrei dare una breve panoramica.
La creazione di un’applicazione richiede alcuni passaggi importanti: in primo luogo, la definizione delle risorse che risiedono nel libro mastro distribuito, nonché le transazioni che agiranno su tali risorse per modificarne lo stato; in secondo luogo, progettare la logica delle transazioni che opera su queste risorse.
Ora, poiché le transazioni vengono ricevute da un nodo Sawtooth, vengono inoltrate ad altri nodi.
Un nodo è selezionato da un modello di consenso per pubblicare un blocco.
Il blocco conterrà tutte le transazioni che sono state ricevute ed eseguite con successo.

Il blocco viene quindi trasmesso ai nodi di pubblicazione.
Ogni nodo sawtooth riceve un blocco pubblicato e verifica che quel blocco sia valido.
Quindi notifica la nostra applicazione di eventuali cambiamenti di stato.
Alla fine di questa sezione, avremo familiarità con l’utilizzo dell’SDK JavaScript per interagire con una rete Sawtooth e scrivere la logica del codice per creare transazioni contenenti informazioni sugli oggetti fisici.
Ora sei pronto per iniziare questa sezione!

Recensione dei componenti di Hyperledger Sawtooth

I validatori Sawtooth convalidano le transazioni, combinano i batch (lotti) di transazioni in blocchi, li inoltrano al libro mastro e approva i blocchi validi in base all’algoritmo di consenso della rete.

Le applicazioni Sawtooth sono applicazioni distribuite (chiamate anche famiglie di transazioni) costituite da un processore di transazione per la logica lato server e un client per l’utilizzo da applicazioni Web, CLI o mobili.

I processori delle transazioni forniscono la logica di business lato server.

I batch (lotti) sono gruppi di transazioni presentate insieme. Se una transazione fallisce, anche le altre transazioni in quel batch falliscono.

Il livello di rete è responsabile della comunicazione tra i nodi di convalida in una rete Sawtooth Hyperledger, tra cui l’esecuzione della connettività iniziale, l’individuazione dei peer e la gestione dei messaggi.

Lo stato globale contiene lo stato corrente del libro mastro e una catena di chiamate di transazione. Lo stato per tutte le applicazioni in esecuzione sulla rete s è rappresentato su ciascun nodo. Lo stato è suddiviso in spazi dei nomi specifici dell’applicazione, che consente alle applicazioni di condividere e riutilizzare i dati dello stato globale tra processori di transazione.

Applicazione Sawtooth di TunaChain

Facciamo bagnare i piedi con un esempio di una semplice applicazione blockchain Hyperlingger Sawtooth che si riferisce allo scenario di fornitura del tonno che abbiamo discusso nel nostro scenario dimostrato. Sawtooth TunaChain consente a un utente di creare risorse denominate (tonno) e trasferirle tra diversi titolari designati da una chiave pubblica.

Nel nostro esempio, vedremo:

  • Un processore di transazione
  • Un semplice client basato su browser.

Il processore di transazione TunaChain viene scritto utilizzando l’SDK Sawtooth Python 3. Si interfaccia con un validatore Sawtooth per convalidare le transazioni.
Il client è una semplice interfaccia utente basata su browser scritta utilizzando l’SDK JavaScript Sawtooth. Consente all’utente di gestire coppie di chiavi pubbliche / private e inviare transazioni utilizzando l’API REST di Sawtooth.

Clonare il Repository

Se non lo hai fatto, devi clonare il repository GitHub hyperledger/education. Questo repository contiene il codice per l’applicazione di esempio Sawtooth TunaChain.
Per clonare il repository, aprire una finestra di terminale, accedere alla cartella dei progetti e immettere i seguenti comandi:

$ git clone https://github.com/hyperledger/education.git

$ cd education/LFS171x/sawtooth-material/sawtooth-tuna

Ora sei nella cartella che contiene il codice per l’esempio di Sawtooth TunaChain.

La Struttura dei file dell'Applicazione TunaChain

Qui puoi vedere la struttura dei file dell’applicazione Sawtooth TunaChain:

190214_Hyperledger - Lesson 04-10 - File_structure_of_TunaChain_Application

Avviare l'Applicazione

Assicurati di avere Docker in esecuzione sul tuo computer prima di eseguire il comando successivo. Se non hai installato Docker, dovresti rivedere il Capitolo 4, Requisiti tecnici.

Nota: assicurati di essere nella cartella sawtooth-tuna
Utilizzeremo il file docker-compose.yaml fornito per creare ed eseguire i contenitori Docker per i componenti Sawtooth e TunaChain necessari.
Esegui il seguente comando per avviare Sawtooth con la nostra applicazione TunaChain:

$ docker-compose up

A questo punto, la finestra del terminale dovrebbe mostrare che questi contenitori sono in esecuzione: sawtooth-validator, tunachain-shell, sawtooth-settings-tp, tunachain-tp,
sawtooth-rest-api
e tunachain-client.

Dovresti anche vedere i messaggi che mostrano che sawtooth-settings-tp e tunachain-tp si sono registrati con il validatore, che l’API REST è connessa al validatore alla porta 4004 e che il client è stato costruito all’interno del contenitore del tunachain-shell.

Se tutte queste condizioni sono vere e non si verificano altri errori, è stata avviata correttamente una rete Sawtooth a nodo singolo con l’applicazione demo TunaChain.

Lo Stato dell'Applicazione TunaChain

Esistono due tipi di voci di stato all’interno dell’applicazione TunaChain: Risorse e Trasferimenti. Queste voci di stato sono rappresentate come oggetti JSON con codifica UTF-8 con chiavi ordinate.

Le voci dello stato delle Risorse sono formattate come segue:

{
__# Name of the Asset
__“name”: “name”,
}

Le voci dello stato delle Trasferimenti sono formattate come segue:

{
__# Name of the Asset
__“asset”: “asset”,

__# Public key of the proposed recipient of the Asset
__“owner”: “owner”,
}

Sawtooth TunaChain Addressing

In Hyperledger Sawtooth, gli spazi dei nomi definiscono lo schema di indirizzamento per i dati dell’applicazione. Tutte le applicazioni di Sawtooth memorizzano i dati nel dizionario di stato con indirizzi a 35 byte (70 caratteri esadecimali). Gli indirizzi per le risorse di TunaChain sono generati come segue:

  1. I primi 3 byte di qualsiasi indirizzo di stato di Sawtooth sono riservati per lo spazio dei nomi dell’applicazione. Per l’applicazione TunaChain, il prefisso dello spazio dei nomi viene generato prendendo i primi 6 caratteri di un hash SHA-512 del nome dell’applicazione “catena di trasferimento”:
    19d832
  2. Il byte successivo di un indirizzo TunaChain specifica quale tipo di risorsa è memorizzata all’indirizzo:

    Risorsa
    00

    Trasferimento
    01
  3. Gli ultimi 31 byte di un indirizzo TunaChain sono i primi 62 caratteri di un hash SHA-512 del nome della Risorsa.

Ad esempio, l’indirizzo TunaChain di un asset con il nome “tuna4” verrebbe generato come segue:

>>> hashlib.sha512(‘transfer-chain’.encode(‘utf-8’)).hexdigest()[:6] +
’00’ + hashlib.sha512(‘tuna4’.encode(‘utf-8’)).hexdigest()[:62]
’19d83200714923803714eeb557276759eab2ce605c929dee093e7aa4359ee6f29a8880′

Sawtooth TunaChain Transaction Payload

Ogni payload della transazione TunaChain è rappresentato come un oggetto JSON con il seguente formato:

{
__# Action the transaction takes, either “create”, “transfer”, “accept”, or
__# “reject”
__“action”: “action”,

__# Name of the Asset to be affected by the transaction
__“asset”: “asset”,

__# Public key of the proposed new owner for a “transfer” transaction
__“owner”: “owner”
}

Browser Client

Ora siamo pronti a testare la nostra applicazione attraverso l’interfaccia utente. Per utilizzare l’applicazione client TunaChain, utilizzare un browser per navigare a localhost: 8000.

Ci sono quattro cose diverse che possiamo fare all’interno dell’applicazione:

  • Seleziona titolare ci consente di selezionare una chiave pubblica o creare una nuova coppia di chiavi pubblica/privata, a cui viene fatto riferimento come Titolare

  • Crea Tuna Record invia una transazione per creare una nuova voce di Tuna nello stato, che è detenuta dal Titolare attualmente selezionato

  • Transfer Tuna invia una transazione per creare una nuova (voce di) Trasferimento nello stato, che può essere accettata o rifiutata dal potenziale destinatario della risorsa Tuna

  • Accetta Tonno mostra un elenco dei Trasferimenti correnti con il Titolare attualmente selezionato elencato come destinatario, nonché le opzioni di Accept o Reject (Rifiuta) il Trasferimento.

Inoltre, c’è una tabella Lista Tonno che mostra tutte le attuali risorse (asset) Tuna attuali nello stato con i rispettivi Titolari.

Nota: l’applicazione è in esecuzione all’interno del contenitore Docker del tunachain-client, ma la porta su cui è in esecuzione è esposta alla porta 8000 sul computer host.

Creazione di un Nuovo Titolare

Per inviare transazioni al REST API, è necessario creare un nuovo Titolare. Per l’applicazione TunaChain, i Titolari sono solo coppie di chiavi pubbliche/private che vengono archiviate nella memoria locale del browser.

All’interno dell’interfaccia utente, è possibile creare queste chiavi dall’elenco a discesa Seleziona Titolare. È possibile utilizzare questo stesso elenco a discesa per passare da più utenti nella memoria locale.

190214_Hyperledger - Lesson 04-11 - Tuna_Holder_drop_down
190214_Hyperledger - Lesson 04-12 - Tuna_Create_New_Key_Pair

Questo elemento dell’interfaccia utente richiama la seguente funzione all’interno del codice client:

// Select User
$(‘[name=”keySelect”]’).on(‘change’, function () {
__if (this.value === ‘new’) {
____app.user = makeKeyPair()
____app.keys.push(app.user)
____saveKeys(app.keys)
____addOption(this, app.user.public, true)
____addOption(‘[name=’transferSelect”]’, app.user.public)
__} else if (this.value === ‘none’) {
____app.user = null
__} else {
____app.user = app.keys.find(key => key.public ===this.value)
____app.refresh()
}

app.js:  Select User

//Create new key-pair
const makeKeyPair = () => {
__const context = createContext(‘secp256k1’)
__const privateKey = context.newRandomPrivateKey()
__return {
____public: context.getPublicKey(privateKey).asHex(),
____private: privateKey.asHex()
__}
}

state.js:  makeKeyPair

Questa funzione utilizza l’SDK Client Signing di JavaScript per creare una chiave privata casuale a 256 bit rappresentata come una stringa esadecimale a 64 caratteri. Questa chiave non dovrebbe essere condivisa con nessun altro.
Successivamente, la funzione deriva una chiave pubblica dalla chiave privata a 256 bit creata sopra. Questa è la chiave che è sicura da condividere.
Restituisce questa coppia di chiavi all’applicazione, dove chiama la seguente funzione per salvare la coppia di chiavi nella memoria locale:

//Save key-pairs to localStorage
const saveKeys = keys => {
__const paired = keys.map(pair => [pair.public, pair.private].join(‘,’))
__localStorage.setItem(KEY_NAME, paired.join(‘;’))
}

state.js:  saveKeys

Nota: questo metodo di salvataggio della coppia di chiavi è solo a scopo dimostrativo. Questo metodo non è consigliato per un ambiente di produzione.

Creare un Record Tuna

All’interno dell’interfaccia utente, selezionare il proprietario della nuova risorsa nel menu a discesa Seleziona Titolare, quindi fornire un nome univoco per il tonno nella casella di testo Crea Record Tuna. Infine, fai clic sul pulsante Crea.

190214_Hyperledger - Lesson 04-13 - Tuna_Create

Dopo aver fatto clic sul pulsante Crea, la seguente funzione viene chiamata all’interno del client:

//Create Asset
$(‘#createSubmit’).on(‘click’, function () {
__const asset = $(‘#createName’).val()
__if (asset) app.update(‘create’, asset)
})

apps.js: Create Asset

Ogni elemento dell’interfaccia utente che deve apportare una modifica allo stato chiamerà la funzione app.update (). Questa funzione formatta il carico utile della transazione e lo invia alla funzione submitUpdate () in state.js.

app.update = function (action, asset, owner) {
__if (this.user) {
____submitUpdate(
____{ action, asset, owner },
____this.user.private,
____success => success ? this.refresh() : null
____)
__}
}

app.js: app.update()

La funzione submitUpdate () gestisce il processo di creazione di una transazione, aggiungendola a un batch, inoltrando il batch all’API REST e attendendo una risposta.
Se la transazione è stata eseguita correttamente dal processore di transazione, aggiunta a un blocco e pubblicata dal validatore, lo stato verrà aggiornato con la nuova voce. Dopo aver aggiornato la pagina, vedrai la Risorsa tonno visualizzata nel Tuna List (Elenco Tonni), insieme alla chiave pubblica del Titolare associato.

190214_Hyperledger - Lesson 04-14 - Tuna_List

Trasferire un Tuna

Qualsiasi Risorsa assegnata a un particolare Titolare può essere trasferita a un altro Titolare usando il menu a scomparsa Transfer Tuna.
Si noti che il trasferimento deve essere accettato dal destinatario prima di essere finalizzata.

190214_Hyperledger - Lesson 04-15 - Tuna_Transfer

Nell’esempio sopra, stiamo proponendo di trasferire la proprietà di tuna4 dal proprietario corrente (identificato dalla chiave che inizia con 02ddf8de…) a un nuovo proprietario (identificato dalla chiave che inizia con 03b241b1…

).

Dopo aver fatto clic sul pulsante Trasferisci, la seguente funzione viene chiamata all’interno del client:

//Transfer Asset
$(‘#transferSubmit’).on(‘click’, function () {
__const asset = $(‘[name=”assetSelect”]’).val()
__const owner = $(‘[name=”transferSelect”]’).val()
__if (asset && owner) app.update(‘transfer’, asset, owner)
})

apps.js: Transfer Asset

Questa funzione chiama app.update (), che a sua volta chiama submitUpdate () per inviare la transazione per creare una nuova voce di Trasferimento in stato.

Accettare o Rigettare i Trasferimenti

Una volta creato un Trasferimento, vai al menu a discesa Seleziona Titolare e seleziona la chiave pubblica del potenziale destinatario. Questo ricaricherà la pagina e popolerà la sezione Accept Tuna con tutti i Trasferimenti in stato con il Holder selezionato come potenziale destinatario, come mostrato di seguito:

190214_Hyperledger - Lesson 04-16 - Accept_Tuna

Facendo clic su Accetta o Rifiuta invocherà una delle seguenti funzioni:

//Accept Asset
$(‘#transferList’).on(‘click’, ‘.accept’, function () {
__const asset = $(this).prev().text()
__if (asset) app.update(‘accept’, asset)

})

app.js: Accept Asset

//Reject Asset
$(‘#transferList’).on(‘click’, ‘.reject’, function () {
__const asset = $(this).prev().prev().text()
__if (asset) app.update(‘reject’, asset)
})

app.js: Reject Asset

Dopo aver accettato o rifiutato il Trasferimento, il Trasferimento verrà rimosso dalla sezione Accettare il Tonno. Se il Trasferimento è stato accettato, la tabella Lista Tonno verrà aggiornata per mostrare il nuovo proprietario. Se è stato rifiutato, la tabella Lista Tonno sarà invariata per indicare che il trasferimento non è stato effettuato.

Processore di Transazioni TunaChain

Per verificare, ci sono due componenti principali di un processore di transazioni:

  • Classe TransactionProcessor
    Una classe generica fornita dall’SDK di Sawtooth. Gestisce la connessione tra il processore della transazione e il validatore.

  • Classe TransactionHandler
    Una classe base che viene estesa con una logica di convalida specifica per ogni applicazione. Oltre a diversi metodi di metadati, ha un metodo apply () che comprende la logica per la convalida e l’esecuzione di una transazione.
    Il metodo apply () viene chiamato con due argomenti, transaction e context. L’argomento transaction contiene il comando che deve essere eseguito, mentre il context memorizza le informazioni sullo stato corrente.

Per separare i dettagli della codifica di stato e della gestione del carico utile dalla logica di convalida, il processore di transazione TunaChain utilizza due classi aggiuntive:

  • TunachainPayload ha i campi action, asset e owner ed è responsabile della convalida che il carico utile della transazione sia stato formato correttamente.

  • TunachainState contiene un riferimento al context e dispone di metodi aggiuntivi per la generazione di indirizzi di stato, oltre a ottenere e impostare i valori nello stato.

Il codice per il processore di transazione TunaChain può essere trovato qui

Questa funzione chiama app.update (), che a sua volta chiama submitUpdate () per inviare la transazione per creare una nuova voce di Trasferimento in stato.

Chiudere Sawtooth

Nota: Una volta terminato questo tutorial, eseguire il seguente comando per arrestare i contenitori Docker che eseguono i componenti Sawtooth:

$ docker-compose down

Sommario del flusso dell'Applicazione TunaChain

L’applicazione TunaChain di esempio mostra le funzionalità di Sawtooth Hyperledger con un semplice client basato su browser per l’interfaccia utente e un processore di transazione per la logica di business.

190214_Hyperledger - Lesson 04-17 - Application_Flow

Hyperledger Sawtooth consente alle entità di aggiornare e leggere in modo sicuro il registro distribuito senza coinvolgere un’autorità centrale. Gli sviluppatori creano la logica di business dell’applicazione e del processore di transazione (contratto intelligente).
Attraverso l’applicazione client, gli utenti (tonno pescatore, regolatore, ristorante) sono in grado di modificare lo stato creando e applicando transazioni.
Attraverso un’API REST, l’applicazione client crea un batch contenente una singola transazione e lo invia al validatore.
Il validatore applica la transazione utilizzando il processore di transazione, che apporta una modifica allo stato (ad esempio, creando un record di una pesca di tonno).