Gestione ﬁliera alimentare tramite blockchain · 2020. 2. 20. · nella catena di produzione di...

Gestione filiera alimentare tramiteblockchain

Studente/i

Francesco Bresciani

Relatore

Giacomo Poretti

Correlatore

-

Committente

Laboratorio Cantonale

Corso di laurea

Ingegneria Informatica PAP

Modulo

Progetto di diploma

Anno

2019

Data

5 settembre 2019

i

AbstractOggi, più che mai, il consumatore preferisce acquistare prodotti alimentari di cui può co-

noscere l’origine delle materie. Il progetto si propone di dimostrare, attraverso il traccia-

mento della filiera del Formaggio d’Alpe Ticinese DOP, che è possibile sviluppare un’appli-

cazione basata su blockchain che sia sufficientemente semplice da essere impiegata per il

tracciamento delle filiere corte come quelle dei prodotti tipici del nostro territorio.

Sono state individuate e analizzate diverse applicazioni esistenti che si propongono di

fornire un ecosistema digitale in cui gli attori di una filiera possano raccogliere le informazioni

relative ad un prodotto e presentarle al consumatore attraverso un dispositivo mobile. Nel-

l’ambito del progetto è stato sviluppato un prototipo che ha permesso di mettere a confronto

diverse soluzioni tecnologiche e fornire indicazioni per una futura implementazione.

L’applicazione sviluppata dimostra come sia possibile godere dei benefici dell’impiego

della blockchain escludendo la complessità e i gli elevati costi delle altre soluzioni. Grazie ad

una approccio di questo tipo, anche i piccoli produttori possono offrire ai propri consumatori

una visione trasparente del processo di creazione di un determinato prodotto.

Il progetto offre solide basi su cui sviluppare un’applicazione per il tracciamento di

molteplici filiere permettendo di integrare non solo produttori, rivenditori e consumatori ma

anche enti di controllo e enti di certificazione dando coì ancora più valore ai pregiati prodotti

ticinesi.

Gestione filiera alimentare tramite blockchain

i

AbstractToday, more than ever, consumers prefer food that the source of the raw material it’s produ-

ced with is known.

The project, through the study of the supply chain of the traditional cheese produced on

the southern-swiss alps, aims to provide the evidence that we can build a blockchain-based

application simple enought to be used to track the short supply chain that characterize the

production of our local products.

We found and studied a moltitude of existent applications that aim to create a digital en-

vironment where the supply chain participants can record informations about a product and

show them through a mobile device. The develpment of the project allowed us to compare

different technologies and supply valuable insights for future development.

The proposed application is the evidece that it’s possible to benefit from the use of the

blockchain technology avoiding the complexity and high-costs of the other existent solutions.

Using an approach like the one proposed, also little producers can provide a transparent

view of the creation process of their products.

The project provides a strong bottom line on top of wich is possible to develop an appli-

cation to track different supply chains allowing certification authorities and legal authorities

to join producers, retailers and consumers in giving value to the finest local products.


ii


iii

Indice

1 Introduzione e contesto 1

1.1 Laboratorio cantonale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Scopo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Obiettivi del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Definizioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.1 Filiera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.2 Tracking e Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.3 Importanza della tracciabilità nella filiera agroalimentare . . . . . . . . 3

1.4.4 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.4.1 Caratteristiche della blockchain . . . . . . . . . . . . . . . . . 7

1.4.4.2 Tipologie di blockchain . . . . . . . . . . . . . . . . . . . . . 9

1.4.4.3 Funzionamento della blockchain . . . . . . . . . . . . . . . . 10

1.4.5 Merkle Tree e DAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.5 Formaggio d’Alpe Ticinese DOP . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Stato dell’arte 15

2.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Bitcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.2 Hyperledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.3 Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.4 Quadrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Soluzioni che non fanno uso di una blockchain . . . . . . . . . . . . . . . . . 18

2.2.1 Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.1.1 SIG Connected pack . . . . . . . . . . . . . . . . . . . . . . 19

2.2.2 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.3 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.4 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.5 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Soluzioni che fanno uso di una blockchain . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Esempi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


iv INDICE

2.3.1.1 TE-FOOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1.2 IBM Food Trust . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.1.3 Foodchain DApp . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.2 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.3 Caratteristiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.4 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.5 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4 IPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Soluzione 27

3.1 Definizione finalità progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Scelte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Perché la blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1.1 Paragone tra blockchain e database . . . . . . . . . . . . . . 30

3.2.2 Perché IPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.3 Perché Foodchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.4 Perché Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.5 Perchè un VPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.3 Funzionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Vantaggi e svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.5 Architettura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6 Architettura dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.7 Considerazioni sulla sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Conclusioni 45

4.1 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


v

Elenco delle figure

1.1 Risposte ad un sondaggio sulla tracciabilità alimentare . . . . . . . . . . . . . 4

1.2 Ordinanza sulle derrate alimentari . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Diagramma sistemi centralizzati, decentralizzati, distribuiti . . . . . . . . . . . 9

1.4 Mappa svizzera dei prodotti DOP . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5 Etichetta Formaggio d’Alpe Ticinese DOP . . . . . . . . . . . . . . . . . . . . 13

2.1 Servizi SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Componenti TE-FOOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Diagramma decisionale per l’impiego di blockchain . . . . . . . . . . . . . . . 29

3.2 Pagina tracking su mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Contadino admin page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Casaro admin page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.5 Rivenditore admin page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6 Diagramma archietettura del sistema . . . . . . . . . . . . . . . . . . . . . . 41

3.7 Diagramma archietettura dei dati . . . . . . . . . . . . . . . . . . . . . . . . . 42


vi ELENCO DELLE FIGURE


1

Capitolo 1

Introduzione e contesto

Nel capitolo introduttivo sono contenute la descrizione dello scopo e la descrizione degli

obiettivi del progetto. In questo capitolo vengono anche fornite informazioni e definizioni utili

a comprendere il contesto in cui il progetto si è svolto.

1.1 Laboratorio cantonale

Il Laboratorio Cantonale[1] è un ente statale che fa parte del Dipartimento della sanità e della

socialità[2], Divisione della Salute Pubblica[3]. Il laboratorio cantonale, attraverso attività

ispettive, analitiche e amministrative, svolge molteplici incarichi tra cui l’esecuzione della

legislazione federale sulle derrate alimentari.

Altri compiti riguardano l’esecuzione della legislazione federale sugli oggetti d’uso,

si occupa di incarichi nell’ambito della radioprotezione ed esegue inoltre le prescrizioni

cantonali in materia di acque balneabili.

Le attività del Laboratorio cantonale sono prevalentemente di controllo ufficiale e so-

no essenzialmente volte alla salvaguardia della salute pubblica nonché alla tutela dei

consumatori dalle frodi.

In Svizzera diverse autorità del settore sanitario, veterinario e agricolo contribuiscono a

garantire un elevato livello di sicurezza delle derrate alimentari e degli alimenti per animali.

1.2 Scopo del progetto

In sintonia con gli incarichi e le attività del committente (i.e. Laboratorio Cantonale), lo scopo

del progetto è di sviluppare un sistema che permetta al consumatore di avere maggiore

consapevolezza del prodotto che acquista grazie alla possibilità di accedere a informazioni

di cui può essere garantita la veridicità.


2 Introduzione e contesto

1.3 Obiettivi del progetto

Gli obiettivi del progetto sono:

• Fornire indicazioni riguardo il rapporto esistente tra il contesto del progetto 1 e il

contesto tecnologico attorno alla blockchain

• Fornire riflessioni riguardo una possibile architettura del sistema

• Sviluppare un software che funga da prototipo e che sia di semplice utilizzo. I dati

devono essere persistiti su blockchain

1.4 Definizioni

1.4.1 Filiera

Con filiera si intende l’insieme delle attività, dei flussi di materiali, dei flussi di informazioni,

delle tecnologie, delle risorse e delle organizzazioni che concorrono alla creazione, tra-

sformazione, distribuzione, commercializzazione e fornitura di un prodotto finito. In senso

più stretto, si intende l’insieme delle aziende che concorrono alla catena di fornitura di un

prodotto.

Sono inclusi aspetti di controllo sull’origine e sulla trasformazione di un prodotto che ne

garantiscono la validità tutelando la sicurezza intermedia e finale.

La filiera può essere semplice(corta) o complessa(lunga) a seconda di quanti passaggi

subisce il prodotto prima di arrivare allo stato finito. Le filiere alimentari sono considerate di

primaria importanza perchè costituiscono la base dell’alimentazione umana.

Una filiera è detta implosiva quando da un prodotto finito si vogliono ricercare tutti i prodotti

che hanno concorso alla sua realizzazione. Una filiera è detta esplosiva quando da un

prodotto si vogliono trovare tutti i suoi derivati.

1.4.2 Tracking e Tracing

Con il termine tracciabilità, tracking in inglese, si intende il processo volto a raccogliere

mano a mano tutte le informazioni necessarie a tenere traccia degli elementi in ingresso

che vanno a creare, modificare o trasformare un prodotto.

Con il termine rintracciabilità, tracing in inglese, si intende il processo che torna indietro

nella catena di produzione di un prodotto, al fine di ricercare un preciso evento o un’azione.

Quindi le azioni di tracciabilità e rintracciabilità sono volte a comunicare cosa sto facendo

mentre lo sto facendo e archiviare le informazioni come dato2 in modo che chi verrà dopo di

me sappia con precisione cosa è stato fatto, quando ed in che modo3.1territorio ticinese, filiera Formaggio d’Alpe Ticinese DOP2tracciabilità3rintracciabilità


3

1.4.3 Importanza della tracciabilità nella filiera agroalimentare

In questa sezione viene riportato il punto di vista di diverse entità riguardanti l’importanza

della tracciabilità nella filiera agroalimentare. Verranno esposti concetti provenienti dalla

consultazione di documenti e regolamenti prodotti dalla FAO (Food and Agriculture Orga-

nization of the United Nations) 4, dall’IFIC (International Food Information Council Founda-

tion), dal Parlamento Europeo e infine dalla Confederazione Svizzera.

La FAO, [4] tramite una pubblcazione intitolata Food Traceability Guidance[5] pubblicata

nel 2017, si propone di fornire delle linee guida utili alle aziende di tutto il mondo che operano

nella food industry per la corretta implementazione di un sistema di tracciabilità dei prodotti.

Nel documento è ampiamente argomentato come la tracciabilità dei prodotti alimentari

• porterebbe un enorme beneficio a livello sociale

• possa essere effettiva solo se vi partecipassero tutti gli attori della filiera

• dipenda della completezza e correttezza delle informazioni raccolte

Secondo l’IFIC la tracciabilità dei prodotti alimentari è uno dei top trends del 2019 in

ambito food. [6]

In particolare è molto interessante leggere il paragrafo:

Consumers want to know how their food is produced, where it came from and

the quality of the ingredients. They also have broader questions about environ-

mental sustainability, and many seek brands that align with their broader social

values.

La crescita del trend della tracciabilità alimentare in questo periodo storico è evidente con-

sultando il seguente grafico che riporta le percentuali di persone che hanno risposto al-

la domanda "Compreresti un prodotto di una marca differente da quella a cui sei abi-

tuato se questa offrisse informazioni più approfondite di quelle riportate sull’etichetta del

prodotto?"[6],

4è un istituto specializzato delle Nazioni Unite con lo scopo di contribuire ad accrescere i livelli di nutrizione,aumentare la produttività agricola, migliorare la vita delle popolazioni rurali e contribuire alla crescita economicamondiale. La FAO lavora al servizio dei suoi paesi membri per ridurre la fame cronica e sviluppare in tutto ilmondo i settori dell’alimentazione e dell’agricoltura.



Figura 1.1: Risposte ad un sondaggio sulla tracciabilità alimentare


5

Il Regolamento (CE) N. 178/2002 del Parlamento Europeo e del Consiglio, in vigore

dal 1 gennaio 2005, che regola la tracciabilità alimentare indica l’obbligo di

ricostruire e seguire il percorso di un alimento, di un mangime, di un animale de-

stinato alla produzione alimentare o di una sostanza destinata o atta ad entrare

a far parte di un alimento o di un mangime attraverso tutte le fasi della produzio-

