Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Blockchain: Analisi ed Implementazione di un
Caso d’Uso Mediante Smart Contract
Tesi di laurea
Relatore
Ch.mo Prof. Francesco Ranzato
Laureando
Federico Brian
Matricola 1122698
Anno Accademico 2018-2019
Federico Brian: Blockchain: Analisi ed Implementazione di un Caso d’Uso Mediante Smart Contract, Tesi di laurea, c 17 Settembre 2019.
“Fare le cose vecchie in modo nuovo - questa è innovazione.”
Joseph Alois SchumpeterAbstract
La tecnologia blockchain è ancora in fase nascente, tuttavia sta suscitando un considerevole
interesse. Nata dal genio di Satoshi Nakamoto, pseudonimo che può rappresentare un individuo
od una collettività, questa innovazione è finalizzata allo sviluppo di un sistema di pagamento
online, sicuro e indipendente da qualsiasi tipo di autorità centrale.
Con il presente documento, il laureando Federico Brian descrive il lavoro svolto durante il
periodo di stage avvenuto presso l’azienda Sync Lab S.R.L. nella sede di Padova, il cui scopo
era: analizzare lo stato dell’arte della tecnologia blockchain, studiarne le diverse tipologie ed, in
un primo momento, il linguaggio degli smart contract Solidity applicato alla catena Ethereum.
Nondimeno, un’idea di progetto software ha preso forma durante lo stage ed il laureando è stato
chiamato a contribuire allo sviluppo proprio per quanto riguarda il lato blockchain: grazie alle
conoscenze acquisite è stato in grado di offrire un contributo significativo anche dal punto di
vista decisionale.
Lo studio operato e le conoscenze acquisite si sono concretizzati nella realizzazione di un’in-
frastruttura permissioned che implementa, su Hyperledger Fabric, un caso d’uso relativo alla
compravendita ed al passaggio di proprietà di beni.
Lo stage è stato supervisionato dal tutor aziendale Ing. Fabio Pallaro ed ha avuto la durata
complessiva di trecento ore.
vRingraziamenti
Vorrei ringraziare in primo luogo il prof. Francesco Ranzato, relatore della mia tesi, per la
precisione delle comunicazioni e la disponibilità dimostratami durante la stesura di questo
documento.
Ringrazio Sync Lab S.R.L. per avermi dato la possibilità di sviluppare un progetto inno-
vativo, utilizzando tecnologie all’avanguardia che mai hanno mancato di mettermi alla prova.
Ringrazio Fabio Pallaro per essere un tutor eccezionale, i colleghi per la simpatia: grazie per
aver reso l’ufficio un ambiente lavorativo cordiale e mai noioso.
Desidero ringraziare la mia famiglia per il sostegno manifestato nei miei confronti nel corso di
questi anni.
Ringrazio gli amici di una vita, ormai sparsi per il globo, con i quali ho condiviso avven-
ture oltre ogni immaginazione: Sandro, Ferdi, Otto, Bally, Trink, Nardo, Dave, Gianni, Silvia,
Rocco, Secco, Aomo.
Ringrazio Margherita ed Emma per essere così speciali ed indispensabili. Ringrazio Marta
per l’affetto e la premurosità dimostratemi in questo ultimo anno.
Infine, desidero ringraziare il Conio per questi primi due anni indimenticabili.
Ringrazio i coinquilini meravigliosi che mi ha regalato: la Queen, il Depa, Riki, Giacomo,
Vlad, Sarci e Lucarmà.
Padova, 17 Settembre 2019 Federico Brian
viiIndice
1 Introduzione 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Settori di impiego . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Processi e metodologie aziendali 5
2.1 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Concretizzazione dei principi Extreme . . . . . . . . . . . . . . . . . 6
2.2 Strumenti di supporto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Descrizione dello stage 9
3.1 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Considerazioni preliminari . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Descrizione del prodotto . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Studio tecnologico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Studio di fattibilità blockchain 15
4.1 Sintesi dello studio di fattibilità . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Smart contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 Linguaggi di programmazione degli smart contract . . . . . . . . . . 16
4.2.3 Gas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Studio del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.1 Studio del dominio applicativo . . . . . . . . . . . . . . . . . . . . . 23
4.4.2 Studio del dominio tecnologico . . . . . . . . . . . . . . . . . . . . 23
4.4.3 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Implementazione 27
5.1 Progettazione Architetturale . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.1 Topologia di rete Hyperledger Fabric . . . . . . . . . . . . . . . . . 28
5.2.2 Istanziazione della rete . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.3 Chaincode in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
ixx INDICE
6 Conclusioni 33
6.1 Consuntivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Valutazione Personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Glossario 37Elenco delle figure
1.1 Logo Sync Lab S.R.L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Cicli di pianificazione e riscontro di Extreme Programming. . . . . . . . . . 6
4.1 Logo di Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Logo di Solidity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Logo di Vyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Logo di Hyperledger Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5 Struttura del ledger in Hyperledger Fabric . . . . . . . . . . . . . . . . . . . 18
5.1 Progettazione architetturale del prodotto software . . . . . . . . . . . . . . . 27
5.2 Topologia di rete implementata. . . . . . . . . . . . . . . . . . . . . . . . . 28
Elenco delle tabelle
6.1 Tabella degli obiettivi obbligatori . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Tabella degli obiettivi desiderabili . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Tabella degli obiettivi facoltativi . . . . . . . . . . . . . . . . . . . . . . . . 35
xiCapitolo 1
Introduzione
In questo capitolo verrà brevemente esposto il contesto in cui si è svolto lo stage, descri-
vendo le motivazioni che hanno spinto l’azienda a proporlo.
Introduzione al contesto applicativo.
Esempio di utilizzo di un termine nel glossario
Proof-of-Work (PoW).
Esempio di citazione in linea.
[1]
Esempio di citazione nel pie’ di pagina
citazione1 .
1.1 L’azienda
Sync Lab S.R.L. è una società di consulenza informatica fondata nel 2002 con sedi a Napoli,
Roma, Milano, Verona e Padova.
Fin dai primi anni Sync Lab si è rapidamente sviluppata nel mercato ICT, raggiungendo
una solida base finanziaria e un’ampia diffusione sul territorio attraverso le sue cinque sedi.
L’organico aziendale è andato aumentando in modo continuo e rapido, in relazione all’apertura
delle varie sedi ed alla progressiva crescita delle stesse, raggiungendo le cento collaborazioni
nel 2007 e superando le duecento nel 2016.
Le politiche di assunzione hanno reso Sync Lab un punto di riferimento per coloro che
intendono avviare o far evolvere in chiave professionale la loro carriera: l’alto tasso di assunzione
post-stage [9] ed il basso turn-over testimoniano la voglia di condividere il progetto comune,
assumendo ruoli e responsabilità che possono essere offerti solo da un processo evolutivo così
intenso.
Il fatturato rispecchia la crescita dell’azienda, beneficiando dell’approccio adattativo e
diversificato al mercato [10].
12 CAPITOLO 1. INTRODUZIONE
Figura 1.1: Logo Sync Lab S.R.L.
1.1.1 Servizi offerti
La principale attività di Sync Lab è la consulenza tecnologica: un processo continuo di identifi-
cazione e messa in opera di soluzioni su misura, finalizzate alla creazione di valore. Sync Lab
eroga servizi in ambito:
∗ Business Consultancy;
∗ Project Financing;
∗ IT Consultancy.
In questo modo, l’azienda è in grado di supportare le esigenze di innovazione di tutte le
organizzazioni ed in ogni settore di mercato dell’Information Technology.
Un ulteriore punto di forza di Sync Lab è la qualità dei servizi offerti, come dimostrano
le certificazioni ISO 9001, ISO 14001, ISO 27001, OHSAS 18001 ottenute nel corso degli
anni. L’approfondita conoscenza di processi e tecnologie, maturata in esperienze altamente
significative e qualificanti, fornisce l’expertise e il know-how necessari per gestire progetti di
elevata complessità, dominando l’intero ciclo di vita:
∗ Studio di fattibilità;
∗ Progettazione;
∗ Implementazione;
∗ Governance;
∗ Post Delivery.
L’offerta di consulenza specialistica trova le punte di eccellenza nella progettazione di
architetture software avanzate, siano esse per applicativi di dominio, per sistemi di Supporto
al Business (BSS), per sistemi di integrazione (EAI/SOA) o per sistemi di monitoraggio appli-
cativo/territoriale. Il laboratorio Ricerca e Sviluppo (RD) dell’azienda è sempre al passo con
i nuovi paradigmi tecnologici e di comunicazione, ad esempio Big Data, Cloud Computing,
Internet of Things (IoT), Mobile e Sicurezza IT, per supportare i propri clienti nella creazione
ed integrazione di applicazioni, processi e dispositivi. Le attività in ambito Educational ed
RD hanno permesso di acquisire una profonda conoscenza degli strumenti di finanza agevolata
fruendone direttamente ed interagendo con enti di supporto ai progetti innovativi dei propri
clienti.
L’azienda, grazie alla rete di relazioni a livello nazionale ed internazionale, ha ottenuto
importanti finanziamenti in progetti RD europei (FP7 e H2020) [11].1.2. L’IDEA 3
1.1.2 Settori di impiego
Sync Lab si sta sempre più specializzando in vari settori d’impiego: dal mondo banking
all’assurance con una nicchia importante nell’ambito sanità in cui vanta un prodotto d’ec-
cellenza per la gestione delle cliniche private. L’azienda inoltre ha recentemente fondato un
reparto collegato Sync Security che si occupa espressamente del mondo della cyber security e
sicurezza informatica in genere.
1.2 L’idea
Non esiste ad oggi una procedura ben definita, tracciata e normata che descriva il processo di
compravendita di un bene generico. Gli attuali strumenti che cercano di adempiere a tale scopo,
per alcuni tipi di beni, sono dei documenti di “scrittura privata”: si tratta tuttavia di procedure
non regolamentate e lasciate al libero arbitrio delle persone.
Questa mancanza potrebbe essere colmata attraverso un software opportunamente svilup-
pato, che tiene traccia in modo non falsificabile ed immutabile dello scambio di beni: per
questo caso d’uso la blockchain trova la sua applicazione ideale poiché soddisfa esattamente le
seguenti esigenze:
∗ Immutabilità delle transazioni;
∗ Verificabilità delle stesse;
∗ Sicurezza dei dati.
Lo scopo dello stage è realizzare una rete blockchain che dia la possibilità di utilizzare uno
specifico smart contract, ovvero un programma auto-eseguibile locato all’interno della struttura
stessa ed opportunamente sviluppato dal sottoscritto per il caso d’uso sopra citato. L’utente
deve avere la possibilità di registrare il pagamento relativo al passaggio del bene di valore in
questione e successivamente l’avvenuto scambio di quest’ultimo.
La tecnologia blockchain sarà descritta nella sezione 3.2.1.
1.3 Organizzazione del testo
Il secondo capitolo descrive le metodologie adottate per lo sviluppo del progetto.
Il terzo capitolo presenta lo studio del dominio tecnologico riguardante la tecnologia blockchain.
Il quarto capitolo affronta lo studio di fattibilità riguardante la tecnologia blockchain.
Il quinto capitolo descrive l’architettura del progetto, l’istanziazione della rete e l’implementa-
zione del chaincode.
Il sesto capitolo riporta le conclusioni tratte alla fine del periodo di stage, indicando un
consuntivo, le competenze acquisite e le impressioni avute relative all’esperienza di tirocinio.Capitolo 2
Processi e metodologie aziendali
Nel presente capitolo verranno descritte le tecniche e metodologie di sviluppo del prodotto.
Più precisamente verranno descritti i principi cardine di Extreme Programming e successi-
vamente verrà illustrato come questi siano stati applicati durante lo stage.
Come moltissime altre aziende, anche Sync Lab sta abbracciando le metodologie Agile
come modello di sviluppo prediletto. I principi di tali metodologie sono pochi e precisi:
∗ Le persone e le interazioni sono più importanti dei processi e degli strumenti;
∗ È più importante avere software funzionanti che documentazione;
∗ Bisogna essere pronti a rispondere ai cambiamenti oltre che aderire alla pianificazione.
Nel mio caso sono stato inserito in un contesto dove veniva utilizzato un modello di sviluppo
Agile declinato alla variante Extreme Programming (Extreme).
2.1 Extreme Programming
Extreme è un framework di sviluppo che mira alla qualità del software e, soprattutto, alla qualità
della vita del team di sviluppo. È il più preciso dei framework Agile per quanto riguarda le
pratiche di ingegneria appropriate per lo sviluppo software e trova la sua applicazione ottimale
quando:
∗ I requisiti del software cambiano rapidamente;
∗ Si conosce la data precisa del rilascio del progetto;
∗ Si utilizzano tecnologie nuove, poco conosciute;
∗ Il team di sviluppo è di piccole dimensioni e situato nella medesima località;
∗ La tecnologia usata permette l’utilizzo di Unit Test e Functional Test [13].
56 CAPITOLO 2. PROCESSI E METODOLOGIE AZIENDALI
Figura 2.1: Cicli di pianificazione e riscontro di Extreme Programming.
Elementi chiave di Extreme sono il Pair Programming, l’uso sistematico di unit e functional
test, il Refactoring, il divieto ai programmatori di sviluppare codice non strettamente necessario
secondo il principio YAGNI 1 , l’enfasi sulla chiarezza e la semplicità del codice, la preferenza per
strutture gestionali non gerarchiche e l’importanza data alla comunicazione diretta e frequente
fra sviluppatori e cliente e fra gli sviluppatori stessi2 .
Proprio come la metodologia Scrum, anch’essa derivata da Agile, Extreme prevede dei gior-
nalieri stand-up meeting in cui gli sviluppatori sono chiamati a rispondere fondamentalmente a
tre specifiche domande:
∗ Cos’è stato portato a termine ieri?
∗ Cosa sarà portato a compimento oggi?
∗ Quali problemi stanno causando ritardi?
Nondimeno, esiste anche in Extreme la suddivisione del progetto in blocchi di lavoro rapidi,
detti Sprint, alla fine di ciascuno dei quali creare un incremento del software.
2.1.1 Concretizzazione dei principi Extreme
Nel contesto del mio progetto di stage mi sono trovato in team di sviluppo chiamato Team933
di cui faccio tutt’ora parte e che mira a produrre un prodotto software completo per un cliente.
Questa situazione mi ha predisposto ad assimilare la maggior parte dei principi Extreme
immediatamente anche se, a volte, la velocità con cui era richiesta la realizzazione delle task
ha portato a compiere imprecisioni e inesattezze, dovute alla mia inesperienza professionale
nel campo IT.
Per lo sviluppo dell’applicativo, il team ha adottato le seguenti metodologie Extreme,
suddivise per cadenza.
1 “You Aren’t Gonna Need It” (ing. “non ne avrai bisogno”)
2 dalprincipio Extreme:“Pair Negotiation” (ing. “negoziazione di coppia”), in cui gli sviluppatori sono chiamati a
dare il proprio contributo negli ambiti in cui hanno più esperienza
3 dal momento che tutti i membri condividono lo stesso anno di nascita2.1. EXTREME PROGRAMMING 7
Mensile:
∗ Release Plan: viene organizzata una videoconferenza con il cliente finale e gli stakehol-
ders al fine di illustrare gli incrementi del software raggiunti, chiarire eventuali dubbi
riguardanti il contesto del prodotto software e che possono potenzialmente influenzarne il
comportamento, allineare le aspettative concernenti l’applicativo e concordando insieme
i prossimi obiettivi da raggiungere.
Settimanale:
∗ Iteration Plan: ad inizio settimana vengono discussi, alla luce di quanto portato a termine
la settimana precedente, gli obiettivi che si pianifica di riuscire a raggiungere nella
settimana a venire. L’efficienza di pianificazione è una dote sovente mancante in lavoratori
inesperti, per cui sono stato più volte sollecitato a rivedere quanto prefissato dato che si
rivelava essere troppo ottimistico.
Giornaliera:
∗ Stand up meeting: una volta al giorno, non appena i componenti del team giungevano in
ufficio ci si incontrava in sala conferenze per fare il punto della situazione secondo le
regole del framework Extreme. È importante sottolineare che l’attenzione veniva posta
anche ad eventuali problematiche extra-lavorative che potessero in qualche modo portare
in una situazione di rischio la buona riuscita degli obiettivi prefissati, mettendo a proprio
agio il lavoratore e permettendogli di risolvere l’eventuale problema ogniqualvolta ce ne
fosse stato il bisogno.
Oraria:
∗ Pair programming il team di sviluppo, durante la fase di di analisi e progettazione
architetturale, ha attuato questa metodologia che prevede che il più esperto del contesto
trattato (piuttosto che del linguaggio di programmazione utilizzato) faccia da driver,
cioè che scriva codice, mentre una o più persone facciano da navigator, vale a dire
supervisione e revisione in tempo reale del codice scritto, segnalando eventuali errori o
perplessità di concetti logici e tecniche riscontrate.
∗ Unit test: i test di unità sono sviluppati a monte della codifica del vero e proprio appli-
cativo. Questa tecnica prende il nome di Test Driven Development (TDD) e permette
di avere un’idea cristallina di come deve funzionare il software che si deve sviluppare.
Nondimeno, scrivendo prima i test si forniscono esempi dettagliati che descrivono in
modo univoco il comportamento del software e che, quindi, fungono da documentazione
esaustiva.
∗ Hourly update: durante la codifica individuale è opportuno informare gli altri membri
del team circa le attività portate a termine e le eventuali problematiche riscontrate. In
questo modo si possono evitare situazioni che portano a perdere molto tempo e che
possono mettere a rischio le scadenze prefissate.
∗ Half-an-our bug finding: letteralmente:“trovare il bug in mezz’ora”. Durante la codifica
individuale si ha a disposizione al più mezz’ora di tempo per provare a risolvere un
eventuale bug da soli, dopodiché si deve interpellare il responsabile del team per chiedere
di essere assistiti. Se nemmeno lui è in grado di risolvere la situazione in un ulteriore
mezz’ora, si ricorre all’aiuto del manager aziendale.8 CAPITOLO 2. PROCESSI E METODOLOGIE AZIENDALI Quest’ultimo principio non è proprio di Extreme ma si può considerare come tale, dato che la metodologia si differenzia ad esempio da Scrum per l’estrema pianificazione, che a volte avviene anche nell’ordine dei minuti. 2.2 Strumenti di supporto Gli strumenti di supporto da me utilizzati in azienda sono i seguenti: Slack: piattaforma di messaggistica altamente impiegata per il lavoro in team, che fa del suo punto di forza la divisione per canali. Ogni canale ha un suo scopo e può avere accesso libero o ristretto a membri selezionati. Il vantaggio dell’utilizzo di Slack è la velocità e facilità dello scambio e reperimento delle comunicazioni ed informazioni e l’integrazione con diverse applicazioni per un monitoraggio continuo ed immediato. Trello: software gestionale in stile Kanban basato sul web. Ogni utente, a login effettuata, può accedere a diversi workspace che può aggiornare inserendo o modificando una o più card, a seconda delle task eseguite o da eseguire. Il vantaggio dell’utilizzo di Trello è rendere consapevole l’utente dello stato in cui si trova lo sviluppo di un progetto software. Tramite la creazione di una card l’utente può definire un requisito, un’azione atomica, un bug rilevato: in questo modo si riesce a scomporre la complessità di un progetto software di grandi dimensioni, rendendo la sua implementazione più schematica ed organizzata. GitLab: servizio di versionamento online basato su Git. Il codice da me prodotto è salvato su un repository privata su GitLab, aggiornata durante tutto il ciclo di sviluppo.
Capitolo 3
Descrizione dello stage
In questo capitolo si intende illustrare nel dettaglio lo studio iniziale e le considerazioni che
hanno portato allo sviluppo del progetto e che sono alla base della proposta di stage. Per
motivi di riservatezza mi è stato permesso solo di descrivere l’applicazione e le tecniche
utilizzate in modo sommario, senza scendere troppo nei dettagli, per tutelare la proprietà
intellettuale di Sync Lab S.R.L.
3.1 Introduzione al progetto
3.1.1 Considerazioni preliminari
È opportuno spendere del tempo per specificare la natura di questo progetto. Come descritto
nel sottotitolo del presente capitolo, non mi è possibile elargire dettagli con grande precisione
per non ledere la proprietà intellettuale dell’azienda ospitante Sync Lab. Il prodotto, descritto
nelle prossime sezioni, è stato sviluppato per un ente pubblico e costituisce una partizione di
un sistema più grande. Non deve essere considerato come un prodotto a sé stante; bensì come
un fondamentale ingranaggio di un meccanismo più vasto e complesso.
3.1.2 Descrizione del prodotto
Il progetto ha come scopo la realizzazione di:
∗ Una rete blockchain di almeno due nodi;
∗ Uno smart contract che consenta la registrazione nella blockchain di un atto di vendita
relativo ad un bene.
In sintesi, il sistema desiderato dovrà registrare le informazioni relative ad un bene, le anagrafiche
del suo possessore, del suo acquirente ed il relativo atto di vendita.
3.2 Studio tecnologico
Lo studio inizia descrivendo la tecnologia blockchain, le sue peculiarità, le tipologie esistenti
e gli ambiti di utilizzo. Si proseguirà illustrando la tecnologia permissionless di Ethereum e
quella permissioned di Hyperledger Fabric, che avrà un capitolo dedicato.
910 CAPITOLO 3. DESCRIZIONE DELLO STAGE
3.2.1 Blockchain
Caratteristiche
La tecnologia blockchain è un database distribuito, decentralizzato ed immutabile, composto
da una sequenza concatenata di informazioni suddivise in strutture dati chiamate blocchi. Un
blocco appena inserito possiede un riferimento di tipo hash al blocco che lo precede ed, una
volta inserito, non è possibile modificarlo od eliminarlo in un secondo momento.
Si definisce peer ogni utente che partecipa alla creazione di nuovi blocchi (miner) oppure
alla validazione degli stessi (validator). L’insieme dei peer di una blockchain forma una rete
peer-to-peer in cui non esiste un’entità centrale che svolge il ruolo di amministratore: l’integrità
e la validità dei dati sono garantite da specifici algoritmi di consenso, di cui si parlerà nella
sezione 3.2.1.
Ogni peer possiede una copia del libro mastro (ledger) contenente tutte le transazioni
avvenute nell’intero ciclo di vita della blockchain. Il ledger di un peer è considerato valido solo
se identico ai ledger del 50% + 1 dei peer sulla stessa blockchain: è facile rendersi conto che
in una rete pubblica si deve rendere la modifica di uno o più blocchi estremamente difficoltosa
in termini computazionali e svantaggiosa in termini economici. Per questa precisa motivazione
il metodo di creazione dei blocchi più usato dalle blockchain permissionless è il Proof-of-Work
(PoW). Se un blocco dovesse essere modificato, allora anche il suo hash e quello di tutti i
blocchi successivamente creati dovrebbe essere ricalcolato.
La blockchain, di conseguenza, vanta un alto grado di sicurezza in termini di protezione da
contraffazioni ed è ritenuta la scelta prediletta per l’implementazione del caso d’uso presentato.
Consenso
Si definisce consenso il processo di sincronizzazione delle transazioni attraverso i nodi della
rete atto ad assicurare che le diverse copie del ledger siano aggiornate solo quando le transazioni
sono effettivamente approvate.
Le transazioni devono essere scritte su ogni copia del ledger nello stesso ordine, stabilito in
maniera univoca. Questa esigenza obbliga i nodi della blockchain ad aderire ad un accordo
comune, stabilito al momento della creazione della stessa. A questo fine vengono utilizzati
diversi algoritmi di consenso, aventi le seguenti proprietà:
∗ Integrità: ogni partecipante della rete effettua al più una scelta.
∗ Validità: un peer sceglie sempre un valore proposto da un altro partecipante;
∗ Accordo: tutti i peer scelgono lo stesso valore corretto;
∗ Terminazione: tutti i peer concordano un valore in un tempo finito.
In una rete blockchain pubblica e permissionless è necessario che tutti i peer abbiano una copia
identica del ledger. Poiché è fondamentale che i blocchi generati rispecchino in modo veritiero
le transazioni che avvengono su tale rete, vengono utilizzati diversi algoritmi che definiscono
come debbano essere generati i blocchi da inserire in coda alla blockchain.
Il problema dei generali bizantini
I sistemi informatici distribuiti, per essere considerati affidabili, devono gestire eventuali
anomalie di componenti mal funzionanti poiché c’è il rischio che possano fornire informazioni
contrastanti a diverse parti del sistema.3.2. STUDIO TECNOLOGICO 11
Questa situazione può essere espressa in modo astratto come problema dei generali bizantini,
formalizzato come segue:
Un gruppo di generali dell’esercito bizantino è accampato con le loro truppe intor-
no a una città nemica. Comunicando solo tramite un messaggero, i generali devono
concordare un piano di battaglia comune. Tuttavia, uno o più di essi possono
essere traditori che cercheranno di confondere gli altri.
Si deve disporre di un algoritmo per garantire le seguenti condizioni:
(A) Tutti i generali leali decidono lo stesso piano d’azione (determinismo).
I generali leali seguiranno ciò che l’algoritmo deciderà; allo stesso modo i traditori
possono fare tutto ciò che desiderano.
L’algoritmo deve garantire la condizione (A) indipendentemente da ciò che fanno i traditori. I
generali leali non dovrebbero solo raggiungere un accordo, dovrebbero anche concordare un
piano ragionevole;
(B) Un numero limitato di traditori non può indurre i generali leali ad adottare un piano
negativo.
Il problema è trovare un algoritmo per garantire che i generali leali raggiungano un accordo. È
dimostrato che, usando solo messaggi orali, questo problema è risolvibile se e solo se più di
due terzi dei generali sono leali; così un singolo traditore può confondere due generali leali.
Con messaggi scritti falsificabili, il problema è risolvibile per qualsiasi numero di generali e
possibili traditori. [5] Nei sistemi distribuiti, la capacità degli algoritmi di risolvere il problema
sopra descritto viene indicata come Byzantine Fault Tolerance (BFT).
È plausibile considerare che alcuni partecipanti ad una rete blockchain possano avere
intenzioni che mirino a ledere il benestare di uno o più fruitori. Alcuni, ad esempio, potrebbero
tentare di modificare le informazioni contenute in uno o più blocchi al fine di trarre vantaggi
economici, molto spesso a discapito di altri. La tecnologia blockchain è un registro distribuito
e non amministrato da alcuna autorità centrale: senza un algoritmo BFT un nodo potrebbe
essere in grado di trasmettere transazioni false. Queste sarebbero così registrate nelle copie dei
registri degli altri nodi, mettendo in pericolo l’affidabilità della rete.
Proof-of-Work
Una blockchain permissionless deve essere in grado di evitare la modifica dei blocchi, pena la
sua inaffidabilità. Per far fronte a questo problema è stato introdotto il concetto di generazione
dei blocchi attraverso complessi problemi matematici, la cui risoluzione richiede un grande
sforzo computazionale e un grosso dispendio di tempo ed energia: il Proof-of-Work.
Questa metodologia comporta la ricerca di un valore che, una volta sottoposto ad una
funzione hash, restituisca un ulteriore hash che inizia con un certo numero di bit a zero. Il
lavoro medio richiesto è esponenzialmente proporzionale al numero di bit a zero richiesti e può
essere verificato immediatamente. Si adotta un valore hash con un numero selezionabile di
bit a zero al fine di non ipersemplificare la sua generazione, dal momento che l’avanzamento
tecnologico offre calcolatori di potenza crescente. Il nodo che riesce a trovare il valore hash
corretto prima degli altri crea il blocco: esso verrà aggiunto in coda alla blockchain e riceverà
un compenso sotto forma di valuta virtuale, chiamata cripto-valuta.
L’algoritmo Proof-of-Work non risolve in modo ottimo la Byzantine Fault Tolerance ma
offre al contempo una delle implementazioni più sicure ed affidabili per le reti blockchain. [6].12 CAPITOLO 3. DESCRIZIONE DELLO STAGE
Proof-of-Stake
In una tradizionale blockchain Proof-of-Work, i miners votano su quali transazioni sono arrivate
a che ora e più si dispone di potenza della CPU, più aumenta l’autorità esercitata sulla rete: è
necessaria una forza computazionale ed un dispendio di tempo ed energia non banali. Proof-
of-Stake segue un paradigma simile: le parti interessate esercitano il voto ma lo fanno con la
valuta interna di quel particolare sistema. Ogni account ha una certa possibilità al secondo di
generare un blocco valido, proprio come una componente hardware adibita al mining, e questa
possibilità è proporzionale al saldo del conto. Una formula molto semplice per raggiungere
questo scopo è la seguente:
balance
SHA256(prevhash + address + timestamp) ≤ 2256 × dif f
dove:
∗ prevhash è il valore hash del blocco precedente;
∗ address è l’indirizzo del nodo miner;
∗ timestamp è il formato data corrente di Unix in termini di secondi;
∗ balance è il bilancio del nodo miner;
∗ diff è un parametro globale modificabile di difficoltà.
Se un miner soddisfa la precedente equazione può generare un blocco valido, ricevendo una
ricompensa in termini di cripto-valuta. Una conseguenza immediata di questo approccio è che
il peer avente il balance maggiore ottiene il controllo della rete: per questo viene implementato
un algoritmo che sceglie in maniera pseudo-casuale ma comunque proporzionale allo stake,
cioè alla «posta in gioco», l’account da premiare.
Nel caso in cui la rete peer-to-peer rilevi una manomissione nel blocco appena generato
allora l’investimento non sarebbe più ritornato e l’utente viene estromesso dalla rete. Tuttavia,
questo algoritmo di consenso è difficile da implementare e le sue attuali implementazioni non
sono ancora mature per essere utilizzate in reti pubbliche [2].
Fork
Nell’ambito delle blockchain permissionless, quindi accessibili pubblicamente, chiunque può
partecipare al processo di consenso approvando o rifiutando l’ordine in cui sono state registrate
le transazioni. Al fine di stabilire e di rendere inequivocabile tale ordine, è necessario un
approccio di tipo probabilistico poiché due o più nodi potrebbero avere un’opinione differente
su quale blocco sia stato generato prima. È una condizione che si verifica specialmente quando
due blocchi vengono generati nello stesso istante o in un intervallo di tempo non misurabile dal
sistema. Questa condizione negativa viene definita come soft fork ed ogni rete blockchain attua
diversi protocolli per sanare tale situazione di inconsistenza.
Gli sviluppatori di una blockchain possono decidere di eseguire un fork manualmente, ad
esempio per aggiornare protocolli o cambiare l’algoritmo di consenso. Questa situazione
prende il nome di hard fork.
Blockchain per realtà enterprise
Con l’aumentare della popolarità di Bitcoin ed Ethereum è cresciuto anche l’interesse per tutte
le tecnologie che derivano da esse, ovvero le funzionalità di base della blockchain e le ÐApps.
Tuttavia, molti contesti aziendali richiedono caratteristiche prestazionali che le tecnologie3.2. STUDIO TECNOLOGICO 13
blockchain permissionless non sono attualmente in grado di offrire, senza contare che in molti
casi d’uso conoscere l’identità dei partecipanti, limitare l’accesso alla rete e rendere alcune
transazioni private è un requisito fondamentale. L’uso di blockchain da parte di aziende private
è in costante crescita, tuttavia le esigenze possono essere significativamente diverse se non
addirittura in collisione con la politica delle blockchain permissionless. Ad esempio, l’accesso
alla rete aziendale deve avvenire previa identificazione ed è limitato ai soli utenti autorizzati,
cosa che una blockchain pubblica come Bitcoin od Ethereum non può fornire per costruzione,
poiché alla creazione di un nuovo account viene assegnato un valore hash pseudo-casuale.
Le transazioni dovrebbero essere portate a compimento e verificate in meno di un minuto,
mentre in una blockchain permissionless una transazione impiega diversi minuti per essere
incorporata in un blocco a causa del consenso Proof-of-Work; stessa cosa dicasi della conferma
di transazione, senza contare che il movimento di cripto-valuta sarebbe visibile pubblicamente,
anche se cifrato.
Da qui nasce l’idea di sviluppare una blockchain permissioned, ovvero un sistema che
mantenga i benefici di una blockchain introducendo peculiarità che soddisfino le esigenze
del settore enterprise. Ad esempio, istituendo una rete non accessibile pubblicamente i cui
partecipanti sono identificati, che assicura privacy dei dati, transazioni quasi immediate e basso
ritardo della conferma.
In questo tipo di blockchain l’utilizzatore della rete può intraprendere solo le azioni che gli
è permesso eseguire, richiamare solo gli smart contract a lui associati oppure, a valle di una
autenticazione, esercitare i privilegi di amministratore.
Consenso in ambito permissioned
Le blockchain permissionless come Bitcoin ed Ethereum hanno cripto-valuta nativa per in-
centivare il mining delle transazioni che attualmente esso avviene mediante Proof-of-Work.
Quest’ultimo, tuttavia, presenta diversi svantaggi che comportano una sensibile latenza di
conferma delle transazioni e un basso numero di transazioni al minuto. Questi fattori rendono le
blockchain pubbliche non adatte ad un utilizzo a livello aziendale. Nelle catene permissioned il
consenso è definito come la verifica a tutto tondo della correttezza di un insieme di transazioni
comprendente un blocco. Occorrono quindi nuove architetture di rete e nuovi algoritmi per il
raggiungimento del consenso. La scelta dominante in questo settore prevede che il consenso
sia ottenuto tramite protocolli a votazione, che assicurano elevate performance.Capitolo 4
Studio di fattibilità blockchain
Nel presente capitolo si affronta lo studio di fattibilità riguardante la tecnologia blockchain,
a partire dalla scelta della piattaforma ed a seguire alla selezione del linguaggio di pro-
grammazione degli smart contract. Lo studio di fattibilità inizia con la descrizione delle
due tecnologie prese in esame, Ethereum ed Hyperledger Fabric, mettendole in relazione
ai requisiti che dovranno soddisfare. Si proseguirà quindi con l’elencare i pregi e difetti
derivanti da ciascuna scelta. Verrà infine spiegato il motivo che ha portato a scegliere
Hyperledger Fabric come piattaforma blockchain e Java come linguaggio di programmazione
per il chaincode.
4.1 Sintesi dello studio di fattibilità
4.2 Ethereum
Figura 4.1: Logo di Ethereum
Ethereum è una blockchain globale permissionless ed open source per il software decentraliz-
zato, le ÐApps. Le transazioni modificano la Ethereum Virtual Machine (EVM), una macchina
virtuale distribuita in grado di eseguire codice, il quale rappresenta le transazioni e la cui
esecuzione causa transazioni di cripto-valuta, in questo caso l’Ether. EVM è pensata per essere
turing-complete, ovvero per eseguire le stesse operazioni di una macchina di Turing con tempo
e memoria finiti: in altre parole, di eseguire algoritmi.
1516 CAPITOLO 4. STUDIO DI FATTIBILITÀ BLOCKCHAIN
4.2.1 Smart contract
La possibilità di eseguire codice sorgente tramite la EVM ha permesso ad Ethereum di di-
stinguersi dalle altre blockchain in quanto, oltre alle transazioni di Ether, è possibile scrivere
dei programmi eseguibili automaticamente noti con il nome di smart contract. Uno smart
contract permette di costruire una logica specifica attorno ad una transazione, crearne di nuove,
verificare certe condizioni oppure memorizzare i dati inseriti da utenti o da altri smart contract.
Un esempio di applicazione degli smart contract è la gestione della proprietà intellettuale.
Ogni volta che un contenuto viene utilizzato a fini commerciali, ad esempio una canzone, il
proprietario dei diritti di quella canzone riceve una commissione. Molto spesso più parti sono
coinvolte nella creazione di una canzone e può essere difficile capire chi possiede questi diritti,
a chi spetta il pagamento e in che misura.
Gli smart contract possono garantire che i diritti vadano ai destinatari previsti, registrando
le proprietà intellettuali in una piattaforma blockchain. Il fruitore della canzone versa una
determinata somma allo smart contract, che provvederà a redistribuirla nei wallet degli autori
nella misura concordata.
Dall’esempio presentato si evince la volontà di eliminare qualsiasi intermediario ed evitare
controversie. Di fatto, lo smart contract agisce in modo imparziale e non subisce il controllo di
nessun ente: esso viene eseguito automaticamente, assicurando che le condizioni contenute al
suo interno vengano rispettate.
4.2.2 Linguaggi di programmazione degli smart contract
Figura 4.2: Logo di Solidity Figura 4.3: Logo di Vyper
I principali linguaggi di programmazione messi a disposizione per Ethereum sono due: Solidity
e Vyper.
Solidity è un linguaggio ad oggetti statically typed: il tipo delle variabili è dichiarato e quindi
determinato a tempo di compilazione, come C, C++ o Java. Supporta l’ereditarietà, l’uso di
librerie e la definizione di oggetti complessi definiti dall’utente[8].
Vyper viene definito come linguaggio contract-oriented. Nato successivamente a Solidity
si trova ancora in fase di sviluppo ma promette di avere le seguenti caratteristiche[12]:
∗ Controllo di limiti e overflow sugli accessi di array e sul livello aritmetico;
∗ Supporto per numeri interi con segno e numeri decimali in virgola fissa;
∗ Decidibilità: dovrebbe essere possibile calcolare un limite superiore preciso per il
consumo di gas di qualsiasi chiamata di funzione;4.3. HYPERLEDGER FABRIC 17
∗ Supporto per le unità avanzate, come ad esempio timestamp, timedelta, secondi, wei,
wei al secondo, metri al secondo al quadrato).
Ciò che accomuna i due linguaggi di programmazione è la semplicità data dall’obbligo di
interazione con la EVM: essa infatti dispone di limitata capacità computazionale, caratteristica
che influisce anche sui linguaggi con cui si relaziona.
4.2.3 Gas
La peculiarità del software decentralizzato di Ethereum, chiamato smart contract, è che richie-
de qualcosa in cambio per essere eseguito. I miner sono responsabili dell’inclusione delle
transazioni all’interno dei blocchi che generano; per farlo devono utilizzare la loro potenza
computazionale per convalidare gli smart contract. Il concetto di gas consente loro di addebitare
una determinata tariffa, conosciuta come miner’s fee che aiuta ad incentivare i miner a prendere
parte attiva nel sistema Ethereum.
Viene utilizzato il concetto di gas per separare semanticamente l’Ether, che ha valore
monetario variabile, con il costo effettivo indispensabile all’esecuzione di uno smart contract,
che invece rimane sempre lo stesso. Un’analogia utile è data dal prezzo di un determinato
carburante, variabile nel tempo e dai litri dello stesso carburante necessari per viaggiare da una
località ad un’altra, che invece rimane una quantità fissa.
4.3 Hyperledger Fabric
Figura 4.4: Logo di Hyperledger Fabric
4.3.1 Descrizione
Hyperledger Fabric è una piattaforma open source permissioned che implementa la tecnologia
di registro distribuito, progettata per l’uso in contesti aziendali. Fabric fa parte di Hyperledger,
un progetto open source creato nel 2015 per far avanzare le tecnologie blockchain in più settori,
ospitata dalla Linux Foundation.
Hyperledger Fabric è mantenuta da sviluppatori di almeno trentacinque organizzazioni diverse
e la sua community di sviluppo conta, al momento della scrittura di questa tesi, più di duecento
collaboratori in tutto il mondo.
Fabric dispone di un’architettura modulare e configurabile che promette innovazione, versa-
tilità ed ottimizzazione per numerosi casi d’uso in campo aziendale: realtà operanti in settori
come il bancario, finanziario, assicurativo, sanitario, risorse umane e fornitura utilizzano già
questo framework per gestire ed amministrare il loro business.
Fabric è la prima piattaforma a registro distribuito che permette lo sviluppo di smart contract18 CAPITOLO 4. STUDIO DI FATTIBILITÀ BLOCKCHAIN
scritti in linguaggi di programmazione popolari come Java, Go e JavaScript, permettendo alla
maggior parte delle aziende di sviluppare applicazioni anche senza conoscere linguaggi specifici
di un determinato dominio, come avviene ad esempio con Vyper o Solidity in Ethereum.
La blockchain generata con Fabric, essendo permissioned, non necessita di Proof-of-Work
o di potenti calcoli computazionali: il consenso è ottenuto tramite votazione e la presenza di
una cripto-valuta per incentivare il mining dei blocchi non è necessaria, rendendo il costo di
un’istanziazione della piattaforma molto simile ad un tradizionale sistema distribuito. [3].
4.3.2 Architettura
Ledger
In Hyperledger Fabric, un ledger consiste di due parti distinte ed in stretta relazione tra di loro:
la world state e la blockchain.
Figura 4.5: Struttura del ledger in Hyperledger Fabric
La world state detiene il valore corrente dell’insieme di oggetti di business contenuti nella
blockchain, identificato univocamente come stato del ledger. In questo modo le applicazioni
che richiedono lo stato corrente di un oggetto possono interrogare direttamente la world state,
anziché scorrere l’intera blockchain alla ricerca dei dati desiderati. È implementata come un
database per offrire un vasto insieme di operazioni, dalle interrogazioni sui dati alla memoriz-
zazione degli stessi.
Le applicazioni inviano transazioni che apportano modifiche alla world state e queste transazioni
finiscono per essere scritte nella blockchain del ledger. Le applicazioni sono isolate dai dettagli
di questo meccanismo di consenso da una apposita SDK: invocano semplicemente uno smart
contract e vengono avvisati quando la transazione è stata inclusa nel ledger, nel caso in cui sia
valida.
Mentre la world state contiene l’insieme aggiornato di valori degli oggetti di business, la
blockchain funge da registro cronologico delle transazioni: essa contiene tutte le transazioni
avvenute e tutti gli stati in cui si è trovato la world state. Fornisce quindi uno strumento di
tracciamento delle versioni della world state, comprensivo anche delle transazioni che hanno
causato un cambio di stato.
La blockchain è strutturata come un log sequenziale di blocchi interconnessi, in cui ogni blocco
contiene una sequenza di transazioni che hanno letto o modificato la world state. Ogni blocco4.3. HYPERLEDGER FABRIC 19
possiede un header, il quale contiene un valore hash della transazione che lo ha generato
assieme al valore hash del blocco precedente; un body che contiene le transazioni registrate in
modo ordinato più un ulteriore blocco di “metadati”, quali timestamp, certificati di sicurezza,
chiave pubblica e firma di chi ha operato la generazione del blocco [3].
Peer
Una rete blockchain è composta primariamente da un insieme di nodi peer, che detengono uno
o più ledger e talvolta anche diversi smart contract. Un peer espone un insieme di API che
permettono agli amministratori e alle applicazioni di interagire con i servizi che offre e può
essere creato, avviato, fermato, riconfigurato o eliminato in qualsiasi momento. Un peer può
assumere diversi ruoli, descritti come segue.
Committing peer: ogni nodo che fa parte di almeno un canale. Esso riceve blocchi generati
in seguito a transazioni e, se ritenuti validi, procede a marcarli come tali. Se tutti i committing
peer validano un blocco allora esso entra a far parte del ledger di tutti i nodi di quel canale.
Endorsing peer: un nodo che ha uno smart contract installato e che pone la sua personale fir-
ma digitale sulle transaction response. Questo meccanismo è noto con il nome di endorsement
procedure e sarà trattato nelle sezioni successive.
Leader peer: il nodo responsabile dell’organizzazione di cui fa parte e che ha lo scopo di
distribuire i blocchi ordinati dall’orderer ai Committing peer del canale.
Anchor peer: nodo adibito alla comunicazione con altre organizzazioni presenti nello stes-
so canale e che contribuisce all’applicazione del protocollo conosciuto come gossip data
dissemination protocol.
Orderer: tipologia speciale di peer che non contiene smart contract e stabilisce l’ordine delle
transazioni avvenute nei canali, mantenendo consistente il ledger degli altri peer.
Il nodo orderer adotta una politica di tipo FIFO1 e svolge una funzione cruciale poiché evita
l’inconveniente denominato Fork, trattato nella sezione 3.2.1.
Canali
Un canale è una sotto-rete di comunicazione riservata tra due o più specifici partecipanti alla
rete, adibito alla conduzione di transazioni private e confidenziali. Ogni peer sottoscrive una
transazione nel canale in cui è autorizzato ad accedere, in caso contrario la transazione viene
rigettata ed il world state non subisce modifiche.
Un peer può partecipare a più canali e possiede un ledger per ogni canale a lui associato:
nessuna informazione appartenente ad un ledger può essere recuperata da un canale esterno. La
separazione di peer e ledger operata dai canali permette ai membri della rete che necessitano di
riservatezza di coesistere con i loro competitors nella stesse rete blockchain.
È possibile configurare i canali specificando le organizzazioni che ne usufruiranno e che
eventualmente potranno inserire a loro volta altre organizzazioni: diventa così possibile definire
due tipologie di privilegi sul canale. Nondimeno, esiste un canale speciale creato al momento
1 First In First Out: l’ordine di arrivo delle transazioni concide con l’ordine con cui saranno memorizzate nei
blocchi.20 CAPITOLO 4. STUDIO DI FATTIBILITÀ BLOCKCHAIN
dell’istanziazione della piattaforma chiamato canale di sistema ed utilizzato dall’ordering
service, descritto nelle sezini successive.
Membership Service Provider
I peer partecipanti ad una rete Hyperledger Fabric sono titolari di un’identità digitale formaliz-
zata con un certificato X.509, che permette di determinare i permessi di accesso alle risorse ed
alle informazioni presenti nella rete. In Fabric, l’attributo che identifica univocamente un peer
e che unisce l’identità dello stesso con i suoi permessi prende il nome di principal. Per essere
verificabile un’identità digitale deve essere rilasciata da un’autorità affidabile, che può essere
di tipo pubblico o di tipo privato. Questa autorità, in Fabric, prende il nome di Certificate
Authority (CA) e rappresenta un ente di terza parte abilitato a rilasciare un certificato digitale.
Il bisogno di stabilire quali siano le CA affidabili ha portato alla definizione di un ulteriore
componente specifico: il Membership Service Provider (MSP), che si occupa anche di identifi-
care i ruoli specifici che i partecipanti alla rete ricoprono nel contesto di questa organizzazione.
Il MSP rappresenta la rete così definita, precisando i privilegi di accesso dei canali e, più
generalmente, della rete.
Chaincode e smart contract
Gli smart contract definiscono la logica di business eseguibile che genera nuove informazioni
da inserire all’interno del ledger, mentre con chaincode ci si riferisce tipicamente a insiemi di
smart contract raggruppati in base a logiche simili. In particolare, uno smart contract definisce
le regole di interazione tra organizzazioni diverse attraverso codice eseguibile: le applicazioni
invocano uno smart contract per generare transazioni, che saranno inserite nel ledger di tutti i
partecipanti al canale in cui è stato istanziato il chaincode contenente lo smart contract invocato.
Ad esempio, uno smart contract potrebbe garantire che la consegna di una nuova auto venga
effettuata entro un periodo di tempo specificato o che i fondi vengano rilasciati secondo i termini
prestabiliti, migliorando in questo modo il flusso di merci o di capitale.
In Hyperledger Fabric, molto spesso si usano i termini smart contract e chaincode in modo
intercambiabile. In generale, uno smart contract definisce la logica di transazione che controlla
il ciclo di vita di un oggetto di business contenuto nella world state; esso viene quindi incapsulato
in un chaincode in modo da poter essere rilasciato nella rete blockchain. In altre parole, gli smart
contract sono le transazioni che modificano il ledger mentre il chaincode è la componente che
regola il modo in cui gli smart contract vengono messi in package, pronti per essere distribuiti
fra i peer dello stesso canale.
Naturalmente, uno smart contract può accedere alle informazioni presenti nel ledger: nello
specifico può eseguire operazioni di inserimento ed eliminazione di elementi nella world state
ed interrogazioni, sia alla world state che alla blockchain.
Associata ad ogni chaincode c’è una politica di endorsement, applicata agli smart contract
definiti con essa, la quale indica quali organizzazioni nella rete debbano firmare una transazione
generata da uno smart contract affinché tale transazione sia considerata valida. Ad esempio,
una politica di endorsement può dichiarare che una transazione necessiti di essere firmata da tre
organizzazioni che partecipano alla stessa rete prima di essere considerata valida. È importante
sottolineare che tutte le transazioni, valide o non valide, vengono aggiunte alla blockchain del
ledger ma solo quelle valide aggiornano la world state.
Le politiche di endorsement sono ciò che rende Hyperledger Fabric diversa dalle altre blockchain
come Ethereum o Bitcoin: in questi sistemi una transazione valida può essere generata da ogni
nodo nella rete. Fabric, a differenza, modella la tecnologia blockchain per adattarla alle esigenze4.3. HYPERLEDGER FABRIC 21
aziendali: le transazioni devono essere validate da organizzazioni riconosciute e ritenute sicure
ed affidabili.
La piattaforma Fabric possiede un chaincode di sistema adibito alla riduzione dei costi di
comunicazione gRPC tra peer e chaincode e, al momento della stesura di questa tesi, svolge
mansioni di gestione del ciclo di vita del chaincode, gestione della configurazione dei canali ed
esposizione di API per l’interrogazione dei ledger.
Il ciclo di vita di un chaincode è descritto come segue: il codice sorgente, presente nel file
system di un endorsing peer, viene installato lanciando un opportuno comando da terminale.
Anche se installato, un chaincode non è ancora utilizzabile dai partecipanti della rete: occorre
lanciare il comando di istanziazione da terminale, in questo modo esso viene installato in tutti i
peer che partecipano allo stesso canale, diventando disponibile ed eseguibile.
Ogni chaincode istanziato può essere aggiornato tramite una procedura simile all’istanziazione:
l’aggiornamento viene notificato e succesivamente installato in tutti i peer del canale e le
successive invocazioni di uno smart contract incapsulato nel suddetto chaincode verrà indirizzato
automaticamente alla nuova versione.
Ordering service
Nell’ambito delle blockchain permissionless, come ad esempio Ethereum e Bitcoin, ogni nodo
può partecipare al processo di consenso che consiste nell’ordinamento delle transazioni e nella
scrittura delle stesse in blocchi concatenati. Si è quindi costretti a fare affidamento ad algoritmi
che determinino la sequenza delle transazioni in modo probabilistico; da tali algoritmi non è
assicurato il determinismo poiché due o più peer possono avere una visione diversa sull’ordine
delle transazioni. Questa circostanza negativa è conosciuta come Fork, illustrata nella sezione
3.2.1.
Hyperledger Fabric funziona diversamente: fornisce un nodo speciale chiamato orderer
che orchestra l’ordinamento delle transazioni. Questo processo prende il nome di ordering
service e vi prendono parte tutti gli orderer relativi alle diverse organizzazioni esistenti nella
rete. Questo assicura:
∗ determinismo, poiché ogni blocco che viene validato da un peer è considerato finale e
corretto dal momento che viene generato dall’orderer, eliminando il rischio di Fork;
∗ efficienza di performance e scalabilità, poiché la separazione delle responsabilità di
endorsing del chaincode e di ordering delle transazioni elimina possibili colli di bottiglia
che possono verificarsi quando esecuzione del chaincode e ordinamento delle transazioni
sono operate dallo stesso nodo.
Gossip Data Dissemination Protocol
Come detto nella precedente sezione, Fabric opera un disaccoppiamento delle responsabilità
dividendo il carico di lavoro tra esecuzione delle transazioni ed ordinamento delle stesse, la
prima operata dagli endorsing e committing peer mentre la seconda dai nodi orderer. Serve, a
questo punto, un protocollo di propagazione delle informazioni che sia affidabile, scalabile e
che assicuri la consistenza dei dati: il Gossip Data Dissemination Protocol2 . Tale protocollo
pone le sue fondamenta sullo scambio continuo di messaggi, contenenti informazioni circa
lo stato del ledger e la firma del peer che ha inviato il messaggio, tra i nodi facenti parte
dello stesso canale. In questo modo, i peer che intendono falsificare messaggi sono facilmente
identificabili e coloro che perdono o ricevono in ritardo un messaggio aggiorneranno il loro
2 d’ora in poi riferito come protocollo gossipPuoi anche leggere
