• Non ci sono risultati.

3.2 Scelte

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.

2

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

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.

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 immutabile3e 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 sulla

3

di 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

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 allamungitura 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 iprodotti 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- kchain4. 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.

4

Figura 3.3: Contadino admin page

Sulla pagina di amministrazione del casaro5 è 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ò quindiformalizzare l’acquisto di un lotto di latte e da quel momento può utilizzarlo, anche

parzialmente, percreare 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.

5

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

6

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

Figura 3.4: Casaro admin page

Nella pagina di amministrazione del rivenditore è possibileacquistare 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.

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,

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/acquirenti7

• 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 autorizzati8

• conoscere la strada che prendono i propri prodotti ottenendo così dati utili a migliorare la propria produzione e far crescere il proprio business9

• 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 dichiarare

7vedi Oderr nella sezione 1.1 8

vedi sezioni 4.1 e 4.2

9

per 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 indicare che gli si possa attribuire un valore più elevato incrementando così i ricavi

• 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.

Documenti correlati