ne, della trasformazione e della distribuzione. Gli operatori del settore alimen-

tare devono quindi disporre di sistemi e procedure che consentano di mettere

a disposizione delle autorità competenti, che lo richiedano, queste informazio-

ni in tutte le fasi della produzione, della trasformazione e della distribuzione la

rintracciabilità degli alimenti:

• chi ha fornito loro un alimento, un mangime o qualsiasi sostanza entrata a

far parte di un alimento

• individuare le imprese alle quali hanno fornito i propri prodotti “. . . .

L’Ordinanza sulle derrate alimentari e gli oggetti d’uso (ODerr) [7] si esprime come

segue sull’argomento tracciabilità in ambito agroalimentare:



Figura 1.2: Ordinanza sulle derrate alimentari


7

1.4.4 Blockchain

La blockchain è un registro digitale distribuito5 composto da blocchi concatenati tra loro che

seguono delle regole molto rigide per quanto riguarda la loro creazione, le tempistiche con

cui vengono creati e il contenuto dei blocchi stessi. 6 Il registro è pubblico, distribuito ed

immutabile.

Un Distributed Ledger Technology è composto da: [8]

• un modello di dati che conserva lo stato attuale del registro7

• un linguaggio per cambiare lo stato del registro attraverso l’esecuzione di transazioni

(smart contracts8)

• un protocollo che garantisce il consenso sulle transazioni eseguite e quindi sullo stato

attuale del registro 9

Distributed Ledgers esistevano prima che venisse inventata la blockchain. Anche il

concetto di Smart Contract esisteva prima che venisse inventata la prima blockchain10.

La blockchain è nata grazie all’utilizzo congiunto di diverse tecnologie e concetti che

includono:

• crittografia

• reti P2P11

• transazioni a cui è associato un time-stamp

• algoritmo di consenso

• potenza di calcolo condivisa

1.4.4.1 Caratteristiche della blockchain

In questa sezione vengono descritte le caratteristiche della blockchain.

5in inglese: Distributed Ledger(DL), è una particolare struttura di dati che risiede su diversi computer.6in inglese: Distributed Ledger Technology(DLT)7consiste in una serie di transazioni crittograficamente securizzate a cui è associato un time-stamp8gli Smart contracts sono delle porzioni di codice (programmi) che vengono eseguite quando si verificano

determinate condizioni9per consenso si intende un processo portato a termine dai computer appartenenti ad una rete volto a sincro-

nizzare i dati di un registro. Il consenso in una rete porta tutti i partecipanti della rete stessa a riconoscere comevalida e corretta una stessa versione dei dati contenuti nel registro. Un algoritmo di consenso ha quindi duefinalità: garantire che i dati sia uguali in ogni copia del registro e prevenire che partecipanti malintenzionati pos-sano manipolare i dati. Esistono diversi algoritmi di consenso e le blockchain non utilizzano necessariamenteuno stesso algoritmo per raggiungere il consenso.

10Bitcoin11peer to peer è un architettura di rete in cui non esiste un punto centrale come inteso in un’architettura

client-server



Pubblica perchè chiunque abbia accesso ad internet può leggere i dati in essa conte-

nuti è sufficiente essere in possesso di un wallet.

Distribuita perchè una copia del registro è presente su ognuno dei nodi della rete

P2P costituita dagli utilizzatori della blockchain stessa. L’integrità dei dati è garantita da un

algoritmo di consenso che non permette che esistano copie tra loro diverse del registro.


9

Figura 1.3: Diagramma sistemi centralizzati, decentralizzati, distribuiti

Immutabile perchè l’algoritmo di consenso fa in modo che i nodi si controllino vicende-

volmente in maniera continua con lo scopo di non permettere a nessun nodo di propagare

informazioni diverse da quelle contenute nelle altre copie del registro.

Trustless nel senso che ogni utente connesso alla rete non ha bisogno di fidarsi della

controparte, o di un intermediario centrale, per poter effettuare una transazione. La fiducia

dell’utente è infatti tutta riposta nella tecnologia ed in particolare nel software e nel protocollo

su cui questa è strutturata.

Trasparente perchè le transazioni e le informazioni che vengono registrate sul databa-

se distribuito sono accessibili e visibili a chiunque faccia parte della rete.

1.4.4.2 Tipologie di blockchain

Esistono tre tipi di blockchain: pubblica, privata e mista, chiamata anche consortium block-

chain. Public Blockchains Le blockchain pubbliche sono quelle di cui più spesso si sente

parlare. Le più famose sono Bitcoin, Litecoin ed Ethereum. Questa tipologia di blockchain

è la più libera ed aperta che esiste. Semplicemente chiunque può leggere, scrivere e fare

mining.

Private Blockchains Le blockchain private, chiamate anche permissioned blockchains

sono delle blockchain a cui si può accedere per eseguire operazioni di lettura e scrittura solo

se si è in possesso dell’autorizzazione di chi l’ha realizzata e con il permesso dell’owner dei

dati. In queste blockchain è anche possibile eliminare e sovrascrivere dati già salvati sulla

blockchain. Le blockchain private perdono dunque la caratteristica di essere immutabili e

anche la caratteristica di essere decentralizzate. Questo ne rende l’impego limitato a chi

necessita di un database distribuito reso sicuro tramite meccanismi criptografici. I vantaggi



di questo tipo di blockchain sono la possibilità di sfruttare le caratteristiche di una blockchain

limitatamente ai confini dell’azienda o dell’organizzazione che ne fa uso. Siccome non è

necessario avere un’elevata complessità dell’algoritmo che gestisce il consenso, i tempi per

le operazioni di scrittura sono sensibilmente ridotti rispetto a quelli necessari ad eseguire lo

stesso tipo di operazione su blockchain pubblica.

Consortium Blockchains Le blockchain miste sono una via di mezzo tra le pubbliche

e le private. L’accesso è ristretto solo a chi ne ha l’autorizzazione ma le consortium bloc-

kchains godono della proprietà di essere distribuite. Non sono necessari tempi lunghi per

raggiungere il consenso e sono più sicure delle blockchain private perchè non c’è un single

point of failure.

1.4.4.3 Funzionamento della blockchain

Almeno una parte dei nodi di una blockchain hanno il ruolo si miner. Un miner si occupa

di validare le transazioni e creare nuovi blocchi. Dopo aver eseguito la computazione ne-

cessaria a risolvere il problema fornito dall’algoritmo di consenso, il miner, è incentivato a

pubblicare la soluzione perchè riceve un reward. Di ogni blocco di transazioni validate e in-

cluse in un blocco, viene fatto un hash, che è incluso nel successivo blocco come puntatore

al precedente formando così una catena di blocchi immutabili. L’immutabilità di una block-

chain è data dal fatto che per modificare i dati è richiesta un’enorme capacità di calcolo per

"convincere" il 51 per cento dei nodi del risultato di una transazione creata in maniera ma-

levola con lo scopo di alterare lo stato del registro sia necessaria una forza computazionale

elevatissima che avrebbe più senso impiegare per fare mining.

1.4.5 Merkle Tree e DAG

Il concetto di hash tree è stato brevettato nel 1979 da Ralph Merkle, un crittografo statuni-

tense che si è applicato nella crittografia a chiave pubblica. In crittografia un hash tree, o

Merkle Tree, è una struttura di dati ad albero in cui ad ogni foglia è associata un’etichetta

con l’hash di un blocco di dati. Ad ogni nodo non foglia è associato un hash delle etichet-

te dei suoi nodi figli. L’impiego di hash tree rende semplice, veloce e sicura la verifica del

contenuto di una struttura dati di grandi dimensioni.

Un Merkle DAG, Merkle Directed Acyclic Graph, è una struttura dati simile ai Merle

Tree ma meno rigorosa nel senso che un Merkle DAG non deve necessariamente essere

bilanciato e i nodi non foglia possono contenere dati.

1.5 Formaggio d’Alpe Ticinese DOP

La filiera del Formaggio d’Alpe Ticinese DOP è una filiera corta infatti i prodotti vengono

per lo più consumati in zone geograficamente vicine a quelle di produzione. I passaggi che


11

portano dalla materia prima al prodotto finito sono di numero limitato.

I prodotti DOP 12 o IGP 13 sono specialità tradizionali con un forte legame con la propria

regione di origine. Da generazioni sono realizzati con il cuore e l’anima di casari, panettieri,

macellai e distillatori. Nei prodotti DOP tutto proviene da una regione di origine ben definita,

dalla materia prima alla lavorazione fino al prodotto finito. Le specialità IGP sono prodotte,

trasformate o raffinate nel luogo di origine. DOP e IGP sono marchi di qualità protetti dalla

legislazione svizzera. Dopo la registrazione da parte dell’Ufficio federale dell’agricoltura, le

denominazioni protette possono essere utilizzate solo per i prodotti che soddisfano i requisiti

di origine, di processo e di qualità delle specifiche. Organismi di certificazione indipendenti

controllano la conformità.

12denominazione di origine protetta13indicazione geografica protetta



Figura 1.4: Mappa svizzera dei prodotti DOP

In svizzera 22 prodotti tra pani, formaggi, salumi e distillati sono certificati DOP e 15

prodotti sono certificati IGP.[9] Tra i più famosi figurano la Gruyère dOP, lo Sbrinz DOP, il

Raclette du Valais DOP e il Formaggio d’Alpe Ticinese DOP.

Il Formaggio d’Alpe Ticinese DOP viene prodotto e lavorato nelle aziende di estivazione

dei Comuni riportati nel capitolato d’oneri nel Canton Ticino, dal 1 giugno al 30 settembre.

Il Formaggio d’Alpe Ticinese DOP viene prodotto quotidianamente in vasche di rame

principalmente dal latte crudo di vacca. Poiché l‘estivazione delle capre gode di una lunga

tradizione in Ticino, ne nacque la necessità di unire questi due tipi di latte prima della pro-

duzione casearia. In base al capitolato d’oneri, può essere aggiunto fino al 30 % di latte

di capra. La ricca flora alpina, che funge da nutrimento per le vacche e le capre, dona a

questo latte un aroma sottile. Le forme appena pressate vengono poi immerse in salamoia

per 24 ore. Fino all’alpe, le forme vengono pre-stagionate su tavole in legno di abete rosso

o di larice. La durata minima della stagionatura è di 45 giorni.[10]


13

Figura 1.5: Etichetta Formaggio d’Alpe Ticinese DOP

Nel 2017 gli alpi in cui il Formaggio d’Alpe Ticinese DOP è stato prodotto sono state 38.

Al momento della scrittura di questo docuemnto non sono disponibili dati relativi al 201914

e al 2018.15[11]

14la stagione non è ancora conclusa15Angone Crestumo - Val Faido, Bolla Carassina - Val Blenio, Bolla e Froda - Val Lavizzara, Bresciana - Val

Blenio, Cadonigo - Val Prato Leventina, Camadra - Val Blenio, Campo la Torba - Val Lavizzara, Carì - Val Faido,Cava - Val Biasca, Cioss Prato - Val Bedretto, Cristallina - Val Bedretto, Croce Lucomagno - Val Blenio, Fieud- Val Airolo, Formazzora - Val Bedretto, Fortunei - Val Airolo, Fümegna - Val Lavertezzo, Garina Pusced - ValAcquarossa e Serravalle, Geira - Val Dalpe, Giumello - Val Sant’Antonio, Gorda - Val Blenio, Grossalp - ValBosco Gurin, Lucomagno - Val Blenio, Manegorio - Val Bedretto, Motterascio - Val Blenio, Pertusio - Val Blenio,Pesciüm - Val Airolo, Pian Daioss - Val Acquarossa, Pian Laghetto - Val Acquarossa, Piora - Val Quinto, PiotaCrozlina - Val Faido, Pontino - Val Airolo, Prato-Ambrì - Val Quinto, Pradasca - Val Blenio, Rovina - Val Piotta,Sfille - Val Campo Valle Maggia, Sorescia - Val Airolo, Stabiello - Val Bedretto, Vogornesso - Val Sonogno.[11]


15

Capitolo 2

Stato dell’arte

Nella sezione 1.4.4 viene riportata una definizione di blockchain e e una descrizione delle

sue caratteristiche. In questo capitolo viene fatta un’analisi delle blockchain più diffuse e più

adatte ad essere impiegate per lo sviluppo di soluzioni in ambito supply chain. In questo

capitolo viene anche riportata una descrizione dei software per la tracciabilità della filiera

agroalimentare già esistenti sul mercato seguita da un’analisi comparativa tra le soluzione

che fanno uso di blockachain e quelle che non ne fanno uso. In questo capitolo viene

anche inclusa una descrizione del protocollo IPFS1 che, come vedremo, è un componente

fondamentale del software sviluppato.

2.1 Blockchain

In questa sezione vengono descritte le blockchain più diffuse. Ad oggi esistono molte

più di mille criptomonete ed ognuna di esse ha una propria blockchain sulla quale viene

scambiata. Ogni giorno nascono nuove criptomonete e, con esse, nuove blockchain.

2.1.1 Bitcoin

Bitcoin è attualmente la criptovaluta più diffusa e la blockchain di Bitcoin è attualmente la

più diffusa e utiilzzata. Il numero di transazioni eseguite quotidianamente è infatti molto più

elevato rispetto al numero di transazioni eseguite su qualsiasi altra blockchain. Sul web

si trovano tantissimi articoli che raccontano la storia di bitcoin e cosa sta dietro a questa

criptomoneta dal valore così elevato. Di nostro interesse però non è la criptomoneta ma la

tecnologia su cui si appoggia. Bitcoin è stata inventata nel 2009 da una persona, o gruppo,

che si fa chiamare Satoshi Nakamoto. Lo scopo della tecnologia proposta nel è di creare un

nuovo sistema di scambio di valuta digitale completamente decentralizzato e che non dipen-

da da nessuna autorità centrale. 2 Bitcoin è stata la prima implementazione di blockchain.

1Inter Planetary File System2tradotto dal whitepaper di bitcoin[12]


16 Stato dell’arte

La rete bitcoin è in grado di supportare solo 7 transazioni al secondo, ciò la rende molto più

lenta di altri sistemi che hanno finaloità simili. Il circuito VISA per esempio ne può gestire

24,000 al secondo. Ethereum, al momento, è in grado di elaborarne 15. Il limite di bitcoin

è la sua scarsa programmabilità. Bitcoin infatti è adatta al semplice immagazzinamento, in

blocchi immutabili, di dati relativi alle transazioni. Come vedremo successivamente, altre

blockchain sono in grado di eseguire porzioni di codice, chiamati smart contracts all’avveni-

re di un determinato evento. Per questo motivo bitcoin non è la blockchain più adatta ai fini

del progetto.

Bitcoin utilizza un algoritmo di consenso chiamato Proof of Work.

2.1.2 Hyperledger

Hyperledger è un progetto open source iniziato nel 2015 creato e seguito dalla Linux Foun-

dation. Linux è il più grande progetto opensource del mondo. Tra i molti progetti della Linux

Foundation, che garantisce la protezione e accelera lo sviluppo del kernel di Linux, c’è il

progetto Hyperledger che ha lo scopo di promuovere la trasparenza e la fiducia tra azien-

de che collaborano. Hyperledger quindi vuole rendere più efficienti le reti di business e le

transazioni che avvengono tra i business appartenenti ad una stessa rete.

Hyperledger è una blockchain permissioned a differenza di Bitcoin ed Ethereum che

sono permission-less. 3

Hyperledger è composto da librerie, moduli (tools) e frameworks. Un Hyperledger

Framework è composto da:

• un registro distribuito (DL) "append-only"

• un algoritmo di consenso

• gestione degli accessi e della privacy

• supporto per smart contracts

I frameworks di Hyperledger sono: Iroha, Sawtooth, Fabric, Indy e Burrow. I moduli di

Hyperledger sono Cello, Explorer e Composer. Le librerie di Hyperledger sono Aries, Quilt,

Transact e Ursa.

I moduli sono sviluppati per uno specifico framework ma poi sono resi utilizzabili anche

da altri framework grazie a dei "connettori" appositamente sviluppati. Ogni frameowrk ha

caratteristiche che lo rende adatto ad uno specifico scopo o più orientato ad un determinato

tipo di impiego. Iroha per esempio è orientato allo sviluppo di applicazioni mobile ed è con-

cepito per essere facilmente incluso in un progetto. Sawtooth è modulare, flessibile e offre

supporto per lo sviluppo sia di reti permissioned che permissionless. Fabric è stata la prima

3esiste un’eccezione che riguarda il framework Sawtooth che può essere configurato permissionless


17

proposta di Hyperledger ed è particolamente interessante nel caso in cui si vogliano crea-

re dei tunnel privati con un sottoinsieme dei partecipanti. Indy è sviluppato appositamente

per la gestione delle identità distribuite. Burrow è un framework ancora non completamente

maturo che si propone di integrare una EVM (Ethereum Virtual Machine).4 Di default ogni

framework utilizza un diverso algoritmo di consenso. 5

Una descrizione dei moduli e delle librerie non viene riportata perchè non utile ai fini

della trattazione. In bibliografia sono presenti diversi riferimenti utili oltre al sito ufficiale di

Hyperledger.[13]

2.1.3 Ethereum

Ethereum è una blockchain inventata nel 2015. Come tutte le altre blockchain è un adatta-

mento di bitcoin ma con uno scopo molto differente. L’esistenza di Ether, la criptomoneta

associata ad ethereum, è un effetto collaterale dell’esistenza della blockchain stessa. La

differenza tra bitcoin e ethereum è nello scopo. Mentre bitcoin è un registro di transazioni

finanziarie, ethereum ha lo scopo di fornire il "motore" per far funzionare un unico enorme

computer mondiale. Come bitcoin, ethereum è una blockchain pubblica e permissionless e,

come bitcoin, attualmente, utilizza un algoritmo di consensochiamato Proof of Work anche

se è già stato annunciato che lo stesso sarà rimpiazzato da un algoritmo Proof of Stake.

Ethereum permette di eseguire in maniera decentralizzata ciò che ci aspettiamo pos-

sa essere eseguito da un computer (eseguire programmi, salvare dati). Chiunque ospita

un nodo ethereum partecipa all’esecuzione della Ethereum Virtual Machine (EVM) che è,

appunto, il componente che permette di eseguire in maniera decentralizzata un program-

ma, ovvero, di eseguirlo sul computer di ogni partecipante. Gli smart contract di ethereum

sono scritti in un linguaggio moderno e developer-friendly. il linguaggio è Turing complete

che significa che si possono eseguire tutte le operazioni che ci si aspetta possano essere

eseguite in qualsiasi altro linguaggio di programmazione.

Come già accennato in precedenza, uno smart contract è un programma che viene

eseguito dalla blockchain all’avvenire di un determinato evento. Di seguitop viene descritto

più in dettaglio come questo avviene.

Il deployment di uno smart contract avviene tramite la creazione di un particolare tipo di

account che, oltre alle funzionalità di un account normale, contiene del codice. All’account

è ovviamente associato un indirizzo come per gli account normali. Per eseguire uno smart

contract sarà sufficiente inviare ether all’indirizzo che lo ospita e, se necessario, delle infor-

mazioni aggiuntive come parametro. Ogni nodo della blockchain eseguirà lo smartcontract

sulla sua EVM e includerà il risultato nel prossimo blocco che verrà minato. Il nodo che

"vincerà" nella pubblicazione del blocco, riceverà la ricompensa per il lavoro eseguito.

4una descrizione della EVM é disponibile alla sezione 2.1.35anche se in molti casi esso può essere scelto diverso da quello di default o addirittura essere cambiato

mano a mano che la rete cresce.



2.1.4 Quadrans

Quadrans è una fondazione svizzera con sede a Mendrisio, Ticino. La fondazione ha svilup-

pato una blockchain pubblica e open-source che deriva da un fork di ethereum ed è quindi

in grado di eseguire gli smart contracts sviluppati per la EVM. La piattaforma permette di

eseguire DApps che partecipano ad un’economia digitale sostenuta da un meccanismo di

rewarding interno.

Quadrans utilizza due assets criptografici: Quadrans Coin (QDC) e Quadrans Token

(QDT) che equivalgono a coin e token come sono concepiti per le altre blockchain e che

svolgono diverse funzioni. I QDC equivalgono ad ether per ethereum e fungono da reward

per i partecipanti alla rete. I QDC possono essere spesi insieme ai QDT come pagamento

per le transazioni. La verifica delle transazioni viene eseguita da due diversi tipi di nodo

della rete: i Miners e i Masternodes.

I masternodes gestiscono l’input degli users e suddividono il lavoro computazionale tra

i diversi miners che hanno invece lo scopo di scrivere sulla blockchain i blocchi immutabili

di transazioni come avviene in qualsiasi altra blockchain. Le blockchain pubbliche general-

mente adottano un algoritmo per il consenso che richiede un grande dispendio di energia

per essere soddisfatto. Quadrans, che vuole essere un’azienda energeticamente sostenibi-

le, adotta un algoritmo di consenso su più livelli che richiede la partecipazione di un numero

inferiore di nodi. I coin inoltre sono stati concepiti per avere un valore con bassissima volati-

lità, così da permettere ai partecipanti di fare previsioni accurate riguardo le spese derivanti

dall’utilizzo della piattaforma stessa. La prima implementazione fatta sulla blockchain Qua-

drans è la DApp Foodchain in ambito Food supply chain traceability. Maggiori dettagli sono

disponibili nella sezione 2.3.1.3

2.2 Soluzioni che non fanno uso di una blockchain

In questa sezione vengono presentati gli esempi di software per la tracciabilità della filiera

agroalimentare già esistenti sul mercato che non fanno uso di blockchain. Segue un’analisi

di questo tipo di soluzione.

2.2.1 Esempi

È stata trovata una sola soluzione che sembra offrire un servizio di elevato livello nonostante

non faccia uso di blockchain. Presumo che se questo documento fosse stato prodotto uno

o due anni fa, molte delle soluzioni che fanno uso di blockchain descritte nella sezione 2.3

fossero da includere tra le soluzioni che non ne fanno uso.

Non è stato possibile eseguire un’analisi tecnica delle soluzioni software già esistenti a

causa della mancanza di informazioni a riguardo. Si presuppone che il motivo per cui queste

informazioni non siano reperibili è probabilmente che le aziende che sviluppano questi pro-


19

dotti non è interessante fornrire alla concorrenza e alla stampa informazioni riguardanti la

loro implementazione. Inoltre, l’interesse dei clienti di queste aziende (produttori, traforma-

tori, distributori) non riguarda sicuramente le scelte implementative ma piuttosto i vantaggi

che adottare una soluzione di questo tipo possa portare alla loro azienda e ai loro clienti

(consumatori e altri attori della filiera).

2.2.1.1 SIG Connected pack

Tutte le informazioni riportate provengono dal sito ufficiale[14].

La SIG (SIG Combibloc Group AG) è un’azienda svizzera attiva dal 1860 dapprima co-

me produttrice di vagoni ferroviari e armi da fuoco (poi diventata SIG Sauer). Attualmente

SIG mette a disposizione le competenze acquisite nel mondo della fabbricazione e dell’in-

gegneraria dedicandosi allo studio e alla produzione di imballaggi come anche alla fornitura

di servizi legati al mercato del packaging.

In particolare i tre settori di cui si occupa sono:

• Product Innovation & Differentiation

• Smart Factory

• Connected Pack



Figura 2.1: Servizi SIG

Ai fini della trattazione è interessante il settore Connected Pack che riguarda la digita-

lizzazione del prodotto attraverso lo studio di soluzioni per la gestione della supply chain,

del tracciamento della filiera e del marketing digitale.

Al momento in cui viene scritto questo documento, nessuna fonte suggerisce che le

soluzioni proposte in ambito Traceability solutions facciano uso di blockchain.

2.2.2 Vantaggi

I vantaggi di una soluzione che non fa uso di blockchain sono sicuramente quelli derivanti

dall’impiego di una soluzione digitale piuttosto che cartacea. Alcuni possono essere:

• velocità di consultazione

• possibilità di integrazione con altri software

• eseguire analisi con gli stessi dati

2.2.3 Caratteristiche

Le due caratteristiche più importanti di cui prendere nota sono:

• il software è sviluppato per essere venduto all’azienda che lo deve utilizzare

• la proprietà dei dati è dell’azienda che li inserisce

• il potere di agire sui dati è nelle mani dell’azienda che fornisce il software


21

2.2.4 Focus

Il focus del materiale informativo infatti è sui benefici per chi usa il software, non sui bene-

fici per il consumatore. Ad elementi quali il ROI, la customer loyalty, la data collection e il

customer engagement è data molta più importanza di quanta ne sia data alla trasparenza,

benefici per il consumatore e agli aspetti ambientali e sociali. L’impressione è che il software

sia sviluppato per permettere all’azienda di digitalizzare il processo di tracking 6 e di miglio-

rare le performance del proprio business. Viene ripostata di seguito una frase presente sulla

homepage del sito di uno di questi software:

Want to learn more about what connected packaging can do for producers?

2.2.5 Considerazioni

Ciò che si può dedurre dall’analisi fatta è che, nonostante un software di questo tipo abbia

enormi vantaggi, esso non è in grado di soddisfare la necessità di garantire la veridicità

delle informazioni che il consumatore consulta. Inoltre è difficile immaginare come un ente

certificatore possa eseguire dei controlli senza dover richiedere accesso ai dati.

L’opinione dello scrittore è che nononstante sia evidente che è possibile eseguire trac-

king con tecnologie basate su database tradizionale, con queste soluzioni, non si riesce a

sfruttare a pieno le potenzialità della tecnologia e soprattutto non si riescano a mettere al

centro il consumatore e l’ambiente. Inoltre lasciare che le aziende possiedano i dati e ab-

biano solo loro accesso ad informazioni, se esistono, riguardanti chi ha inserito e modificato

le informazioni, rende questo tipo di soluzione solo superficialmente trasparente.

2.3 Soluzioni che fanno uso di una blockchain

In questa sezione vengono presentati gli esempi di software per la tracciabilità della filiera

agroalimentare già esistenti sul mercato basati su blockchain. Segue un’analisi di questo

tipo di soluzione.

2.3.1 Esempi

Per queste soluzioni è stato possibile eseguire un’analisi più approfondita delle tecnologie

utilizzate e della loro implementazione. Probabilmente il motivo è che le tecnologie utilizzate

sono opensource e che le aziende sono più orientate alla trasparenza e alla condivisione.

È disponibile una varietà enorme di soluzioni. Per l’analisi ne sono state scelte tre differenti.

6che come abbiamo visto nella sezione 1.4.3 è obbligatorio in molti paesi



Tra le più importanto che non sono state descritte figurano Provenance7, Certilogo - Viveat8,

OPTEL9.

2.3.1.1 TE-FOOD

TE-FOOD è un’azienda tedesca con sedi in Germania, Ungheria e Vietnam. Lo slogan

di TE-FOOD è "Farm-to-table food traceability on blockchain" ed il loro prodotto, basato

su Hyperledger 10, si propone di portare trasparenza, velocità nel richiamo di prodotti in

vendita, supporto nel rispetto delle leggi, riduzione della falsificazione dei prodotti e vantaggi

commerciali per chi adotta la piattaforma. 11 TE-FOOD propone un prodotto che supporta

tutti gli attori della supply chain. In figura 2.2 viene riportato un grafico in cui vengono

descritti i componenti offerti dalla piattaforma TE-FOOD tra cui gli attori della filiera possono

attingere.

7https://www.provenance.org/8https://www.certilogo.com/ - https://www.viveat.com/9https://www.optelgroup.com/food-and-beverage/

10vedi sezione 2.1.211gli stessi di cui si parla nella sezione 2.2


23

Figura 2.2: Componenti TE-FOOD

Come precedentemente indicato, TE-FOOD è sviluppata su Hyperledger[15]. La bloc-

kchain è infatti di tipo permissioned.

2.3.1.2 IBM Food Trust

IBM, che partecipa al progetto Hyperledger, in collaborazione con oltre 400 aziende che già

utilizzano prodotti IBM ad altri scopi, ha sviluppato un prodotto molto interessante e ampio

volto a sostenere le aziende che operano nel campo del food ad implementare un sistema

di tracciabilità dalla materia prima allo scaffale.

La soluzione di IBM è sviluppata con Hyperledger Fabric e Hyperledger Composer. Il

prodotto è veramente ampio e personalizzabile. Esistono anche API per poter integrare il

prodotto con un ERP già esistente che possono essere utilizzate anche per espandere le

funzionalità del prodotto stesso.

I vantaggi di impiegare questa soluzione sono: migliorare l’efficienza della supply chain,

ridurre gli sprechi, ridurre falsificazioni e frodi alimentari, aumentare la sostenibilità ed au-

mentare la fiducia nel marchio. [16]

Il prodotto è venduto come SaaS 12 ed è fornito suppporto da consulenti IBM certificati

e specializzati. Molta importanza è dedicata a chi possiede i dati. Come riportato sul sito

ufficiale: "L’utente li carica, li possiede e li controlla". Si fa leva quindi sul fatto che la block-

chain sia di tipo permissioned per garantire che i dati siano caricati solo da utenti noti e che

i dati vengano modificati e visti solo da chi ne ha il permesso.

2.3.1.3 Foodchain DApp

Foodchain SpA è un’azienda italiana fondata nel 2016 che fornisce servizi per la tracciabi-

lità di prodotti alimentari. Le sedi dell’azienda sono ubicate presso ComoNExT Innovation

HUB (Como), I3P (Torino) e Impact HUB Trentino (Trento). La DApp di Foodchain è stata

12Software-as-a-Service



sviluppata in collaborazione con la fondazione Quadrans. Foodchain è infatti costruita sulla

blockchain di Quadrans e ne costituisce la prima implementazione presente sul mercato.

La DApp ha lo scopo di fornire un ecosistema per la creazione di autenticità, sostenibi-

lità, sicurezza alimentare e garanzia di qualità dei prodotti. Foodchain si rivolge a produttori,

trasportatori, aziende di logistica, amministrazione pubblica, grande distribuzione organiz-

zata ed enti certificatori. Oltre al settore del food, la DApp è utilizzabile anche da operatori

della filiera tessile strettamente legata al territorio del Comasco in cui Foodchain è stata

sviluappata.

2.3.2 Vantaggi

I vantaggi derivanti dall’impiego della blockchain, coerentemente con quanto descritto nella

sezione 2.1, sono:

• maggiore trasparenza

• garanzia di alta diponibilità

• versione dei dati sempre coerente per tutti gli attori

• maggiore responsabilizzazione degli attori

a dipendenza della scelta del tipo di blockchain utilizzata, il focus può essere sulla

garanzia dell’immutabilità dei dati e la completa decentralizzazione del sistema13, oppure

la garanzia che le informazioni siano inserite solo da attori autorizzati e la possibilità di

mantenere la privacy e l’ownership dei dati immessi nella blockchain14

2.3.3 Caratteristiche

Come le soluzioni che non fanno uso di blockchain, questi prodotti forniscono strumenti

per migliorare il business ma ciò che veramente viene fornito da questo tipo di prodotto è

l’ecosistema che favorisce la collaborazione tra gli attori della filiera con lo scopo comune di

garantire la qualità e la trasparenza del prodotto fino al momento dell’acquisto da parte del

consumatore.

2.3.4 Focus

Il focus di questi prodotti è su:

• trasparenza

• responsabilità

13nel caso di impiego di una blockchain pubblica14nel caso di impiego di una blockchain permissioned. risultati simili si possono ottenere anche su blockchain

pubblica tramite accorgimenti appositi.


25

• autenticità (intesa come prodotti non contraffatti)

• sostenibilità energetica

• sostenibilità sociale

• riduzione degli sprechi

2.3.5 Considerazioni

È subito evidente come queste soluzioni siano molto più diffuse e adottate rispetto a soluzio-

ni che non fanno uso di blockchain. Sicuramente l’hype riguardante questo tipo di tecnologia

è favorevole alla nascita ed alla crescita di aziende che sviluppano prodotti che fanno uso

di blockchain. Sicuramente il focus più orientato al consumatore a ad aspetti sociale ed

ecologici favorisce l’adozione da parte degli attori della filiera e la fruizione da parte dei

consumatori. Una caratteristica comune è che tutti questi prodotti sono studiati per il trac-

ciamento anche molto dettagliato di filiere abbastanza complesse a cui partecipano aziende

di grandi dimensioni.

2.4 IPFS

IPFS (Inter Planetary File System), è un protocollo tramite il quale è possibile mettere in

comunicazione vari nodi della rete che mettono a disposizione dello storage in cui mante-

nere i file di un file system distribuito. IPFS, a differenza di HTTP, non utilizza dei percorsi

per descrivere dove si trova il file che stiamo cercando si trovi. Al contrario, IPFS, utilizza

un metodo chiamato content addressing per cui ad ogni file è associato un hash che viene

calcolato applicando una funzione di hashing al contenuto del file stesso. In questo modo

l’hash è univoco per ogni file e quindi l’hash può essere utilizzato anche come id del file

stesso.

Gli hash di IPFS sono chiamati multihash che è un id che contiene anche informazioni

riguardo l’algoritmo che è stato utilizzato per calcolare l’hash stesso. Lo scopo di questa

complicazione è che tramite multihash si può puntare a file il cui hash è stato calcolato con

funzioni diverse. Questo aumenta l’interoperabilità e permette di sostituire l’algoritmo nel

caso venisse scoperto che non è più sicuro come si pensava al momento in cui l’hash era

stato creato.

IPFS utilizza IPLD (Inter Planetary Linked Data) e i Merkle Tree già descritti nella sezio-

ne 1.4.5 che sono alla base delle tecnologie DLT. IPLD consiste in un meccanismo necessa-

rio a suddividere file grandi in porzioni di file che sono salvate e indirizzabili individualmente

nella rete ma che, attraverso dei link, sia possibile ricostruire il file originale. Ogni file, se

di dimensioni superiori a 256kB, viene suddiviso in diversi file ognuno dei quali ha un suo

hash. Esiste un nodo del DAG, che ha un suo hash, che noi interroghiamo per avere il



file intero. Questo nodo, oltre al suo indirizzo, ha un array di link ai nodi del DAG a cui si

trovano le sue parti. I nodi hanno anche una dimensione che è uguale alla somma della

dimenesione dei suoi dati più le dimensioni dei dati a cui i link puntano.

Linked Data è un concetto che sta alla base del web decentralizzato. Uno dei vandaggi

di IPFS è la deduplication che consiste nel fatto che caricando due copie identiche di un

file 15, l’hash sarà identico. Quindi nella rete IPFS non esisterà la necessità di occupare più

volte lo storage per tenere copie identiche dello stesso file.

IPFS ha anche un sistema per fare in modo che quando aggiorno il contenuto di un file,

siccome l’hash cambia, lo stesso non sarebbe più raggiungibile all’indirizzo originale16.IPNS

(Inter Planetary Naming System) permette di inserire un file su IPFS e associargli un hash

"statico" nel senso che a quell’indirizzo troviamo l’indirizzo dell’ultima versione del file.

Un vantaggio di IPFS è, come in tutti i sistemi decentralizzati, che il sistema non dipen-

de dallo stato di un determinato nodo per poter funzionare. Per esempio se un server fosse

in stato di non funzionamento non sarebbe possibile consultare un documento che questo

server ha il compito di fornire. Con IPFS si può presumere che questo file sia fornibile da

un nodo tra quelli attivi, non dipendendo quindi dallo stato di un nodo specifico.

15che possono essere visti anche come due file con lo stesso contenuto16si pensi per esempio ad una nuova release di un documento di cui noi abbiamo garantito l’accesso tramite ad

un determinato indirizzo. sarebbe necessario, ad ogni aggiornamento, informare tutti gli utilizzatori di utilizzareun nuovo indirizzo. e se questi utilizzatori fossero altri software?


27

Capitolo 3

Soluzione

Uno degli obiettivi del progetto, elencati nella sezione 1.3, è proporre un prototipo di sempli-

ce utilizzo i cui dati siano persistiti su blockchain. Nel seguente capitolo viene presentato il

risultato di questa fase del progetto. Il software non si prefigge di essere pronto per essere

messo in produzione ma, piuttosto, lo scopo è di proporre una struttura grafica e architet-

turale che possa essere utilizzata come base su cui ragionare per definire i requisiti per un

progetto diverso che si proponga di soddisfare le necessità del committente e della filiera.

Il processo di sviluppo del software di seguito descritto è stato fondamentale anche per il

raggiungimento degli altri obiettivi. Non sarebbe infatti stato possibile addentrarsi sufficien-

temente nel contesto da poter suggerire come affrontare la soluzione di dettagli funzionali e

tecnologici.

3.1 Definizione finalità progetto

In questa sezione viene descritto come si è pensato di affrontare il progetto per raggiungere

gli obiettivi in accordo con lo scopo del committente.

Per quanto riguarda la fase di descrizione del contesto e raccolta delle informazioni

necessarie a rispondere ai quesiti posti, è stato letto ed elaborato molto materiale inerente

l’aspetto tecnologico per lo studio di una soluzione.

Il progetto sviluppato è un’applicazione web sviluppata in Node.js che utilizza il fra-

mework Express e il template engine Handlebars. Altri packages utilizzati sono:

• axios per fare chiamate http sia dal browser verso il server web che dal server web

verso gli altri servizi che verranno descritti di seguito

• bs58 e sha2 per gestire gli aspetti crittografici dei cid di IPFS

• ipfs-mini per dialogare con il nodo ipfs installato su VPS (Virtual Private Server)

dedicato

• jquery


28 Soluzione

• qrcode per generare i QR code da applicare sulle etichette dei prodotti

3.2 Scelte

In questa sezione vengono fornite le motivazioni per cui sono state prese determinate scelte

implementative.

3.2.1 Perché la blockchain

L’impiego della blockchain è uno dei requisiti del progetto. Siccome spesso viene impiegata

la blockchain in alcuni progetti in cui non è necessario, di seguito, viene argomentato perchè

la scelta di impiegare la blockchain è corretta. In primo luogo il fatto che quasi la totalità delle

soluzioni ad oggi presenti sul mercato futilizzino questa tecnologia è sicuramente un buon

indicatore che l’impiego della blockchain sia corretto.

Di seguito viene riportata una frase di Vitalik Buterin, inventore di Ethereum, in cui

vengono esposte in maniera chiara e concisa come la blockchain sia perfettamente adatta

allo sviluppo di un’applicazione distribuita per la tracciabilità in campo food supply chain.

If you’re buying some food or medicine, for example, you have this complex

global supply chain...Ideally, you’d want to have some kind of common shared

network that you could use to get all the information about where each individual

thing came from so you could trace every part of the product back to where it

came from.You could have a smartphone app that you could check everything

about the product and see if it satisfies your needs. To do this kind of thing, you

need to have a shared network and the blockchain is a great way to do it.

Oppure gli autori di un interessantissimo articolo sull’argomento[17] scrivono:

In general, blockchain technology is useful in those use- cases where there are

more than one administrative authority and there is a trust deficit among those

parties. A typical example could be a supply chain management system, where

multiple parties collaborate together to deliver goods.


29

Figura 3.1: Diagramma decisionale per l’impiego di blockchain

If the stored value in the blockchain needs to be publicly verifiable then we should use

public blockchain, whereas if the data is only for specific parties then a private blockchain is

a better choice because consensus mechanisms can be simplified. [17]


30 Soluzione

3.2.1.1 Paragone tra blockchain e database

Le caratteristice di un database interessanti allo scopo di qeusta analisi sono:

• db dipende da chi lo amministra

• esiste un DBA che ha potere di modificare dati e funzionalità

• è permissioned quindi

• in un db privato per accedere ai dati il DBA deve fornirci le credenziali di un account

• in un db pubblico tutti possono accedere ai dati in lettura

• architettura client-server

• è centralizzato. la sicurezza è nelle mani del sistema

Un database pertanto è adatto:[18]

• contenere dati in continuo cambiamento

• Fast Online transaction processing

• informazioni confidenziali (non trasparenti al pubblico)

• dati che non richiedono verifiche

• applicazioni a se stanti

• dati relazionali

Esistono anche database distribuiti che si differenziano dai database tradizionali per-

chè non hanno un single point of failure ma il controllo del database è comunque centraliz-

zato e il sistema è permissioned. I database distribuiti sono differenti dalle blockchain anche

perchè non devono gestire il consenso. Il consenso infatti è gestito dal punto centrale di con-

trollo. Le blockchain invece gestiscono problemi tipo BGP (Byzanthine Generals Problem).

Un’altra differenza, importantissima, tra database distribuito e blockchain sta nello scopo.

Lo scopo della blockchain è fornire l’ecosistema necessario ad avere un mondo completa-

mente distribuito. Lo scopo di un db distribuito è quello di avere un db che beneficia di una

struttura distribuita. Anche a livello di tecnologie di storage le due soluzioni sono differenti

ma ai fini della trattazione, essi non vengono approfonditi.

Le caratteristiche della blockchain sono state ampiamente descritte nelle sezioni 1.4.4

e 2.1. A questo punto della trattazione rimane solo di concludere il perchè la blockchain sia

la giusta tecnologia da impiegare ai fini del progetto.

La blockchain pertanto è adatta:[18]

• gestione di transazioni finanziarie


31

• trasferimento di beni

• verifica di dati

• sviluppo di applicazioni distribuite (DApps)

• molto altro non utile ai fini della trattazione (sistemi di voto elettronico, gestione identità

digitale ecc..)

Da questa analisi ne consegue che è molto più significativo paragonare la blockchain

con un database distribuito piuttosto che con un database tradizionale. Le differenza tra una

blockchain e un database stanno nell’architettura e nello scopo. Un database è perfetto

per salvare e leggere dati.

La blockchain offre un ecosistema che grantisce trasparenza e favorisce la coope-

razione di entità che non si fidano tra loro e che non hanno la possibilità di trovare una parte

terza di cui fidarsi entrambi. Sia i database che la blockchain possono essere utilizzati in

maniera sicura ed entrambe le soluzioni soffrono di problemi di sicurezza. La bc non soffre

di problemi di sicurezza dell’infrastruttura ma solo di come vengono caricati i dati.

Come la blockchain, il database distribuito ha lo scopo di mantenere una copia dei dati

consistente su un insieme di nodi

L’impiego di un database distribuito è paragonabile all’impiego di una blockchain solo

attivando i maggiori livelli di isolazione (serializable isolation level) che comunque non è

sufficiente a garantire un livello di affidabilità e alta disponibilità paragonabile a quello di una

blockchain. [19]. Infatti nei DB distribuiti esiste la possibilità che ci siano conflitti che vanno

risolti tramite intervento manuale o automatico. Il primo causa una situazione di downtime e

si basa sulla promozione di una situazione dove è l’operatore a discernere, il secondo caso

non causa downtime e non dipende dall’intervento umano potenzialmente fraudolento ma

ha la potenzialità di creare involontariamente situazioni ancora più difficili da risolvere.

Quindi nel piccolo non è possibile avere un DB che possa competere con la BC. Gli

unici infatti che riescono a farlo sono i grandi aziende come Amazon e Google e i prodotti

hanno un costo diverso da quello di un semplice DBaaS. La blockchain quindi può essere

vista come un’evoluzione dei distributed db, o meglio, un’alternativa molto simile che offre

la possibilità di persistere dati su dei nodi di cui non ci si debba necessariamente fidare. A

questo scopo i nodi implementano un algoritmo che utilizza soluzioni crittografiche basate

sui Merkle Trees.

Gli svantaggi di impiegare una blockchain sono:

• le transazioni hanno un costo

• i tempi di risposta della blockchain, soprattuto in scrittura, sono molto lenti1

1in alcuni casi si parla di diversi secondi o addirittura minuti, a dipendenza della frequenza con la qualevengono creati i nuovi blocchi


32 Soluzione

• la struttura dati non è relazionale2

3.2.2 Perché IPFS

Esistono dei database compatibili con la blockchain tra cui CouchDB e LevelDB. Sicura-

mente l’impiego di una di queste due tecnologie è adatto al progetto. IPFS è stato scelto

perchè permette di salvare qualsiasi tipo di file compresi file JSON e immagini. I file JSON

sono stati utilizzati per salvare gli oggetti javascript creati con l’applicazione node e facil-

mente utilizzabili anche lato browser. IPFS inoltre è anche la scelta fatta da Foodchain le

cui API, come vedremo di seguito, sono state impiegate nel progetto. Viene qui riportata

una frase tratta dal sito ufficiale di IPFS[20] che espone molto chiaramente quanto IPFS e

la blockchain siano tecnologie sinergiche.

IPFS and the Blockchain are a perfect match! You can address large amounts of

data with IPFS, and place the immutable, permanent IPFS links into a blockchain

transaction. This timestamps and secures your content, without having to put

the data itself on the chain.

3.2.3 Perché Foodchain

La scelta di utilizzare la blockchain di Quadrans è stata definita fin dalla prima versione della

proposta di questo progetto. La collaborazione con Foodchain è stata fortemente voluta fin

dai primi contatti avuti con la fondazione Quadrans. La collaborazione con Foodchain è stata

inoltre molto proficua, ha permesso di focalizzarsi sulla parte di ricerca di una soluzione

e sullo sviluppo del prototipo senza dover entrare nei dettagli della programmazione su

blockchain che non era necessaria ai fini del progetto. Se Foodchain sia la scelta giusta per

un eventuale proseguimento del progetto, verrà analizzato nel capitolo 4. Le possibilità per

integrare Foodchain nel progetto sono:

• analizzare e studiare il comportamento dello smartcontract di Foodchain e interagire

direttamente con la blockchain

• sviluppare un’applicazione web tradizionale che si interfaccia con un nodo remoto

della blockchain tramite API REST

È stato scelto di utilizzare la seconda soluzione perchè le necessità di questo pro-

getto sono ampiamente soddisfatte dallo smart contract di Foodchain. Questa scelta ha

fortemente influenzato l’architettura del sistema descritta nella sezione 3.5.

2non si possono eseguire operazioni tipo il join che si può eseguire nei database più diffusi


33

3.2.4 Perché Node.js

Node.js è un ambiente runtime leggero ed efficiente che permette di scrivere applicazioni

lato server in javascript. Il vantaggio più grande di utilizzare Node.js per lo svliluppo di una

web app è la possibilità di utilizzare lo stesso linguaggio che viene utilizzato nel browser.

Da questo deriva la possibilità di riutilizzare lo stesso codice e quindi ridurre i tempi di

sviluppo. IPFS, la cui implementazione primaria è in Go, offre anche un’implementazione in

JavaScript che permette una perfetta integrazione nel browser o in applicazioni Node.js.

3.2.5 Perchè un VPS

Un VPS (Virtual Private Server) è un server virtuale la cui infrastruttura viene fornita e man-

tenuta come servizio che viene solamente configurata e sfruttata per gli scopi per cui è stata

presa a noleggio. Come è possibile osservare dallo schema dell’architettura del sistema 3.6

è stato utilizzato un server remoto noleggiato su OVH.com che ha due funzioni:

• fare da proxy tra il server web Node.js e il servizio tramite il quale si può comunicare

con il nodo della blockchain

• eseguire un nodo IPFS che si occupa di fornire lo storage necessario ad ospitare i

documenti

Per ragioni di sicurezza il servizio per comunicare con il nodo della blockchain accetta

richieste da un solo IP. Per garantire un elevato grado di flessibilità, si è pensato di permet-

tere all’applicazione web di essere eseguita su una macchina qualsiasi invece che da una

macchina con IP fisso. Per poterlo fare si è reso necessario installare su un VPS con IP

fisso il servizio di proxy.

3.3 Funzionamento

In questa sezione viene descritto come i vari attori interagiscono con il software per dare

vita al flusso della filiera. Il risultato dell’inserimento dei dati nel software è la possibilità

di generare un QR code da apporre sull’etichetta del prodotto che, quando scansionato,

apre sul dispositivo utilizzato una pagina del browser in cui viene fornita una pagina in cui

sono riportate tutte le informazioni riguardanti quello specifico prodotto. Un esempio viene

riportato di seguito suddiviso in tre screenshots i figura 3.2.


34 Soluzione

Figura 3.2: Pagina tracking su mobile

Il software sviluppato si distingue dagli altri descritti nella sezione 2.3 per la sua sem-

plice interfaccia grafica e perchè le pagine di amministrazione tramite le quali produttori,

trasformatori e rivenditori interagiscono con l’applicazione sono sufficientemente semplici

da poter essere fruite anche da dispositivo mobile. Essendo il software inteso per esse-

re impiegato da piccoli produttori, lo scopo di questa scelta è quella di rendere l’impiego

del software il più semplice e meno invasivo possibile per chi, durante la giornata lavo-

rativa, si occupa presumibilmente non solo di gestire aspetti amministrativi (tra cui rientra

l’inserimento dei dati su questo software).

Con lo stesso scopo è stato previsto uno step di configurazione in cui i dettagli riguar-

danti pascoli, produttori, traformatori e rivenditori vengono inseriti nella blockchain creando

una sorta di profilo utente i cui dati sono scritti su blockchain. Considerazioni a riguardo

sono riportate nella sezione 4.2. Le relazioni tra i pascoli e i contadini, tra i contadini e i

trasformatori e tra trasformatori e rivenditori sono scritte nel profilo dell’attore che è quindi

immutabile3 e pubblicamente accesibile.

In accordo con gli obiettivi del progetto sono state implementate le funzionalità utili a dimo-

strare come avviene il flusso del latte nella filiera del latte per la produzione di Formaggio

d’Alpe Ticinese DOP. I prodotti caseari (formaggi e yogurt) sono realmente prodotti dal ca-

seificio Agroval di Airolo. Alla fine di ogni step i dati sono scritti in maniera immutabile sulla

blockchain. Si noti che quando con la frase "i dati sono scritti in maniera immutabile sulla3di seguito, in questa sezione, viene descritto come avvengon eventuali aggiornamenti riuscendo però a

garantire sempre la massima trasparenza aggiornando i dati senza eliminare la versione precedente


35

blockchain" si intente il salvataggio di un file JSON su IPFS e la creazione di un item sulla

blockchain contenente una coppia di valori: un timestamp e un hash IPFS. Questo mecca-

nismo permette di garantire che in un determinato momento quei determinati dati siano stati

scritti su blockchain. I dati, ovviamente, non possono essere modificati perchè l’hash IPFS

non sarebbe più valido. Modifiche e aggiornamenti sono possibili postando una nuova re-

visione sull’item sulla blockchain. In altre parole all’indirizzo dell’item sulla blockchain verrà

mantenuto un array di revisioni contenenti diverse coppie timestamp/ipfs-hash che creano

uno storico dell’item le cui versioni precedenti non sono modificate nè modificabili.

Alla coppia timestamp/ipfs-hash è associato anche l’identificativo dell’attore che ha creato

l’item o postato la nuova revisione. Per quanto riguarda l’autenticazione dell’utente nel siste-

ma, utile a sapere chi ha scritto cosa, si faccia riferimento alle sezioni 3.7 e 4.2. Tornando

alla descrizione del flusso che il latte segue nella filiera, il primo step prevede la scrittura dei

dati relativi alla mungitura del latte per cui è necessario inserire la quantità di latte prodot-

ta.

Il timestamp è aggiunto alla creazione dell’item su blockchain. Il riferimento al pascolo è

aggiunto automaticamente dal sistema grazie alla fase di configurazione eseguita prece-

dentemente. Il prodotto di ogni mungitura è un lotto di latte che viene automaticamente

inserito tra i prodotti in vendita del contadino. Il contadino può eseguire l’upload di file

da associare al lotto di latte. I file vengono caricati su IPFS, viene creato un item sulla bloc-

kchain 4. Il documento IPFS realtivo al latte viene quindi aggiornato ottentendo un nuovo

IPFS hash che verrà utilizzato per creare una nuova revisione dell’item latte contenente un

array di indirizzi ai documenti associati al lotto di latte. Può essere caricato qualsiasi file che

voglia essere condiviso con gli altri attori, con il consumatore, con gli enti certificatori e con

gli enti di controllo.

Per esempio potrebbero essere caricati documenti di trasporto, certificazioni del biologico

o l’attestato che dimostra che il pascolo in cui è avvenuta la mungitura fa parte degli alpi

inclusi nella lista del Formaggio d’alpe Ticinese DOP. Ulteriori considerazioni sono riportate

nella sezione 4.2.

4in maniera che anch’esso sia tracciabile


36 Soluzione

Figura 3.3: Contadino admin page

Sulla pagina di amministrazione del casaro 5 è presente una lista di tutti i lotti di latte

disponibili per la vendita presso i contadini da cui il casaro di rifornisce 6. Il casaro può

quindi formalizzare l’acquisto di un lotto di latte e da quel momento può utilizzarlo, anche

parzialmente, per creare dei prodotti caseari. La lista di prodotti con alcune caratteristiche,

che sono descritte nella sezione 3.6, sono salvati nel file IPFS contenente i dati del casaro.

Il casaro può quindi creare dei prodotti che sono poi resi disponibili nella sezione prodotti in

vendita e acquistabili dai rivenditori. Come per il latte nella pagina del contadino, il casaro

può aggiungere dei documenti ad ogni lotto di prodotti creato.

5che corrisponde ad un profilo che precedentemente è stato descritto in maniera più generica con il terminetrasformatore

6come descritto in precedenza, anche la lista di contadini è persistita su blockchain


37

Figura 3.4: Casaro admin page

Nella pagina di amministrazione del rivenditore è possibile acquistare i prodotti dai

caseifici di cui il rivenditore è cliente e generare un QR code che, quando scansionato,

genera una richiesta al web server la cui risposta è una pagina web attraverso la quale il

consumatore può consultare la pagina di tracking del prodotto.


38 Soluzione

Figura 3.5: Rivenditore admin page

Considerato che in un sistema decentralizzato non esiste qualcuno che può correggere

dei dati immessi erroneamente dall’utente e soprattutto considerato che i dati, una volta su

blockchain, non possono essere eliminati o modificati, si è dovuta trovare una soluzione per

risolvere l’eventuale inserimento di dati errati sulla blockchain. Attraverso l’interfaccia grafica

l’utente ha la possibilità di "eliminare" il lotto di latte o i prodotti che possiede. L’eliminazione

prevede che il prodotto non sia più visibile attraverso l’interfaccia grafica. In fase di elimi-

nazione è previsto che l’utente inserisca un commento attraverso il quale rende trasparenti

le motivazioni di ciò che sta facendo prendendosene pubblicamente la responsabilità. È

importante infatti considerare che i dati rimangono scritti sulla blockchain e il file IPFS non

viene eliminato, pertanto, chi volesse effettuare delle verifiche lo può fare accedendo ai dati

attraverso un canale diverso. Considerazioni a riguardo sono riportate nelle sezioni 4.1 e

4.2.

Come si può constatare consultando la sezione 3.6 di questo documento, il software è

stato sviluppato per permettere di aggiungere alla filiera attori e prodotti in maniera molto

semplice. Alcune possibilità di ampliamento delle funzionalità del software sono descritte

nella sezione 4.2.

Uno svantaggio di utilizzare la blockchain sono i tempi di risposta agli eventi. Nella

testnet di Foodchain per esempio viene creato un blocco ogni 15 secondi. Operazioni quali

la vendita che prevedono la scrittura o l’aggiornamento su blockchain di tre item (vendi-

tore, acquirente, prodotto) richiedono tempi molto lunghi, anche superiori ai 30 secondi,

rendendo l’applicazione inutilizzabile. In accordo con quanto detto in precedenza, quindi,


39

si è dovuta trovare una soluzione che permettesse all’utente di svolgere le operazioni sul

software in maniera immediata. La soluzione proposta consiste nell’aggiornare i dati visua-

lizzati sull’interfaccia grafica del client appena l’utente esegue un’ operazione. Nel frattempo

le operazioni sul backend vengono eseguite come previsto. Ovviamente è necessario dare

un feedback all’utente in maniera che esso sia consapevole che un determinato elemento

con il quale interagisce è provvisorio e non necessariamente già consistente con la versione

su blockchain.

3.4 Vantaggi e svantaggi

In questa sezione vengono descritti vantaggi e svantaggi dell’impiego della soluzione pro-

posta. Alcuni dei punti descritti potrebbero non essere completamente soddisfatti dalle fun-

zionalità che il software offre, ma, potrebbero essere intesi come vantaggi e svantaggi che

dipendono dalle scelte fatte. In alcuni casi, pertanto, potrebbe essere necessaria l’imple-

mentazione di qualche feature aggiuntiva nel web server Node.js e nella parte di interfaccia

grafica. Ulteriori dettagli possono essere trovati nella sezione 4.2.

Svantaggi per i produttori, trasformatori e rivenditori

• risparmio di tempo che deriva, per esempio, dal soddsfare l’obbligo di tenere traccia

dei fornitori/acquirenti 7

• possibilità di conoscere i prodotti che vengono acquistati e utilizzati nei propri prodotti

• possibilità di caricare dati criptati che possono essere consultati solo da altri attori

autorizzati 8

• conoscere la strada che prendono i propri prodotti ottenendo così dati utili a migliorare

la propria produzione e far crescere il proprio business 9

• proteggere il proprio marchio da contraffazioni

• migliorare la reputazione dei propri prodotti

• garantire ai propri clienti che i prodotti derivano da una filiera sostenibile

Svantaggi per i produttori, trasformatori e rivenditori

• necessità di esporre in maniera pubblica informazioni che fin’ora non era necessario

dichiarare7vedi Oderr nella sezione 1.18vedi sezioni 4.1 e 4.29per esempio sapere che una parte dei prodotti acquistati dai rivenditori rimane invenduto potrebbe aiutare il

casaro a diminuire la produzione di un tipo di formaggio prima che il rivenditore decida di diminuire la richiesta.oppure, al contrario, sapere che un determinato prodotto viene venduto in brevissimo tempo potrebbe indicareche gli si possa attribuire un valore più elevato incrementando così i ricavi


40 Soluzione

• necessità di imparare ad utilizzare un nuovo tool

• problemi derivanti da un utilizzo improprio

Vantaggi per enti certificatori/enti di controllo

• ogni documento è firmato digitalmente quindi l’autocertificazione è dichiarata pubbli-

camente

• possibilità di sviluppare dei tool per effettuare controlli in maniera automatizzata

• avere la certezza che le informazioni fornite ai vari enti siano congruenti

• possibilità di appoggiarsi ad una soluzione già esistente per raggiungere i propri

obiettivi

Svantaggi per enti certificatori/enti di controllo Gli enti di controllo sono liberi di

beneficiare oppure no di una soluzione di questo tipo. In alcuni casi potrebbe essere neces-

saria una fase di cambiamento/ambientamento ma le potenzialità sono alte e il ritorno sul

tempo speso è garantito.

Vantaggi per i consumatori

• avere la certezza che i dati non sono stati modificati/manipolati

• avere una visione d’insieme e di facile consultazione

• ottenere informazioni oltre quelle normalmente riportate sull’etichetta del prodotto

Svantaggi per i consumatori Non ne sono stati individuati. Il caso peggiore è che il

consumatore non possa beneficiare dei vantaggi offerti.

3.5 Architettura del sistema

In figura 3.6 è riportato il diagramma dell’architettura del sistema.


41

Figura 3.6: Diagramma archietettura del sistema

Il client del contadino, trasformatore o rivenditore fruisce dell’applicazione web attra-

verso un browser. Le pagine sono servite dal web server Node.js che utilizza il template

engine handlebars per creare dinamicamente le pagine. Attraverso l’interfaccia grafica, l’u-

tente, può eseguire le operazioni descritte nella sezione 3.3. Ogni operazione eseguita sul

client manda una richiesta AJAX al web server che ha il compito di interagire con gli altri

componenti del sistema che sono un proxy che esegue il forwarding delle richieste e delle

risposte con il servizio tramite il quale si interagisce via API Rest con la blockchain, un nodo

IPFS che fa anche da gateway verso la rete IPFS. 10. Il nodo IPFS e il proxy sono installati

sullo stesso VPS rispettivamente sulle porte 5001 e 8088. Il web server Node.js è stato

deployato su heroku, un servizio cloud dedicato facilmente integrabile con CI/CD di GitLab

su cui è stato scelto di creare la repository del progetto.

3.6 Architettura dei dati

Il software è stato sviluppato con un’architettura MVC. Una prima versione del software è

stata sviluppata salvando i dati su un database MongoDB. I controller poi sono stati modi-

ficati in maniera che non interagissero più con il database ma interagissero via http con il

gateway IPFS e con il proxy verso il servizio di Foodchain.

I modelli dei dati sono: pascolo, contadino, casaro, rivenditore, latte, prodotto.

Per aggiungere un nuovo tipo di prodotto non è necessario modificare il web server ma

è sufficiente aggiornare il file IPFS del casaro che lo produce. Di seguito vengoon riportati

un esempio di file JSON salvato su IPFS e il diagramma della struttura dei dati.

10un nodo IPFS, se non configurato come gateway, permette l’interazione solo su una porta su localhost. Peressere accessibile come servizio dall’esterno è stato necessario configurare il nodo IPFS e aprire una portaverso l’esterno.


42 Soluzione

Figura 3.7: Diagramma archietettura dei dati

1 {

2 "nome" : " agrova l " ,

3 / / l i s t a d i i tem i d de i c o n t ad i n i da cu i s i r i f o r n i s c e i l casaro

4 " c o n t ad i n i " : [

5 " 0 x f 00d0000000000005328d32899dca5b2851bcb1 f 8a8 f 9bd7486a6 fb 9 fa 519951 " ,

6 " 0 x f 00d0000000000003b9513cbf03b0e9bd7a19ee84698c646783169 ef 5336b5e2 "

7 ] ,

8 / / l i s t a d i i tem i d de i r i v e n d i t o r i che i l casaro r i f o r n i s c e

9 " r i v e n d i t o r i " : [

10 " 0 x f 00d000000000000ab432 fd 3acb4a1d7b3c533ed511ea7c397e70b22de90b004 " ,

11 " 0 x f 00d000000000000 f 7ab9 f 3a42977a4ac2003c22ade60a66e985386a1d10336c "

12 ] ,

13 / / l i s t a d i i tem i d de l l a t t e p rodo t to . i l l a t t e cont iene un boolean che viene

aggiornato quando viene e l i m i n a to . i n quel caso i l l a t t e r imarra ’ per

sempre i n questo ar ray .

14 " l a t t e " : [

15 " 0 x f 00d0000000000002b3e5be3 f 619aba4256e2adf2235b7228c66b04206ae5ba9 " ,

16 " 0 x f 00d0000000000008c17 f 3610398030c32a435 df 769d13 fb 3464b34663415233 " ,

17 " 0 x f 00d00000000000071ccace9e6addcb5b18d32815215c57 f 321 f 8c62ac8a3b74 " ,

18 ] ,

19 / / l i s t a d i o g g e t t i che de f in i scono i p r o d o t t i che i l casaro produce . per fa re

i n modo che i l casaro possa i n i z i a r e a produrre p r o d o t t i d i v e r s i a t t r a v e r s o


43

i l menu dropdown , bisogna a g g i u n g e r l i qu i postando una nuova r e v i s i o n e de l

casaro s u l l a b lockcha in

20 " cosa_produce " : [

21 {

22 "nome" : " formaggio l e v e n t i n a " ,

23 "udm" : " kg " ,

24 " immagine " : " h t t ps : / /www. agrova l . ch / wp−content / uploads / 2018 / 03 /

FormaggioLevent inaAgroval . jpg " ,

25 " icona " : " icon_cheese . png "

26 } ,

27 {

28 "nome" : " yogur t na tu ra le " ,

29 "udm" : " v a s e t t i " ,

30 " immagine " : " h t t ps : / /www. agrova l . ch / wp−content / uploads / 2018 / 02 /

YogurtDiMontagnaAlNaturaleNat l . jpg " ,

31 " icona " : " i con_yogur t . png "

32 }

33 ] ,

34 / / l i s t a d i p r o d o t t i che i l casaro non ha ancora venduto . a l momento d e l l a

vend i ta questo ar ray viene aggiornato rimuovendo i l p rodo t to che pero ’

manterra ’ un r i f e r i m e n t o a l casaro i n un campo appos i to . l a t ransaz ione d i

vend i ta mod i f i ca anche i l documento de l p rodo t to cambiando l ’ owner . l ’ i d

d e l l ’ i tem prodo t to verra ’ aggiunto i n un ar ray ne l documento de l

r i v e n d i t o r e che l o ha comprato

35 " p r o d o t t i " : [

36 " 0 x f 00d0000000000009b41 f 673ce478debb946bb5c6ba9d66c3a094 f 8c5 df 779bb " ,

37 " 0 x f 00d000000000000ca985 fa 778ed12 f 3cd7d2a1a65b3208a14c739 ef 85b68518 " ,

38 " 0 x f 00d00000000000085 f 3b3354 f 92536119e96092e268694c564ea4 f b f e 8 f 500e " ,

39 " 0 x f 00d0000000000000 f 5e8 f 8474c04e528d5 fe 6 fd 2cd6ba88759a5409 f 8 f 9358c " ,

40 ]

41 }

3.7 Considerazioni sulla sicurezza

L’obiettivo del progetto è sviluppare un prototipo. Aspetti come la protezione della pagina

di amministrazione tramite login non sono stati implementati ma, siccome l’importanza di

questi aspetti è fondamentale in un applcazione di questo tipo, di seguito e nella sezione

4.2 vengono esposte diverse riflessioni a riguardo.

Esistono diverse possibilità per gestire l’autenticazione degli attori. Ognuna di esse ha

vantaggi, svantaggi e casi in cui è più adatto il suo impiego.

Nel caso in cui la fruizione dell’applicazione avvenisse sempre da pc fisso, si potrebbe

installare un nodo della blockchain sulla stessa macchina e fare in modo che l’applicativo

scriva sul nodo locale demandando poi alla blockchain il compito di mantenere l’integrità del

registro condiviso. La coppia di chiavi crittografiche (pubblica + privata) sono salvate in un


44 Soluzione

wallet locale. L’utente ha la responsabilità di proteggerle ed è necessario che qualcuno si

occupi dell’installazione e configurazione del nodo. Questo tipo di soluzione è quella prefe-

rita da chi, come Foodchain, può raggiungere lo scopo di creare una rete solo incentivando

ogni partecipante ad ospitare un nodo della blockchain. Lo svantaggio di questa soluzio-

ne, come detto, è che qualcuno si deve occupare di configuare un nodo della blockchain

per ogni attore 11. Un altro svantaggio è che il nodo non può essere installato su disposi-

tivo mobile. Bisognerebbe quindi installare un light-node che si occupi solo di scambiare

informazioni con una copia del registro remota. Ulteriori informazioni sono riportate nella

sezione 4.1.

Un’altra soluzione è quella di ospitare tutti i wallet in un server che faccia da interfac-

cia tra un sistema di autenticazione tradizionale utente/password e le chiavi crittografiche

associate. Gli svantaggi di questa soluzione sono la perdita della decentralizzazione e la

necessità di mantenere un sistema completamente autonomo. Il database, come l’applica-

zione web, necessiterebbe infatti di qualcuno che lo mantenga aggiornato e che si prenda la

responsabilità della sicurezza dei dati contenuti. Il vantaggio è che l’utente potrebbe fruire

dell’applicazione da un qualsiasi dispositivo senza avere la necessità di mantenere un nodo

e senza avere neanche la necessità di conoscere dettagli sul funzionamento del sistema e

della blockchain.

Entrambe le soluzioni descritte in precedenza prevedono che ad ogni attore della filiera

sia associato un wallet. I dati immessi nella blockchain sarebbero quindi firmati digitalmen-

te e la blockchain offre nativamente meccanismi per conoscere chi ha scritto o modificato

qualcosa e in quale momento. Inoltre la blockchain offre anche supporto per il trasferimento

della proprietà degli item. Questi meccanismi sono disponibili solo sulla main net di Food-

chain ma non sulla test net. Foodchain ha infatti messo a disposizione un nodo della test net

ospitato dalla loro infrastruttura. A questo nodo è associato un unico wallet, pertanto, per

mantenere traccia dell’owner attuale di un item e degli owner precedenti, è stato necessario

aggiungere al modello dei dati un campo owner e dei campi per tenere traccia, per esempio,

di chi ha munto un lotto di latte e di chi lo ha comperato. Utilizzando una blockchain sarebbe

più corretto demandare alla stessa l’archiviazione di questo tipo di informazioni. Il tracking

offerto al consumatore è comunque completo e scritto su blockchain. Nella sezione 4.2

sono riportati delle riflessioni su come il trasferimento su main net dovrebbe avvenire. È im-

portante considerare che su test net non è necessario avere una forte responsabilizzazione

degli attori. Il requisito per ottenere un nodo su testnet di Foodchain è quello di presentare

il proprio progetto diventando così un partner tecnologico a cui viene dato accesso ad un

nodo sulla testnet. Fornendo un solo wallet Foodchain ha la garanzia che non possano

essere create DApp che funzionino su testnet e che possano essere messe in produzione.

11impensabile nel contesto di piccoli produttori ticinesi che passano la stagione all’alpe dove spesso nonesiste accesso alla linea telefonica


45

Capitolo 4

Conclusioni

4.1 Considerazioni

Nel documento della FAO intitolato Food Traceability Guidance[5] a cui ci si è riferiti in pre-

cedenza, viene chiarito che le inefficienze della supply chain nell’industria del food è dovuta

principalmente ad una lacuna di impegno dei governi nel fornire un’adeguata regolamenta-

zione e soprattutto al fatto che, ad oggi, non esiste uno standard globale senza il quale non

è possibile garantire. È possibile che un giorno esista uno standard globale che permetta di

semplificare e definire con chiarezza cosa ci si aspetta dai sistemi di tracciabilità. Ciò che

reputo difficile è la possibilità di adottare un sistema unico perchè le filiere sono tante e le

realtà dei partecipanti è molto eterogenea. È in questo contesto che la soluzione proposta

può soddisfare ed essere esempio per altre soluzioni volte a soddisfare una nicchia che

non può sopportare i costi e la complessità dei sistemi descritti nella sezione 2.3. Soluzioni

sviluppate per soddisfare le necessità di clienti come Walmart, Auchan, Barilla non sono si-

curamente adatte a soddisfare una filiera come quella del Formaggio d’Alpe Ticinese DOP

il cui giro d’affari totale è di qualche ordine di grandezza inferiore a quello generato da un

solo attore delle filiere a cui gli altri software sono rivolte.

Tutte le filiere, anche quelle più piccole, che in rari casi possono espandersi oltre in

confini elvetici, possono e dovrebbero beneficiare delle potenzialità delle tecnologie più mo-

derne. Inoltre l’affinità tra i valori di genuinità e autenticità che alimentano gli alpigiani ticinesi

e i principi di trasparenza su cui si basa l’adozione di un sistema di tracciabilità di questo tipo

è ancora più coerente che tra i principi della blockchain e i principi dei colossi della GDO1.

In precedenza è stato ampiamente argomentato il perchè la blockchain sia la tecnolo-

gia giusta da adottare come elemento fondamentale per un progetto di questo tipo. Sono

anche stati forniti numerosi spunti per eseguire una riflessione riguardo il tipo di blockchain

da utilizzare. Le informazioni di contesto fornite non sono sufficienti a fornire un suggeri-

mento se preferire una blockchain pubblica o una privata. Bisognerebbe approfondire le

1Grande Distribuzione Organizzata


46 Conclusioni

necessità del committente e le necessità della filiera per poter rispondere in maniera sicura

a questo quesito. Sicuramente bisogna considerare che, come tutte le soluzioni commer-

ciali descritte in precedenza, nonostante il livello storage e DLT sia completamente costruito

attorno a tecnologie distribuite, esiste, e dovrà sempre esistere, un punto centrale che è re-

sponsabile di fornire il servizio che permette di interagire in maniera semplice e veloce con

queste tecnologie. Il punto centrale a cui ci si riferisce è costituito dal livello architetturale in

cui si pone il progetto sviluppato, ovvero, il web server e tutta l’infrastruttura che rende pos-

sibile la fruizione dell’applicazione web. Se, impiegando una blockchain pubblica, nessuno

si dovrà occupare di gestire e mantenere l’infrastruttura DLT, sarà sempre necessario offrire

agli operatori della filiera del supporto per quanto riguarda l’inserimento della propria realtà

aziendale nella rete. Per poter individuare la giusta tipologia di blockchain da impiegare è

anche necessario proseguire con un’analisi più approfondita chiedendosi se sia necessario

circoscrivere i partecipanti e favorire a livello applicativo dei canali per lo scambio di dati

e documenti in maniera privata. Un concetto che, per chi scrive, non è risultato chiaro fin

dall’inizio è che se la blockchain rappresenta un ecosistema che una volta messo in moto

rimarrà vivo fino a quando ci saranno dei partecipanti, le applicazioni costruite sopra alla

blockchain non hanno questa caratteristica e necessitano di essere mantenuto come le al-

tre applicazioni. Le applicazioni costruite sulla blockchain non hanno le caratteristiche della

blockchain. L’applicazione web che fa uso di blockchain non è pubblica, distribuita e tru-

stless. Chi sviluppa una soluzione di questo tipo deve, pertanto, definire chiaramente quali

siano le responsabilità che si vogliono avere e quali si preferisce delegare. Analizzando le

necessità della filiera, lo scopo di chi propone la soluzione e se chi propone la soluzione

voglia impegnarsi a mantenere non solo lo strato applicativo ma anche quello strutturale

sottostante, si può decidere se utilizzare una blockcahin pubblica o una privat tenendo in

cosiderazione che sia in caso di blockchain pubblica che privata è possibile implementare

lo scambio di documenti in maniera privata grazie alla possibilità di cifrarli. Un esempio

dell’utilità di avere questa possibilità si palesa, a mio avviso, ogni qualvolta l’attore che in-

serisce delle informazioni potrebbe trarre vantaggio dal fornire versioni diverse della stessa

informazione in base al contesto. Per esempio si potrebbe voler caricare una fattura d’ac-

quisto per dimostrare ad un ente controllore che vengono rispettati determinati requisiti a

livello fiscale e allo stesso tempo si potrebbe però voler nascondere l’impiego del prodotto

acquistato. Grazie alle proprietà della blockchain, sarebbe possibilile ridurre o elimminare

questo tipo di azioni. Allo stesso tempo si potrebbe voler evitare che il cliente possa vedere

le fatture messe a disposizione. Se la fattura viene caricata sulla blockchain cifrata ma cor-

redata da un commento in chiaro che tutti possono leggere, ci sarà sicuramente qualcuno

che è autorizzato a decifrare il fila che può garantire anche a chi non ne ha il privilegio, che

le informazioni inserite aiutino ad aumentare il valore del prodotto.

Una considerazione che va fatta riguardo l’utilizzo di IPFS è legata alla disponibilità dei

dati nel tempo. Prima di tutto bisogna considerare la differenza tra le funzionalità add e pin


47

di un file. Eseguire l’adding di un file significa rendere disponibile un file sulla rete IPFS

attraverso il suo hash grazie al fatto che quando un file viene aggiunto viene effettuato au-

tomaticamente anche il pinning che consiste nell’azione di mantenerne una copia sul prorio

file system così che gli altri nodi possano accederne il contenuto tramite una richiesta. Da

qui deriva sicuramente per il committente la necessità di mantenere un nodo IPFS sempre

attivo per garantire la persistenza dei dati. In questo caso però esisterebbe un singolo punto

che garantisce che i dati rimangano diponibili. La situazione sarebbe analoga ad utilizzare

un database. I dati su IPFS vengono replicati automaticamente in base a quanto spesso

essi vengono letti. Se un file non viene letto per molto tempo potrebbe essere cancellato

anche dall’ultimo nodo e perso per sempre. Esistono dei servizi di pinning che servono a

garantire che almeno una copia del file rimanga sempre disponibile. Sarebbe comunque

utile prevedere di mantenere più nodi IPFS attivi anche perchè quando si utilizzano tecno-

logie che hanno lo scopo di creare una rete che si supporti da se, è corretto abbracciarne

la filosofia e non limitarsi ad usare le risorse ma anche partecipare in maniera collaborativa

mettendo a disposizione delle risorse proprie. Il vantaggio di utilizzare IPFS invece che un

database distribuito proprio è che il meccanismo di replicazione è sviluppato e mantenu-

to dalla community e che molti più nodi di quelli che noi possiamo mettere a disposizione

possono aiutarci a mantenere i dati sempre disponibili. IPFS comunque è un filesystem

pertanto non offre tutte le funzionalità che un database potrebbe offrire. La consultazione

dei dati infatti è abbastanza macchinosa e il loro aggiornamento anche. Sostituire IPFS

vorrebbe dire sostituire Foodchain.

Credo che un punto di forza di questo progetto sia il fatto che l’adozione di una solu-

zione di questo tipo venga proposta dall’ente incaricato di effettuare controlli e garantire la

sicurezza alimentare in tutto il Canton Ticino. Credo che questo aspetto sia un vantaggio

enorme e che debba essere sfruttato per portare beneficio ai produttori e ai consumatori di

prodotti regionali tra cui il Formaggio d’Alpe Ticinese DOP. Il fatto che il progetto sia propo-

sto e sostenuto dal Dipartimento della Sanità e della Socialità attraverso la Divisione della

Salute Pubblica e il Laboratorio Cantonale può solo aumentare la fiducia che il consumatore

può riporre in un’iniziativa di questo tipo.

Una caratteristica della blockchain che può essere sfruttata è la facile integrazione di

sensori IoT che caricano automaticamente dati nel registro immutabile. In molte filiere è di

fondamentale importanza, per esempio, mantenere la catena del freddo. Per dare un’idea

delle potenzialità della blockchain è sufficiente pensare che dati relativi alla temperatura

possano essere automaticamente rilevati, inseriti nella blockchain, analizzati e resi pubblici.

Essendo il Laboratorio Cantonale promotore di questo progetto e anche l’ente incarica-

to ad eseguire i controlli, credo che avrebbe valore valutare la continuazione dello sviluppo

di un sistema che permetta di semplificare e automatizzare i controlli che vengono esegui-

ti. I benefici si rifletterebbero positivamente sia sull’attività del Laboratorio sia sulla routine

degli attori della filiera. I benefici della semplificazione di queste attività si ripercuotono po-


48 Conclusioni

sitivamente sui cittadini. Per eseguire un controllo, con la soluzione proposta, è sufficiente

conoscere l’indirizzo dell’item del contadino sulla blockchain, con questa informazione si

può accedere tramite l’explorer della blockchain e trovare tutti gli hash IPFS delle varie ver-

sioni del documento associato al contadino. Con queste informazioni in mano si può risalire

a tutte le mungiture che il contadino ha inserito sulla blockchain, comprese quelle elimina-

te, e fare un controlli di qualsiasi tipo. Un’interfaccia dedicata dovrebbe essere sviluppata

per poter permette agli operatori di accedere in maniera semplice ed efficace ai dati di cui

necessitano. Attraverso interfacce apposite si possono rilasciare certificazioni, effettuare

richiami sui prodotti, permettere a chi ne è autorizzato di aggiungere informazioni e com-

menti riguardo un prodotto. Il risultato dell’impiego della blockchain infatti è la possibilità di

operare in un ecosistema che permette e favorisce la cooperazione e la fiducia.

Un aspetto interessante di impiegare la blockchain è che, essendo i dati pubblici, chiun-

que, compresa la concorrenza, può effettuare analisi e controlli sull’operato di un’azienda.

Questo aspetto porta sicuramente le aziende che aderiscono ad una rete come quella pro-

posta, ad agire con maggiore etica. Il risultato per il consumatore è la consapevolezza

che, oltre a i dati mostrati attraverso interfaccia grafica, c’è qualcuno che controlla più nel

dettaglio che le informazioni fornitegli siano corrette e veritiere.

4.2 Sviluppi futuri

In questa sezione si vogliono suggerire possibilità per l’ampliamento delle funzionalità del

software e si vogliono fornire spunti utili ad intraprendere un percorso che porti alla trasfor-

mazione di questo prototipo in un’applicazione che possa essere sfruttata nel mondo reale

permettendo alle realtà del nostro territorio di beneficiare di tutti gli aspetti positivi di cui si è

parlato in precedenza.

Dopo aver scelto il tipo di servizio che si vuole offrire bisogna definire il processo di

aggiunta e configurazione degli attori. Attualmente questo processo avviene creando un

file IPFS per il nuovo attore. Il file deve rispettare una determinata struttura e contenere

determinati campi. L’IPFS hash deve poi essere aggiunto al file IPFS root e una nuova

revisione dello stesso va inserita in blockchain. Sia nel caso in cui si decidesse di rendere

autonomo l’attore che si vuole iscrivere, sia nel caso in cui si voglia fornire del supporto

nel processo di inclusione nella rete, è sicuramente necessario prevedere la possibilità di

farlo tramite un’interfaccia grafica che automatizzi il processo ed eviti a chiunque di dover

interagire con la blockchain e IPFS.

Il flusso che il latte segue attraverso i passaggi definiti nel software è sicuramente una

rappresentazione abbastanza fedele al percorso che il latte segue nella filiera reale. I pas-

saggi sono molto semplificati e il tracciamento non può sicuramente limitarsi alla provenien-

za del latte. Il livello di granularità deve essere definito dal committente ma affinchè il con-


49

sumatore possa avere una buona conoscenza del prodotto analizzato, bisogna sicuramente

includere anche informazioni sugli altri ingrendienti principali.

Come detto in precedenza il trasferimento su mainnet di Foodchain comporterebbe un

lavoro di rifattorizzazione dei modelli dei dati e comporterebbe un miglioramento dal punto

di vista dell’autenticazione degli attori attribuendogli la responsabilità di quanto fatto. La

sostituzione di Foodchain con una blockchain diversa avrebbe senso, a mio avviso, solo nel

caso in cui non si trovasse una soluzione contrattuale adatta al contesto della filiera del For-

maggio d’Alpe Ticinese DOP e adatto al contesto cantonale in cui il progetto è stato ideato.

La sostituzione di Foodchain comporterebbe la necessità di riscrivere uno smart contract ed

eventualmente configurare una blockchain che poi dovrà anche essere mantenuta. Sosti-

tuire Foodchain permetterebbe di sostituire IPFS con una delle tante soluzioni di database

decentralizzato che snellirebbe il processo di implementazione di nuove filiere. Il team di

Foodchain e di Quadrans ha fornito un ottimo contributo ai fini della realizzazione del pro-

getto e il lavoro svolto è indubbiamente di uno standard qualitativo elevatissimo. Credo che

una collaborazione futura con Foodchain possa portare solo benefici e garantire un partner

affidabile e competente che ha maturato esperienza nell’utilizzo di una tecnologia sostenuta

dalla fondazione ticinese Quadrans.


50 Conclusioni


51

Bibliografia

[1] Sito ufficiale laboratorio cantonale.

[2] Sito ufficiale divisione della salute pubblica.

[3] Sito ufficiale dipartimento della sanità e della socialità.

[4] Definizione fao.

[5] Food traceability guidance.

[6] Food traceability trends to watch in 2019.

[7] Ordinanza sulle derrate alimentari e gli oggetti d’uso (oderr).

[8] Hyperledger — chapter 1: Blockchain foundation.

[9] Sito ufficiale marchi igp e dop.

[10] Sito ufficiale marchi igp e dop.

[11] Sito ufficiale stea.

[12] White paper di bitcoin.

[13] Sito ufficiale hyperledger.

[14] Sito ufficiale sig.

[15] Sito ufficiale te-food.

[16] Sito ufficiale ibm food trust.

[17] Mohammad Jabed Morshed Chowdhury, Alan Colman, Muhammad Ashad Kabir, Jun

Han, and Paul Sarda. Blockchain versus database: A critical analysis.

[18] Databases and blockchains the difference is in their purpose and design.

[19] Why blockchains dont suck and the perils of distributed databases.

[20] Sito ufficiale ipfs.


Gestione ﬁliera alimentare tramite blockchain · 2020. 2. 20. · nella catena di produzione di...

Documents

Transcript of Gestione ﬁliera alimentare tramite blockchain · 2020. 2. 20. · nella catena di produzione di...