La blockchain per il settore agroalimentare e nelle filiere produttive

dallo storytelling al fact-checking della tracciabilità
fino ai nuovi modelli economici

Studio teorico e tecnico su come l’applicazione ragionata e motivata delle tecnologie blockchain potrebbe efficientare la filiera produttiva e cambiare il rapporto tra produttore e consumatore

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

Executive summary

Frutto di oltre due anni di ricerca ed elaborazione, il presente lavoro, svolte alcune premesse di inquadramento generale dell’impatto del foodtech in Italia, si propone innanzi tutto di demistificare molte idee errate che circolano tutt’oggi sulle presunte proprietà della blockchain per poi illustrare le reali opportunità che questa tecnologia offre in una filiera produttiva e il modo in cui debba essere correttamente implementata perché risulti davvero utile, per il produttore e per il consumatore.

Sono quindi declinati i concetti di blockchain opportunities – fornendo al lettore una lista di ciò che realmente offre una soluzione DLT – e di incompletezza di un progetto blockchain in filiera indicando quali sono le caratteristiche minime e imprescindibili (Minimum Viable Ecosystem) per cui sia utile ed efficace l’impiego di questa tecnologia.

Sono quindi illustrati i livelli di governance di processo per lo sviluppo e mantenimento di un progetto di tracciabilità in blockchain incentrando l’analisi sul ruolo e la responsabilità di ciascun attore della filiera, con particolare attenzione alla naturale esigenza di continuo adattamento ed evoluzione del contesto e delle relazioni tra partecipanti al network dei nodi.

Viene infine descritta la struttura di una soluzione blockchain soffermando l’attenzione del lettore su alcune soluzioni architetturali e tecnologiche enunciando i concetti di controllo di coerenza, per la validazione dei dati in ingresso con opportuni smart contract e di framework di sistema per il successivo scrutinio dei dati in operazioni di verifica e attribuzione di livelli di attendibilità. Condizioni, queste, imprescindibili affinché la gestione collaborativa dei dati in blockchain persegua un concreto obiettivo di affidabilità e trasparenza delle informazioni.

Presentazione dell’Associazione Blockchain Italia

L’Associazione Blockchain Italia (ABI) nasce nel 2018 per iniziativa di un ristretto gruppo di professionisti e accademici di diversa estrazione ed esperienza legati tutti dalla comune curiosità verso la tecnologia blockchain e desiderosi di portare le loro discussioni all’interno di un contenitore – l’Associazione appunto – più strutturato.

L’obiettivo è stato fin dalla sua costituzione quello di allargare la partecipazione degli associati privilegiando una composizione eterogenea mantenendo, quindi, un approccio inclusivo e multidisciplinare. Ciò non solo in considerazione del fatto che la DLT si propone di rivoluzionare innumerevoli settori (e forse addirittura il ruolo stesso dell’individuo nella società), ma anche per il necessario rispetto di un fondamentale principio di libero confronto di idee ed esperienze, fondamentale per fare della buona ricerca scientifica.

Il Tavolo Supply Chain

Nel perseguimento del suo scopo statutario, ABI opera attraverso la costituzione di tavoli tematici dedicati ciascuno ad uno specifico campo di indagine scientifica. I tavoli, a loro volta, sono articolati in gruppi di lavoro nei quali gli Associati approfondiscono in modo pragmatico l’applicazione della tecnologia blockchain in un particolare ambito industriale alla luce delle esigenze del settore, della sua prassi e normativa speciale.

Il presente lavoro è il risultato di oltre due anni di operatività del Tavolo Supply Chain dedicato alla tracciabilità di prodotto lungo la filiera produttiva. Tante ore di vivace confronto, studio e critica di use case e analisi di progetti in corso, proposte ed elaborazione di nuove idee.

Il metodo di lavoro e la genuina passione dei partecipanti hanno consentito di affrontare il tema della tracciabilità in blockchain da innumerevoli prospettive e di raggiungere l’obiettivo di recepire il prezioso contributo di ciascuno integrandolo con gli altri in una sintesi coerente ed efficace.

Si ringraziano (in ordine alfabetico):

• gli estensori del presente lavoro, Paolo Giolito, Fabio Lecca, Francesco Rampone, Massimo Romano e Cesare Saccani; nonché
• i partecipanti al Gruppo di Lavoro (oltre agli estensori), Marcella Atzori, Roberto Candusio, Enza Cirone, Filippo Costalli, Stefano Gatti, Filippo La Scala, Massimo Montecchi, Michele Soavi, Mikaela Valan, Ivan Vitali; e infine
• tutti gli Associati che hanno riletto il testo finale fornendo utili suggerimenti prima della stampa finale.

Sommario

Executive summary. 1

Presentazione dell’Associazione Blockchain Italia. 2

Il Tavolo Supply Chain. 2

Prefazione. 1

1. Contesto del settore agroalimentare. 3

1.1       Situazione attuale. 3

1.2       Asserzioni etiche. 4

1.3       La competizione tra filiere responsabili. 5

1.4       Ruolo della tecnologia blockchain per l’attendibilità delle asserzioni. 6

2. L’innovazione delle tecnologie a registri distribuiti 8

2.1       Un po’ di debunking. 8

2.2       La blockchain in due parole. 9

2.3       Cosa non fa la blockchain. 9

2.4       Quando la blockchain non è necessaria. 11

2.5       Le Blockchain Opportunities (BCO). 14

3. Modelli di governance in blockchain. 18

3.1       I soggetti della BC. 18

3.2       Corporate governance. 19

3.3       Data governance. 20

3.4       Platform governance. 21

3.5       Fase di set-up. 22

3.6       Fasi di sviluppo e competenze dei tre livelli di governance. 22

4. La blockchain al di là del fintech. 24

4.1       La blockchain in filiera produttiva (primi cenni). 24

4.2       La governance alla luce della tipologia di dati. 26

4.3       Una storia scritta in blockchain. 27

5. Trasparenza e coerenza delle informazioni 29

5.1       Minimum Viable Ecosystem. 29

5.1.1        Numerosità degli stakeholder di tipo C. 29

5.1.2        Numerosità degli stakeholder di tipo W. 30

5.1.3        Controlli di coerenza delle informazioni. 31

5.2       Completezza e incompletezza dei sistemi BC. 31

5.3       Costruire un sistema BC in una filiera produttiva. 32

5.4       Applicazione delle BCO e KPI. 32

5.5       Progetti B2B e B2C: trasparenza ad ogni livello. 33

6. Framework informativo verificabile. 34
7. Digital twining. 36

7.1       I termini del problema. 36

7.2       Invertire i termini della relazione. 37

7.3       Documenti e bolle in chiave NFT. 38

8. Le potenzialità fintech in una filiera. 40

8.1       Autofinanziamento. 40

8.2       Sistemi di compensazione disintermediati 40

8.3       Penali e incentivi 41

8.4       I vantaggi fintech. 41

9. Dallo storytelling al fact-checking, innovazioni di processo e di sistema. 42

Prefazione

Innumerevoli sono i progetti di filiera agroalimentare annunciati e sviluppati su piattaforme blockchain[1] di cui, dopo un primo efficace lancio promozionale, non si sente più parlare. Forse non hanno mantenuto le promesse fatte o forse, quando pure l’hanno fatto, non hanno tuttavia contribuito in modo apprezzabile a rafforzare la fiducia del consumatore sulla qualità e provenienza dei prodotti.

Le soluzioni blockchain nel settore agrifood sono rimaste infatti per lo più ancorate al racconto del produttore e quindi adagiate sul tradizionale piano evocativo della pubblicità e del marchio d’impresa. Non hanno quindi significativamente inciso sul rapporto tra impresa e consumatore.

Pare quindi legittimo porsi qualche domanda sulla reale idoneità di questa tecnologia ad essere utilmente applicata in settori non prettamente fintech[2].

La ragione di ciò va per lo più ricercata nella errata intesa capacità della blockchain di risolvere problemi che non hanno natura matematica. La sfida è, insomma, quella di riuscire a adattare l’originaria capacità della blockchain di riconciliare partite contabili senza il ricorso ad un terzo fiduciario affinché sia in grado di “validare” informazioni di carattere non matematico pertinenti ad un prodotto (provenienza, processi industriali, soggetti coinvolti, ingredienti, elementi di assiemaggio, ecc.). Ciò comporta un salto logico e un adattamento della tecnologia affinché risolva problemi di carattere qualitativo e non meramente quantitativo.

1.    Contesto del settore agroalimentare

1.1      Situazione attuale

L’estesa applicazione di tecnologie informatiche ICT[3] avvenuta negli ultimi anni sui principali settori industriali ha coinvolto, con velocità diverse, anche il settore agroalimentare e le filiere produttive nel loro complesso, rendendo così di uso comune termini quali Smart Agrifood e Agricoltura 4.0^[4].

Le implementazioni degli ultimi 50 anni che hanno profondamente trasformato non solo i macchinari impiegati ma anche tecniche di semina, allevamento e monitoraggio delle colture, hanno indubbiamente avuto un focus iniziale orientato a favore dell’incremento della produttività, spinto da fattori contingenti quali la crescita della popolazione mondiale e la conseguente crescente domanda di alimenti. La stessa Agenda ONU 2030 per lo Sviluppo Sostenibile[5], inserendo nel 2015 tra le tematiche affrontate l’obiettivo di «porre fine alla fame, raggiungere la sicurezza alimentare, migliorare la nutrizione e promuovere un’agricoltura sostenibile» ha sottolineato la necessità di raddoppiare entro il 2030 la produttività agricola: incremento ostacolato da importanti fattori esogeni (cambiamenti geoclimatici, pandemia, conflitti internazionali con impatto su prezzi materie prime ed energia) e di per sé irraggiungibile senza una radicale revisione delle tecniche più tradizionali.

In questo contesto l’Italia, come evidenziato dall’analisi dell’Osservatorio Smart Agrifood del Politecnico di Milano[6] presenta la peculiarità di avere un importante tasso di crescita di adozione di soluzioni Agricoltura 4.0 (pari al 31% in più rispetto all’anno precedente) ma su una superficie complessiva interessata pari ad appena l’8% (rispetto al 6% dell’anno precedente). Gli investimenti sostenuti infatti presentano ancora una forte concentrazione su aziende che proseguono un percorso di innovazione già iniziato (early adopter), agendo sulla stessa superficie coltivata.

Alla sopra citata tendenza all’incremento di produttività) si è affiancata la maggiore e nel tempo crescente attenzione alla qualità del prodotto, alla sostenibilità dei processi e alla generazione di informazioni utili richieste dal consumatore finale, con una importante implicazione per tutti i soggetti coinvolti (produttori, trasformatori, distributori, rivenditori[7]): offrire all’utente con semplicità e trasparenza una visione completa delle informazioni necessarie all’acquisto consapevole.

Si arriva quindi, anche nel settore agroalimentare, ad un importante cambio di mindset per l’azienda, che si trova a dover seguire uno sviluppo responsabile, sostenibile e inclusivo, con focus sulla gestione degli sprechi ed eccedenze, coniugando allo stesso tempo il perseguimento del profitto ad una maggiore attenzione alla tutela di beni e valori di interesse collettivo.

Cresce di conseguenza in ogni parte del mondo la domanda per informazioni sempre più accurate, affidabili e credibili sugli aspetti e rischi di natura non finanziaria che per semplicità identificheremo utilizzando l’acronimo ESG (Environmental, Social, Governance)

• Environmental: inquinamento, consumo di risorse, emissioni di CO2, cambiamento climatico e tutela dell’ambiente naturale.
• Social: diritti umani, condizioni di lavoro (incluse forme di discriminazione e parità di genere) e impatti sulle comunità locali.
• Governance: corrette pratiche di business (es.: anticorruzione), rapporti con i consumatori (es.: tutela della privacy, trasparenza informativa, sicurezza dei prodotti, ecc.).

La singola impresa è obbligata pertanto a indirizzare le proprie politiche ed investimenti verso una strategia che riesca a coniugare la preparazione e divulgazione di questo tipo di informazioni assieme alla spinta combinata esercitata dall’evoluzione normativa e dalle esigenze di diversi stakeholder.

1.2      Asserzioni etiche.

La rapida evoluzione della domanda di informazioni su aspetti e rischi ESG è stata affrontata inizialmente dalle imprese in modo superficiale agendo principalmente sulle leve del marketing e della comunicazione. Questo atteggiamento ha favorito la proliferazione di asserzioni, marchi, certificazioni e rating sugli aspetti e rischi ESG rilasciate in base a criteri poco trasparenti e con metodologie di dubbia accuratezza e affidabilità, ma soprattutto senza conformità a riferimenti normativi chiari e senza adeguati sistemi di controllo sulle informazioni divulgate in grado di assicurare la necessaria credibilità alle parti interessate.

Nello sviluppo di questo lavoro vedremo che un’applicazione blockchain consente alla singola organizzazione di raccogliere e inserire nel sistema informazioni verificate che mantengono la distinzione tra le caratteristiche descrittive e prestazionali di sostenibilità di un prodotto (con particolare attenzione alle prestazioni) con quelle relative alla conformità a requisiti di sistema di gestione (es.: sistema di gestione ambientale conforme alla norma ISO 14001) e, soprattutto, le caratteristiche prestazionali (es.: livello di esposizione ai rischi) di un’intera organizzazione rispetto a tutti gli aspetti ESG per poterle mettere a disposizione di tutti gli attori e sviluppare strategie di tipo collaborativo per il miglioramento delle singole variabili a livello di intero sistema del valore.

Per ottenere questo risultato è necessario che ogni operatore di filiera (dalla materia prima fino allo scaffale) raccolga informazioni di sostenibilità relative alle caratteristiche del prodotto e dei processi impiegati (es.: un rating ESG o una relazione sulla sostenibilità) e predisponga delle dichiarazioni verificabili con riferimento a norme e regole internazionali da una terza parte indipendente.

Lo IAF (International Accreditation Forum)[8] ha definito 10 principi fondamentali che, ove applicati, assicurano la divulgazione alle parti interessate di informazioni accurate, affidabili, comparabili e credibili sulla sostenibilità di un’organizzazione. Secondo tale organismo una relazione di sostenibilità, predisposta da un’organizzazione rispetto a standards di rendicontazione di sostenibilità riconosciuti a livello internazionale, e un rating ESG sono due asserzioni e, come tali, sono oggetto di una valutazione di conformità secondo i requisiti della norma ISO/IEC 17029 “Principi e requisiti generali per gli organismi di validazione e verifica”. La valutazione della conformità deve essere effettuata mediante un audit robusto, comprensivo di attività svolte in remoto e attività presso la sede dell’organizzazione (per raccogliere evidenze oggettive e verificare le informazioni dichiarate dall’azienda), condotto da professionisti in possesso di competenze adeguate e verificate. Quest’attività deve essere condotta da organismi di terza parte indipendente accreditati rispetto alla norma ISO 17029 e a un programma come, per esempio, Get It Fair[9].

Un quadro di regole chiare e trasparenti condivise e applicate da tutti gli attori costituisce la premessa indispensabile per la governance di una filiera e consente di fornire al cliente finale un’informazione “cumulata” su tutti gli aspetti di sostenibilità del prodotto e di ogni attore lungo la filiera riportata su un’etichetta etica conforme alla norma ISO/TS 17033 “Asserzioni etiche e informativa di supporto”.

1.3      La competizione tra filiere responsabili.

Sotto la spinta dell’evoluzione del quadro normativo e delle crescenti esigenze di diversi stakeholder, la domanda di informazioni sugli aspetti e rischi ESG non è più limitata al perimetro della singola organizzazione, ma si estende a interi sistemi del valore comprendenti la filiera di fornitura a monte (upstream) e la filiera distributiva a valle (downstream) e riguarda l’intero ciclo di vita di un prodotto (dalla materia prima ai semilavorati, dalla produzione di parti alla realizzazione del prodotto finito, dalla distribuzione del prodotto fino al suo smaltimento dopo l’uso).

Da tempo si è compreso che le organizzazioni non sono solo esposte a rischi di eventi che possono accadere al proprio interno, ma anche e soprattutto da rischi di eventi che si verificano lungo la catena del valore a cui appartengono e possono procurare impatti avversi sulla stessa organizzazione e sui suoi stakeholder, tra cui certamente investitori, fornitori di credito, clienti e consumatori.

Cresce pertanto l’esigenza da parte dei diversi stakeholder di prendere le proprie decisioni non solo in base alle tradizionali variabili di qualità, prezzo e servizi accessori, ma anche e soprattutto sulla base delle caratteristiche di sostenibilità del prodotto e sulla responsabilità degli attori che agiscono lungo l’intero suo ciclo vita: dalla materia prima (es.: la coltivazione di pomodori) al semilavorato di base (es.: la passata base), alla trasformazione e confezionamento fino alla fase post-uso. Tale esigenza, pertanto, può essere soddisfatta solo mettendo a disposizione delle parti interessate informazioni di tipo cumulativo affinché siano in grado di assumere decisioni consapevoli in funzione delle performance di sostenibilità dei prodotti e delle organizzazioni che li hanno realizzati.

In tale contesto, il consumatore potrebbe privilegiare quei prodotti che, al momento dell’acquisto, mettono a disposizione informazioni accurate e affidabili sulle caratteristiche di sostenibilità del prodotto (es.: carbon footprint complessivo del prodotto calcolato in ogni stadio del suo ciclo di produzione) e sul livello di esposizione a rischi sociali e ambientali complessivi di tutti gli attori della filiera (es.: livello di esposizione ai rischi di sicurezza sul lavoro)[10].

1.4      Ruolo della tecnologia blockchain per l’attendibilità delle asserzioni.

Come accennato, le asserzioni etiche di filiera devono essere verificate da una terza parte indipendente la quale, non solo abbia le competenze e l’accreditamento formale di volta in volta necessario (es.: rispetto alla norma ISO 17029), ma possegga anche una struttura e un’organizzazione adeguate al compito che si propone. Eseguire audit “on site”, può essere attività estremamente complessa e costosa che comunque limita la raccolta dei dati al momento in cui è svolto. Peraltro, l’effetto deterrente dei controlli si esaurisce sempre nel momento in cui sono compiuti.

È proprio in questo ambito che la tecnologia BC può fornire un contributo fondamentale garantendo l’attendibilità e completezza dei dati forniti dall’impresa nell’ambito di asserzioni verificabili, favorendo peraltro la loro disponibilità all’auditor con ricorso limitato, o comunque assai più mirato ed utile – all’attività ispettiva.

Nel prosieguo del presente lavoro è descritto il modo in cui le informazioni di filiera possono effettivamente considerarsi “accurate e affidabili” grazie all’impiego della tecnologia BC e, soprattutto, in forza dell’utilizzo di protocolli di validazione implementati da tale tecnologia eseguiti in modo trasparente e necessitato.

Si tratta di una architettura complessa, ma distribuita, nel senso che la complessità non è gestita (e non è responsabilità) di un unico soggetto, ma è “spalmata” per quote su ciascun segmento della filiera. Una architettura, peraltro, “aperta”, e cioè nella quale possono – e devono – assumere un ruolo anche organismi certificatori, associazioni di categoria, associazioni dei consumatori, e financo attori indipendenti che vogliano partecipare, anche in piccola misura, nella definizione e nel sindacato dei protocolli di validazione.

La blockchain diventa in questo modo uno strumento fondamentale per supportare un gioco competitivo aperto tra sistemi del valore basato su asserzioni affidabili. Essa può essere impiegata, per esempio, per monitorare la logistica (trasporto e immagazzinaggio), garantire la catena del freddo o certificare la provenienza dei prodotti (per contrastare la piaga del c.d. Italian sounding), ma anche per dimostrare il rispetto di processi produttivi e disciplinari di filiera che costituiscono spesso fattore centrale di attribuzione di qualità ed eticità del prodotto finale[11].

2.           L’innovazione delle tecnologie a registri distribuiti

2.1      Un po’ di debunking

L’entusiasmo (hype) che ha accompagnato il racconto intorno alla blockchain ha ostacolato in una certa misura l’analisi scientifica e contaminato molti contributi tecnici e divulgativi[12]. L’accettazione acritica di alcuni falsi miti ha fatto sì che molte aziende abbiano investito in progetti blockchain-based privi di solide basi concettuali, destinati quindi ad un mero effetto marketing, ma senza apprezzabili risultati in termini di efficienza di processi[13], riduzione di costi, legalità delle condotte, accesso al credito e affidabilità dei prodotti e servizi offerti[14].

È bene quindi chiarire – premesso un breve cenno su cos’è la blockchain – cosa essa non fa e quando è inutile, poiché nulla aggiunge ad un comune gestionale informatico centralizzato. Procedere in questo modo aiuta senz’altro il lettore a focalizzare l’attenzione nei paragrafi successivi sulle autentiche caratteristiche di una soluzione blockchain e sulle reali opportunità che essa offre in una filiera produttiva (le cc.dd. blockchain opportunities – v. infra § 2.5).

2.2      La blockchain in due parole

In estrema sintesi, la tecnologia blockchain consente di decentralizzare operazioni contabili aventi ad oggetto – almeno nei protocolli criptovalutari – rapporti di debito-credito tra più soggetti. Prima del 2008[15] nessuno era riuscito a progettare un sistema informatico che consentisse di tenere un’unica contabilità in formato digitale tra più operatori senza che uno di loro dovesse necessariamente assumere il ruolo di tenutario del registro. Non era in altri termini possibile gestire una contabilità condivisa senza che qualcuno assumesse il ruolo di fiduciario, che garantisse cioè la corretta e regolare appostazione delle partite di dare e avere nel registro.

Ebbene, la BC, dichiaratamente in ambito monetario, introduce per la prima volta la possibilità di regolare i rapporti tra operatori non dovendo necessariamente avvalersi di un intermediario, garante della corretta esecuzione degli ordini di pagamento. È proprio questa capacità della blockchain di superare la tradizionale adozione di gerarchie informative che la rende lo strumento ideale per conferire attendibilità ai dati in essa caricati ed elaborati senza ricorso ad una autorità terza.

Per tale ragione la BC si definisce trustless, priva di fiducia, nel senso che prescinde dalla necessità di riporre fiducia in un soggetto particolare che assume il ruolo di tenutario del registro.

2.3      Cosa non fa la blockchain

Due sono i miti più comuni che vengono ripetuti quando si vuole sottolineare l’utilità di una soluzione blockchain. Si tratta di idee infondate che inducono a credere che l’adozione di una soluzione DLT consista essenzialmente nel caricare in essa dati e documenti.

2.4      Quando la blockchain non è necessaria.

Oltre ai falsi miti appena visti al paragrafo precedente, l’applicazione pratica della BC è spesso viziata nel racconto mainstream dall’attribuzione a questa tecnologia di presunti vantaggi e prerogative che invero appartengono a un qualsiasi sistema informatico ben costruito e rispetto al quale, quindi, la BC nulla aggiunge[21]. Nello schema seguente sono riportati alcuni esempi.

2.5      Le Blockchain Opportunities (BCO).

Nei paragrafi precedenti abbiamo visto quali sono le caratteristiche che la BC non ha (§ 2.3) nonché quelle che possiede e che tuttavia non sono suo esclusivo appannaggio (§ 2.4) e che quindi potrebbero essere senz’altro implementate anche con una piattaforma informatica “tradizionale”.

Nello schema seguente sono quindi esposte le vere utilità che la blockchain offre – le cc.dd. blockchain opportunities (BCO) – che sarebbero precluse dall’adozione di tecnologie o soluzioni informatiche diverse[29]. Vediamo quali sono.

Grazie alle proprietà sopra indicate, le informazioni che “precipitano” in blockchain possono costituire un set invariabile di dati (che definiamo token) che possono essere aggiornati o modificati solo secondo un protocollo condiviso in blockchain stessa. In senso ampio, chiamiamo questo protocollo smart contract. Ove tali dati siano associati a prodotti di filiera, si riferiscano cioè ad oggetti attuali o potenziali del mondo reale (ad esempio una bottiglia di EVO o un carico di pomodori), possiamo per analogia considerarli una loro “rappresentazione digitale”, informativa e descrittiva, affidabile perché condivisa, non duplicabile e non falsificabile (cioè non modificabile dopo il suo ingresso in BC)[38]. Il grado di affidabilità dipende però dalla effettiva implementazione delle BCO.

Vediamo nel prossimo paragrafo più in dettaglio le proprietà appena descritte della blockchain per una loro conveniente applicazione nella filiera agroalimentare.

3.           Modelli di governance in blockchain

Nel capitolo precedente si è visto, da un punto di vista finalistico e funzionale, a quali condizioni può essere utile adottare una soluzione BC. La verifica della sussistenza di tali condizioni è tuttavia solo il primo passo da compiere prima di procedere all’implementazione del progetto.

Si è infatti detto che per sfruttare la proprietà trustless della BC non è sufficiente riversare dati in un network DLT (come purtroppo si riscontra in molti progetti di filiera BC, anche piuttosto reclamizzati). Occorre infatti costruire una complessa architettura di sistema, specifica per ciascun progetto, con individuazione di ruoli e responsabilità degli attori, realizzare un modello di governance societaria e di gestione delle informazioni tenendo in considerazione gli aspetti di natura organizzativa, legale e tecnologica, nonché implementare opportuni protocolli di validazione dei dati attraverso smart contract.

Si tratta di un’attività fondamentale – anche se spesso trascurata – rispetto a quella di sviluppo informatico del progetto. Quest’ultimo, infatti, non può prescindere da una chiara e definita mappatura degli stakeholder e del loro contributo in ciascuna fase esecutiva.

Nel presente paragrafo esporremo quindi la governance di processo[39] per la realizzazione di un progetto BC che si articola su tre piani sovrapposti che riguardano, rispettivamente: l’insieme dei rapporti giuridici tra i proprietari dell’infrastruttura tecnologica (corporate governance); la gestione dei dati (data governance) e l’operatività della piattaforma (platform governance).

A tali fini, occorre innanzi tutto definire chi sono i soggetti che partecipano in una piattaforma DLT, qual è il loro apporto e a che titolo intervengono, per poi descrivere i livelli di organizzazione a cui devono conformarsi per mantenere l’unità di scopo e gestire il progetto in modo organico e funzionale.

3.1      I soggetti della BC.

Tutti coloro, persone fisiche o giuridiche, che sono direttamente interessati da una soluzione BC, in qualità di contributori o fruitori di dati, competenze o capitali, sono definiti stakeholder.

Nell’ambito di un progetto BC di filiera, è opportuno dividere gli stakeholder in tre macrocategorie:

Ciascuno stakeholder può naturalmente assumere più di un ruolo contemporaneamente, e solitamente è proprio così.

Ad esempio, un consumatore avrà solo un ruolo di tipo read, peraltro limitato alle informazioni alle caratteristiche del prodotto (es.: qualitative, prestazionali, di contenuto) o dell’organizzazione che l’ha realizzato (es.: origine, caratteristiche etiche o di sostenibilità) o comunque non riservate; il coltivatore sarà invece tipicamente uno stakeholder di tipo read e write (R-W), anche in questo caso entro opportuni limiti; un organismo di valutazione della conformità potrebbe assumere un ruolo di tipo read and write (R-W), una associazione di consumatori potrebbe assumere un ruolo read e commit (R-C); il produttore, infine, al vertice della filiera e titolare del marchio d’impresa con cui il prodotto è commercializzato, assumerà con ogni probabilità tutti i ruoli read, write e commit (R-W-C), con credenziali e prerogative di alto livello.

Vediamo ora come gli stakeholder intervengono nella governance della BC.

3.2      Corporate governance

In un progetto BC permissioned, la corporate governance è l’insieme delle regole (e in senso estensivo, dei soggetti) che definiscono i rapporti, l’assetto giuridico e il ruolo assunto dagli stakeholder che hanno funzione write e commit, compresi i rispettivi vincoli contrattuali per il governo dell’infrastruttura hardware, software e informativa (database)[40].

La corporate governance si pone al livello più alto rispetto alla data governance e alla platform governance, ovvero laddove devono essere prese le decisioni che informano tutta la struttura del progetto BC e il suo stesso divenire. In un progetto di filiera, ad esempio, la corporate governance attiene alla costituzione e amministrazione del veicolo societario che deve promuovere e sviluppare il progetto (tipicamente un consorzio), all’individuazione dei suoi organi decisionali ed esecutivi, loro funzione, composizione e durata, all’onboarding degli stakeholder di tipo commit[41], l’individuazione degli stakeholder tipo read, ecc..

3.3      Data governance

Nell’ambito dell’attività di sviluppo e manutenzione di un progetto BC di filiera, la data governance assume un significato che va al di là della prospettiva meramente informatica e va intesa come il protocollo di selezione, raccolta, verifica, validazione e conservazione dei dati di filiera[42].

Pertanto, laddove la corporate governance – tra le altre cose – attiene alla scelta, composizione e funzionamento del particolare organo tecnico-operativo che deve provvedere al design degli smart contract (un “comitato scientifico” in grado di individuare le relazioni tra i vari dati e fissare i relativi parametri di tolleranza), la data governance è sostanzialmente l’insieme di tali smart contract.

La data governance, peraltro, assume una funzione integrativa dell’accordo di filiera che impegna ciascun stakeholder di tipo write a rispettare modalità, tempo e formato di raccolta dei dati.

Infatti, la data governance provvede alla mappatura dei dati e degli indicatori che devono essere trattati in BC, nonché all’individuazione della loro fonte e degli owner (cioè dei soggetti write che assumono la responsabilità del modo e tempo del loro caricamento, v. infra §§ 4.1 e 4.2), ai controlli a cui devono essere sottoposti, alle soglie di tolleranza di validazione e verifica e ad ogni altro elemento reputato necessario o utile per la verifica di coerenza della storia scritta in BC.

Lo sviluppo del sistema di data governance avviene ovviamente in conformità a normative e buone prassi di settore.

L’ISO (International Organization for Standardization) ha pubblicato una norma di fondamentale importanza (la già più volte citata ISO/IEC 17029) che ha il merito di ridurre la confusione, contrastare il greenwashing ed offrire punti di riferimento importanti per sistemi blockchain di ogni settore (incluso naturalmente quello alimentare) che vogliono acquisire informazioni accurate, affidabili e credibili sugli aspetti di sostenibilità di prodotto e di organizzazione (v. precedente § 1.3) da mettere a disposizione delle parti interessate.

Per esempio, nel settore food, le regole di validazione devono essere definite secondo i meccanismi per i ritiri e richiami alimentari. In particolare, secondo il Regolamento (CE) n. 178/2002, gli operatori del settore devono adottare un sistema di rintracciabilità che permetta di individuare la provenienza e il percorso degli alimenti lungo tutta la filiera produttiva al fine di garantire la sicurezza alimentare e la tutela della salute dei consumatori.

3.4      Platform governance

La platform governance è l’insieme delle regole che definiscono la struttura e il funzionamento della piattaforma BC.

La platform governance è quindi innanzitutto il livello che definisce l’architettura della BC, il protocollo (o i protocolli) di consenso e i requisiti tecnici che devono possedere gli stakeholder di tipo commit e write per divenire rispettivamente nodi e contributori del network. È poi il livello in cui la data governance è implementata in BC per eseguire la verifica di coerenza (e veridicità) della storia scritta in BC[43].

In conclusione, possiamo affermare che la platform governance è il livello di governance in cui le decisioni assunte in sede di corporate governance e data governance sono tradotte in linguaggio informatico e vengono eseguite attraverso specifici smart contract[44].

3.5      Fase di set-up

A monte dei tre livelli di governance visti nei paragrafi precedenti si colloca un quarto livello, propedeutico a quelli e caratterizzato da informalità procedurali e dall’esistenza di relazioni pregresse tra i partecipanti.

È il livello in cui i soggetti promotori individuano il veicolo societario o associativo che si occuperà di realizzare e mantenere il progetto BC, e in cui si occupano di pianificare le attività e tracciare il percorso da compiere per arrivare alla formale costituzione di tale veicolo e all’adozione del quadro regolamentare (contrattuale) iniziale per consentirne l’operatività immediata.

3.6      Fasi di sviluppo e competenze dei tre livelli di governance.

In fase di set-up iniziano a formarsi i livelli di corporate governance e platform governance.

Quanto al primo, infatti, i partecipanti al futuro veicolo promotore del progetto devono individuare innanzi tutto i requisiti soggettivi degli stakeholder di tipo commit e write, come ad esempio essere operatori della filiera, oppure essere un particolare organismo certificatore, essere costituiti in forma di società di capitali, avere un capitale sociale minimo (fondo consortile), ecc.

Successivamente, interviene una prima versione della platform governance (in tale fase costituita da un partner tecnologico terzo o dalle divisioni IT dei costitutori) che provvede a individuare e predisporre i protocolli di onboarding degli stakeholder (registrazione, delibera di accettazione, rilascio credenziali, ecc.) e a definire i requisiti tecnici che tali soggetti devono possedere per poter effettivamente eseguire il loro compito commit e write. Tali requisiti, infatti, già in fase di primo avvio del veicolo, devono essere indicati in un apposito contratto tra veicolo e stakeholder (contratto di servizi) affinché quest’ultimi assumano l’obbligo di dotarsi di determinate risorse informatiche e di rispettare determinati livelli di servizio al fine di garantire la funzionalità e la manutenzione del network[45].

La data governance inizia a formarsi una volta che sono state individuate le categorie degli stakeholder in BC e definiti gli obiettivi di filiera che il progetto dovrà conseguire. Essa sviluppa le proprie regole in stretta relazione con la platform governance per tenere sempre in considerazione le modalità e i canali di ingresso dei dati in BC.

4.           La blockchain al di là del fintech.

Si è già accennato al fatto che molti progetti di filiera in blockchain si limitano al mero caricamento di dati nei blocchi senza indagare il merito della loro validazione e la loro architettura di governance. Siffatti progetti riducono l’applicazione della blockchain alla sola proprietà della immodificabilità dei dati che, tuttavia, non è affatto appannaggio esclusivo della blockchain (v. § 2.4). Nel migliore dei casi, tali progetti sfruttano la proprietà della resilienza e storicizzazione (v. § 2.5) che sono sì tipiche della blockchain, ma altamente riduttive delle sue potenzialità effettive, e comunque replicabili anche in altri sistemi non DLT.

Solo applicando tutte (o quasi) le BCO ha senso impiegare tale tecnologia per la gestione di una filiera produttiva. Solo in tal caso si può scrivere in blockchain una storia attendibile di cosa accade in una filiera produttiva, nonché verificare il rispetto di disciplinari e protocolli regolamentari, e così rendere la soluzione BC davvero utile:

• al produttore, a fini controllo esecuzione degli obblighi contrattuali;
• al consorzio di qualità, a fini di verifica del disciplinare di filiera;
• al consumatore, a fini di verifica di qualità e provenienza dei prodotti;
• all’organismo di valutazione della conformità, al fine di compiere operazioni di audit;
• all’autorità, al fine di certificazione e accertamento del rispetto della normativa.

4.1      La blockchain in filiera produttiva (primi cenni).

La blockchain originariamente nasce per risolvere un problema di carattere meramente contabile. Bitcoin consente la circolazione in ambiente digitale di rapporti valutari di debito-credito facendo a meno di terzo fiduciario (tipicamente le banche centrali e commerciali). Per tale ragione, qualora si voglia impiegare la blockchain nella gestione e monitoraggio di una filiera produttiva, occorre applicare (e adattare) le BCO in un contesto di gestione dati di natura non meramente contabile, ma aventi per lo più carattere informativo-qualitativo.

A tale riguardo, prima di andare oltre, occorre chiarire una differenza sostanziale tra una blockchain fintech e una blockchain di gestione di dati di filiera.

La prima consente l’ingresso solo a dati soggetti a validazione di tipo contabile, regolati cioè con smart contract che garantiscono la corretta appostazione di partite di dare e avere in modo che il bilancio di transazione, al netto del resto e commissioni, sia sempre zero. Nella blockchain di filiera, invece, devono trovare ingresso anche dati non soggetti a preventiva validazione (es.: i dati metereologici provenienti da un dispositivo IoT, i dati delle analisi chimiche di un fornitore, l’esito di verifiche compiute da una autorità) oppure soggetti ad una validazione di tipo non contabile (ad es.: l’impiego di determinati prodotti fitosanitari deve essere indicato nel Quaderno di Campagna, rilevato e confermato in successive analisi di laboratorio, il livello di esposizione ai rischi ESG oppure la certificazione di un rapporto di sostenibilità deve essere effettuata da un organismo di verifica/validazione di asserzione etica accreditato rispetto alla norma ISO 17029).

In figura sono illustrate le tre tipologie di dati:

1. A) dati non soggetti a validazione e che entrano direttamente in blockchain (es.: dati di oracoli, ovvero i dati forniti da soggetti che sono considerati attendibili per convenzione dei partecipanti);
2. B) dati soggetti a validazione, ma che non superano i controlli degli smart contract (es.: transazione contabile errata il cui bilancio non sia zero);
3. C) dati soggetti a validazione che superano l’orizzonte degli smart contract e “precipitano” nella blockchain.

La categorizzazione dei dati appena esposta introduce il tema di come una blockchain possa essere efficacemente utilizzata in una filiera produttiva nella quale, per l’appunto, devono essere impiegati smart contract anche per validazioni di tipo non contabile e nella quale hanno ingresso anche dati la cui validazione deve assumere un significato più esteso.

Infatti, se in una BC di tipo contabile i dati proposti in ingresso possono assumere solo due valori di attendibilità (sì/no, 1 o 0), in una BC di filiera i dati in ingresso possono assumere un grado di attendibilità per un numero indefinito di valori. Non solo, in tali progetti è perfino utile accettare un dato con grado di attendibilità minimo (pari a zero) poiché, trattandosi di protocolli in continua evoluzione, solo un successivo audit potrebbe accertare se l’attribuzione di inattendibilità è inerente al dato in sé, oppure riguarda i dati utilizzati come parametri di funzione, o ancora se l’inattendibilità è dovuta ad un errato design dello smart contract che implementa la funzione.

In un progetto di filiera, pertanto, il concetto di “validazione” deve intendersi in modo più elastico, non solo come preventiva verifica della correttezza del dato[46], per cui questo, quando non corretto (ovvero non coerente con quelli già presenti in BC), è rifiutato all’ingresso in BC. Ma deve intendersi anche come preventiva qualifica del dato, ovvero come operazione che attribuisce ad esso un indice di attendibilità. Sicché il dato entra in BC in ogni caso, ma viene qualificato più o meno attendibile con livello di affidabilità “limitato”, “ragionevole” o “assoluto” in funzione della modalità di raccolta ed elaborazione, della sua coerenza con altri dati già presenti in BC, del livello di affidabilità dei sistemi di controllo interno e di appositi parametri di tolleranza decisi in sede di data governance.

4.2      La governance alla luce della tipologia di dati.

Per individuare le data entry appartenenti alle categorie A, B e C occorre naturalmente eseguire una dettagliata mappatura degli stakeholder e delle attività, ruoli e responsabilità di ciascuno, nonché stabilire gli obiettivi delle validazioni (attività tutte appannaggio della corporate governance). Solo allora, il compito passa alla progettazione degli opportuni controlli di coerenza, ovvero alla individuazione di come dovrebbero essere trattati i dati raccolti in BC per rilevare la loro congruenza (attività, questa, tipica della data governance). Infine, tali controlli devono essere tradotti in appositi smart contract di validazione ed esecuzione (attività riservata alla platform governance).

È bene soffermare l’attenzione in modo particolare sulla data governance. Essa costituisce un livello decisionale di capitale importanza, non solo per mantenere il progetto di filiera sempre rivolto alle BCO e rispettoso dell’eventuale disciplinare di filiera, ma anche per risolvere problemi di cooperazione tra gli stakeholder e impiego ottimale delle risorse. Essa, infatti, oltre alla progettazione degli smart contract utili a garantire che i dati in ingresso in BC siano quanto più possibili soggetti a processi di validazione e verifica di coerenza e coincidenza delle informazioni, provvede anche alla definizione di modelli concettuali uniformando l’ontologia e la sintassi dei dati, per poi procedere alla automatizzazione dei processi e alla standardizzazione e formazione dei documenti.

La data governance, insomma, opera su due fronti: (i) progettazione dei criteri di validazione e verifica dei dati e (ii) individuazione dei processi eseguibili in BC.

4.3      Una storia scritta in blockchain.

Le proprietà caratteristiche della blockchain consentono di scrivere in modo indelebile una storia quanto più possibile attendibile poiché scritta a più mani da autori uguali, autonomi e indipendenti[47], laddove il contributo di ciascuno deve mantenere coerenza narrativa con quello di tutti gli altri. Proprio la concorrenza di fonti informative – convergente, tuttavia, in una unica “storia” priva di incongruenze o contraddizioni – costituisce la migliore garanzia di veridicità e autenticità dei dati caricati in blockchain.

Per raggiungere tale risultato è necessario che il design generale del progetto – non limitato quindi ai soli aspetti informatici, ma esteso alla considerazione di elementi architetturali e di governance della piattaforma – tenda quanto più possibile ad un obiettivo di computazione distribuita, e faccia pertanto applicazione delle BCO elencate al § 2.5.

5.           Trasparenza e coerenza delle informazioni

Abbiamo visto che la blockchain consente di scrivere una “storia” della filiera attendibile, non modificabile, trasparente (su ruoli e obblighi degli stakeholder) e accessibile a chiunque a patto che siano correttamente implementate quanto più possibile le BCO.

Vediamo ora quali sono le BCO minime che devono essere implementate per giustificare l’adozione di un progetto BC di filiera.

5.1      Minimum Viable Ecosystem.

Il concetto di Minimum Viable Ecosystem (MVE) è utile per mettere a fuoco i requisiti fondamentali che una soluzione informatica deve possedere così da non disperdere l’attenzione degli sviluppatori soprattutto nelle fasi iniziali di design del progetto.

In ambito BC tale concetto va esteso. È fondamentale, infatti, ricordare che l’implementazione di un sistema BC non ha carattere eminentemente informatico: la BC non è un modo nuovo di fare ciò che si faceva anche prima della sua invenzione, ma è una tecnologia che abilita nuove condotte prima non possibili in ambiente digitale. In altri termini, realizzare un progetto BC vuol dire innanzi tutto decidere di organizzare le informazioni e la loro gestione informatica in modo diverso, coinvolgendo altri attori, concorrenti perfino, mettendo quindi a fattor comune alcune risorse e riposizionando la competizione ad un livello più elevato con effetti benefici su tutto il segmento di mercato in cui il progetto opera.

In tale prospettiva, il MVE non deve solo riguardare l’architettura della piattaforma informatica su cui poggia il progetto BC, ma deve tenere in considerazione anche la rete delle relazioni e il valore dei contributi dei singoli partecipanti al network.

Vediamo nei tre paragrafi seguenti gli altrettanti elementi dell’MVE in un progetto BC.

5.1.1     Numerosità degli stakeholder di tipo C.

Il protocollo Bitcoin fonda la propria attendibilità (correttezza delle annotazioni nei registri) sull’architettura peer-to-peer che lo caratterizza, ovvero sulla struttura orizzontale in cui la partecipazione paritetica dei nodi è la chiave di volta che consente di fare a meno del c.d. middleman, ovvero di un soggetto fiduciario a cui rimettere il corretto appostamento delle informazioni contabili relative alle disposizioni di pagamento.

Tale architettura è fondamentale in qualsiasi progetto BC, e quindi anche in un progetto di filiera produttiva. Si tratta della prima BCO, ownerless (v. § 2.5). Senza di essa non v’è ragione di ricorrere ad una soluzione BC. Non ha cioè senso adottare una soluzione BC senza sottrarre il potere decisionale (validazione delle transazioni, conservazione e storicizzazione dei registri) ad un soggetto fiduciario distribuendolo in modo “democratico”, o comunque ad una moltitudine di partecipanti uguali, autonomi e indipendenti.

Possiamo quindi dire che il primo elemento che il MVE in un progetto BC deve senz’altro possedere è di tipo architetturale: numerosità (ed eguaglianza) degli stakeholder di tipo commit.

5.1.2     Numerosità degli stakeholder di tipo W.

Tuttavia, perché la BC sia utile in un progetto di natura non esclusivamente contabile – come una filiera produttiva – occorre anche implementare una governance del dato che contempli una moltitudine di stakeholder di tipo write.  In tali progetti, infatti, implementare un protocollo che prevede l’esistenza di un solo stakeholder di tipo write è altrettanto irrazionale quanto realizzare una piattaforma BC costituita da un solo nodo[48]. La forza della BC risiede proprio nella possibilità di creare un rapporto paritetico tra i partecipanti basato sull’assenza di gerarchie economiche, legali e informative per cui è possibile creare un protocollo di controllo reciproco tra operatori.

Il secondo requisito del MVE di un progetto BC non meramente contabile va quindi ravvisato nella numerosità degli stakeholder di tipo write[49]. Non si tratta di una specifica BCO, ma di una precondizione necessaria per eseguire gli smart contract di validazione: solo se i dati soggetti a validazione provengono da fonti autonome e indipendenti ha senso operare un controllo incrociato dei dati, tale che gli stakeholder di tipo write contribuiscono, in modo non coordinato ma armonico, a creare una catena di validazioni in cui ogni entry è coerente con quella precedente e successiva[50].

5.1.3     Controlli di coerenza delle informazioni.

Il terzo e ultimo requisito del MVE– ma non meno importante – che un sistema BC deve possedere per giustificare la sua adozione consiste nell’implementazione di protocolli informatici (smart contract) di verifica della coerenza delle informazioni in ingresso in BC.

La BC nasce come soluzione per eliminare il carattere fiduciario che rivestono tutti i sistemi di gestione centralizzata. Essa, più in generale, consente di regolare i rapporti finanziari, giuridici o informativi tra i partecipanti senza il necessario ricorso ad un terzo fiduciario (middleman). Adottare pertanto una soluzione BC conservando tale carattere fiduciario, non ha alcun senso[51].

Limitare quindi il MVE alla sola numerosità degli stakeholder di tipo commit e write non è sufficiente. Occorre che i dati in ingresso in BC siano soggetti a protocolli informatici, trasparenti e necessitati (open execution)[52], che fungano da “filtro” impedendo l’ingresso ai dati non corretti (perché, ad esempio, non rispettano un vincolo di bilancio contabile) ovvero attribuendo loro in automatico un label di attendibilità che indica il grado di coerenza rispetto a popolazione di dati presenti in BC.

Possiamo quindi aggiungere un terzo requisito del MVE relativo alla data governance: implementazione di controlli di coerenza dei dati in ingresso in BC a mezzo di opportuni smart contract.

5.2      Completezza e incompletezza dei sistemi BC.

Alla luce di quanto esposto nei precedenti paragrafi, nell’ambito di un progetto di filiera, definiamo un sistema BC completo, come un sistema in cui sussiste un MVE costituito da:

• numerosità degli stakeholder di tipo commit (eguali, autonomi e indipendenti);
• numerosità degli stakeholder di tipo write (autonomi e indipendenti);
• esistenza di smart contract che effettuano controlli di coerenza delle informazioni caricate in BC.

Di converso, un sistema si definisce incompleto allorché difetti di almeno uno degli elementi su indicati.

Naturalmente, un sistema BC può assumere diversi livelli di completezza in funzione del numero di stakeholder o della ragionevole progettazione degli smart contract. Nei paragrafi successivi vedremo quindi alcuni esempi di come massimizzare la completezza di un sistema BC di tipo non contabile.

5.3      Costruire un sistema BC in una filiera produttiva.

Un sistema BC completo costituisce l’architettura minima da adottare per realizzare un progetto di filiera che consegua davvero l’obiettivo di “certificare” i dati in BC (rectius: validare e verificare la conformità e coerenza dei dati rispetto a specifiche definite in sede di data governance) senza fare ricorso ad un soggetto fiduciario che assuma un ruolo di certificatore.

Come accennato nel paragrafo precedente, tuttavia, un sistema BC completo può avere più livelli di completezza a seconda delle BCO che implementa e della misura e modo in cui le implementa.

A tale riguardo, in Appendice 1, è riportata una tabella esplicativa che elenca per ciascuna BCO una o più possibilità di implementazione in un sistema BC.

5.4      Applicazione delle BCO e KPI.

Si possono immaginare innumerevoli modi di applicare le BCO, diversi e tipici per ciascun caso specifico. Pertanto, una analisi dettagliata e approfondita del funzionamento di ciascuna filiera produttiva, dei suoi disciplinari, del quadro normativo e regolamentare in cui opera e delle prassi sviluppate negli anni, è attività imprescindibile per il design degli smart contract e dei protocolli di validazione dei dati a dimostrazione della bontà e coerenza della storia scritta sul registro.

In via generale, tuttavia, possono essere tracciate delle linee guida per orientare il compilatore nell’implementazione di soluzioni applicative che posso riguardare un qualsiasi progetto BC. In Appendice 2, sono proposte a tali fini delle KPI che attribuiscono il livello di completezza della BC, come ad esempio il numero di nodi e il tipo di relazioni tra essi, numero di attori coinvolti per singolo data entry, volume e valore delle transazioni del network, ecc.

Il punteggio finale attribuito al progetto non solo riconosce ad esso un valore assoluto di completezza, ma consente anche una comparazione con altri progetti. Inoltre, l’apprezzamento dei KPI fin dalla fase di design, consente di orientare lo sviluppo del progetto nella direzione di massima completezza.

5.5      Progetti B2B e B2C: trasparenza ad ogni livello.

L’applicazione delle BCO può essere modulata in modo assai diverso a seconda che l’obiettivo dichiarato sia quello di controllare l’attività degli operatori lungo la filiera ed efficientare i processi nell’interesse del produttore, ovvero quello di tracciare i prodotti e verificare i metodi di trasformazione nell’interesse del consumatore.

I due obiettivi non sono sempre sovrapponibili e anzi, rispondendo ad esigenze diverse, sono talvolta addirittura in contrapposizione.

Pertanto, la trasparenza che si propone di introdurre un qualsiasi progetto BC non può prescindere dalla pubblicazione di un documento, tipicamente nella forma di un whitepaper, in cui siano dichiarati gli obiettivi e le soluzioni progettuali e tecniche implementate per conseguirli[53].

Non solo, il livello di completezza di un sistema BC dipende come visto in larga misura dalla corretta e ragionevole progettazione degli smart contract che regolano l’ingresso dei dati in BC. Tuttavia, pur nel rispetto della BCO open execution, può essere assai difficile, se non impossibile, per un soggetto estraneo al network verificare la bontà ed efficacia degli smart contract implementati. Per tale ragione è raccomandabile l’adozione e pubblicazione di un framework informativo verificabile (v. successivo § 6), ovvero di un documento caricato in BC (e pertanto indelebile e storicizzato) che consente a qualunque osservatore la comprensione delle logiche sottese al funzionamento di ciascuno smart contract così da poter verificare la loro corretta compilazione ed efficacia ai fini dello scrutinio dei dati in operazioni di verifica e attribuzione di livelli di attendibilità.

6.           Framework informativo verificabile.

In un progetto BC la validazione può essere eseguita da smart contract in modalità open execution.

Ciò consente a chiunque, dotato di sufficienti competenze tecniche, di accertare come l’algoritmo degli smart contract esegue la validazione dei dati in ingresso in BC.

Senza tuttavia una dichiarazione a priori circa come lo smart contact dovrebbe eseguire la validazione e verifica non è possibile sindacare se esso faccia esattamente quel si proponeva il compilatore, né se gli input dell’algoritmo sono tempestivi, sono del tipo previsto e provengono dal punto di ingresso corretto.

In altri termini, gli stakeholder di tipo read per poter verificare che la validazione dei dati sia avvenuta correttamente, o secondo una logica condivisibile (e condivisa in sede di data governance), devono essere messi in condizione di comprendere le ragioni sottese alla scelta delle regole e funzioni implementate negli smart contract. Come visto, infatti (§ 4.1), in un progetto di filiera le validazioni dei dati non servono ad impedire l’ingresso in BC di quelli non corretti o ad escludere a posteriori quelli non verificati, ma servono ad attribuire loro un determinato grado di attendibilità e per attivare, al superamento di certe soglie, sempre decise in sede di data governance, opportuni controlli di terza parte (audit on site).

Per garantire trasparenza e fiducia a favore degli stakeholder di tipo read, non basta quindi mostrare loro cosa succede in BC, ma occorre anche dichiarare ciò che dovrebbe succedere; ovvero dichiarare, in modo indelebile (in BC per l’appunto) quali sono le scelte compiute in sede di corporate governance e data governance in ordine all’architettura del network, alle regole del disciplinare che si intende rispettare, agli obiettivi del progetto, e quindi all’utilità dei criteri e dei parametri adottati nelle operazioni di validazione degli smart contract per conseguire tali obiettivi.

Pertanto, per elevare il livello di completezza di un sistema BC, è bene non arrestarsi alla sola trasparenza dei protocolli di validazione degli smart contact e delle metriche considerate (open execution), ma occorre anche pubblicare in BC dei documenti dichiarativi, redatti in una forma strutturata (c.d. framework informativo verificabile o anche framework di governance tecnica) in modo da essere leggibili con più applicativi.

In Appendice 3 si riporta un esempio semplificato di framework informativo in grado di rappresentare in modo completo e in linguaggio naturale (ma leggibile anche da sistemi automatici) l’esecuzione dei singoli smart contract nei passaggi dell’accordo di di filiera[54].

7.           Digital twining

Nel descrivere progetti BC applicati a filiere produttive e distributive, si fa spesso riferimento al c.d. digital twining a voler intendere che in BC è possibile generare un “gemello digitale” di un asset fisico. Alla base c’è l’idea che tra i due enti, quello reale e quello informatico, si possa creare una sorta di entanglement per cui le sorti del primo si riflettono in modo isomorfo sul secondo.

In realtà, il twining e l’entanglement sono due aspetti diversi, e parlare di gemello digitale risulta decisamente fuorviante[55], generando spesso una serie di errate deduzioni che non aiutano ad inquadrare correttamente le BCO rischiando di decretare in anticipo il fallimento di un progetto o la sua inutilità.

7.1      I termini del problema

Per realizzare un vero e proprio gemello digitale – nel senso inteso nei progetti BC – occorre risolvere due ordini di problemi: (i) attribuire carattere di individualità al prodotto fisico che si intende tracciare (single-out) e (ii) far sì che le informazioni relative al prodotto siano veritiere, tempestive, complete e correttamente associate tra loro in BC (entanglement) e mantenute lungo la filiera di fornitura (traceability and transparency).

Quanto al primo problema, si tratta di associare in modo univoco un prodotto fisico ad uno specifico identificativo la qual cosa, salvo rare eccezioni, ovvero allorché il prodotto fisico è dotato di caratteristiche intrinseche che lo rendono di per sé unico e distinguibile dai suoi simili (es.: un diamante con le sue venature), non è sempre possibile[56].

Soprattutto per i prodotti seriali, sfusi, fungibili o a basso valore, riuscire a caratterizzare ogni singolo prodotto (o quantità o lotto) in modo che sia riconoscibile e distinguibile dagli altri è una operazione che potrebbe essere economicamente svantaggiosa o praticamente impossibile allo stato attuale della tecnica.

Sono invero allo studio, e alcune già sul mercato, diverse soluzioni che assicurano il mantenimento della tracciabilità in ogni fase della trasformazione (es.: sul cotone esistono traccianti spruzzati sulla materia prima in fase di coltivazione che mantengono la tracciabilità del prodotto fino alla vendita di una maglietta attraverso le fasi di filatura, tessitura, coloratura, confezionamento; o addirittura dei chip commestibili per prodotti alimentari da banco[57]), tuttavia, non si adattano a tutti i prodotti e a tutte le fasi produttive. Non è infatti solo un problema di individuazione di un prodotto, ma anche di sua contraffazione e sofisticazione. Ad esempio, applicare un QR code sul prodotto – soluzione, questa, spesso utilizzata in progetti BC di filiera – non risolve in alcun modo il problema del single-out poiché uno specifico QR-Code è facilmente riproducibile su un numero indefinito di prodotti diversi (v. in Appendice 4 una scomposizione del problema dell’associazione tra prodotto e token).

Quanto al secondo problema (attendibilità delle informazioni associate al gemello digitale), non esistendo un automatismo tra fatti che riguardano un prodotto e informazioni su tali fatti caricate in BC, non esiste alcuna garanzia che, anche laddove fosse risolto il problema del single out, il flusso informativo non sia intercettato e modificato in modo fraudolento e opportunistico.

Abbiamo già illustrato, tuttavia, come mitigare fortemente i rischi relativi a tale problema nei precedenti paragrafi, ricorrendo cioè ad una gerarchia informativa quanto più possibile orizzontale (distribuita) tale che non occorra riporre fiducia in uno o pochi soggetti, ma in cui le varie fonti informative (operatori e IoT) contribuiscono in modo eguale, autonomo e indipendente alla scrittura di un’unica storia coerente sicché sia impossibile che tale storia sia falsa senza che un accordo fraudolento tra un numero elevato di stakeholder (accordo, peraltro, che necessiterebbe di continue condotte fraudolente per non far emergere l’incoerenza della storia anche a distanza di tempo).

Messe a fuoco le due questioni fondamentali del digital twining, si può correttamente impostare il problema affinché la creazione di un gemello digitale abbia effettivamente senso e utilità all’interno di un progetto BC di filiera.

7.2      Invertire i termini della relazione.

L’operazione di digital twining non può essere intesa in senso real-virtuale, ovvero come se le informazioni provenienti dal mondo reale vadano ad arricchire e caratterizzare il gemello digitale. Circostanza senz’altro vera e necessaria, ma che non costituisce l’essenza del “twining”.

Invero, il gemello digitale viene realizzato il momento stesso in cui si risolve il problema del single-out e si associa al prodotto individualizzato un token digitale, ovvero un asset digitale altrettanto unico e individualizzato quanto il suo “gemello” fisico.

In tale prospettiva l’entanglement tra asset fisico e digitale (token) opera in senso inverso, ovvero in senso virtual-reale: solo le vicende che riguardano il token possono avere un effetto istantaneo sulle sorti dell’asset fisico ad esso associato.

In tali termini, un gemello digitale altro non è che un token il cui possesso e trasferimento attesta la proprietà (o altro diritto) del possessore sull’asset fisico che esso rappresenta. L’entanglement, quindi, opera sul piano giuridico, attribuendo diritti e obblighi con effetti immediati sull’asset fisico in modo conforme alla circolazione del token. Tutto ciò comporta la costruzione a monte di un quadro regolamentare entro cui operano gli stakeholder e nel quale sono stabiliti gli effetti giuridici connessi alla circolazione dei token.

7.3      Documenti e bolle in chiave NFT

Come visto nei precedenti paragrafi, le sorti materiali di un asset fisico devono riflettere quelle virtuali del token e non viceversa[58]. Pertanto, gli effetti giuridici del trasferimento di un token devono essere riflessi nel mondo reale attraverso atti conformi, per esempio attraverso il trasferimento del possesso materiale del prodotto che il token rappresenta.

Il digital twining va quindi riformulato (auspicabilmente abbandonando in modo definitivo tale locuzione foriera di molti fraintendimenti) riconoscendo che ha importanza prevalente il trasferimento del diritto piuttosto che il trasferimento dell’oggetto cui il diritto si riferisce.

Non a caso, nel mondo della logistica, già si fa ampio utilizzo di token, sebbene non virtuali (documenti cartacei con firma autografa)[59], per cui con la BC si tratta solo di trasferire tali soluzioni giuridiche sul piano informatico.

Le c.d. bolle di trasporto o titoli rappresentativi di merce sono documenti che attestano particolari diritti in capo al loro possessore e che consentono, a certe condizioni e con determinati limiti, il trasferimento di tali diritti attraverso il trasferimento materiale dei documenti.

A tali fini possiamo definire i seguenti concetti.

• single-out: operazione o soluzione che consente di individuare e distinguere un prodotto attribuendo ad esso carattere di unicità;
• digital twining: operazione che consiste nell’associare ad un prodotto un token digitale nonché l’insieme delle procedure e tecniche con cui le informazioni relative al prodotto sono via via attribuite al token tale che permanga nel tempo una “somiglianza” tra prodotto e token digitale (operazione ottenibile solo con elevati gradi di completezza del progetto BC in filiera);
• entanglement: costituzione, trasferimento o estinzione di un diritto (o di altra situazione giuridica soggettiva) avente ad oggetto un prodotto che si verifica come effetto immediato di una transazione del token univocamente associato a quest’ultimo.

• Single-out. Il prodotto viene individuato per proprietà intrinseche (es.: venature di un diamante) o contraddistinto con un material tag in modo da essere unico (per le caratteristiche del material tag, v. Appendice 4, § 3).
• Twining 1. Viene creata una associazione tra il prodotto, o il tag applicato al prodotto, e un token.
• Twining 2. Gli stakeholder di tipo write (direttamente o attraverso IoT) raccolgono le informazioni relative al prodotto e via via le caricano in BC (le informazioni sono associate al token e i dati sono validati e verificati attraverso appositi smart contract);
• Entanglement. Il token, non solo contiene o rinvia ad una fedele ed aggiornata storia del prodotto, ma consente, attraverso la sua semplice circolazione (transazioni), la costituzione, modificazione o estinzione di determinate situazioni giuridiche soggettive aventi ad oggetto il prodotto.

8.           Le potenzialità fintech in una filiera.

La BC nasce come soluzione fintech per disintermediare lo scambio di valore su rete telematica, ovvero offrendo la possibilità di scambiare di titoli rappresentativi di rapporti valutari senza ricorso a terzi fiduciari.

Lo stesso risultato di disintermediazione può essere replicato all’interno di circuiti chiusi in cui gli stakeholder di un network BC intendono regolare tra loro rapporti di debito-credito.

8.1      Autofinanziamento

La realizzazione di un progetto BC di filiera – laddove correttamente realizzato con implementazione delle BCO – non solo rende attendibili agli occhi del consumatore le informazioni sui prodotti, ma rende anche attendibili le annotazioni di poste in dare e avere nei rapporti economici tra gli operatori.

In tale prospettiva, una volta sviluppato un progetto di filiera in BC, nulla impedisce di far leva sulle BCO e implementare anche soluzioni di autofinanziamento della filiera e di distribuzione del rischio e dell’utile lungo tutta la catena del valore.

A tali fini, potrebbe essere costituito un fondo comune con deposito bancario fruttifero le cui quote (rappresentative di una porzione del deposito) sono attribuite agli stakeholder attraverso token convertibili in moneta fiat. I pagamenti tra gli operatori potrebbero avvenire attraverso le transazioni di tali token, per poi procedere a periodiche compensazioni di fine periodo (offsetting) riducendo al minimo, se non addirittura eliminando del tutto, il ricorso all’intermediazione bancaria.

Potrebbero inoltre essere emessi token fiduciari, non rappresentativi di quote del fondo, ma costituenti debito dell’intera filiera per un loro impiego in finanziamenti di breve termine sui pagamenti tra gli operatori.

8.2      Sistemi di compensazione disintermediati

Andando oltre i rapporti interni tra gli stakeholder, la filiera, entro il quadro normativo disposto dal recente Regolamento (UE) 2023/1114 (il c.d. Regolamento MiCA – Market in Cripto-Asset), potrebbe adottare una cripto-attività (ovvero un c.d. “token collegato ad attività”) come unità di misura dei rapporti economici tra operatori, come tale spendibile nelle soluzioni di pagamento tra loro, e non solo. Tale cripto-attività sarebbe infatti tanto stabile e apprezzabile dal mercato anche come mezzo di pagamento – e quindi soggetta a circolazione anche al di fuori del network degli stakeholder – quanto più solido e di lunga durata fosse l’accordo di filiera e quanto più apprezzabili fossero sul mercato i suoi prodotti e servizi.

Un siffatto token digitale avrebbe come sottostante l’economia reale della filiera e il conseguente merito creditizio e professionale dei suoi operatori e consentirebbe attraverso la sua spendita di attrarre capitale di rischio senza ricorso all’intervento di soggetti terzi collocatori di strumenti di debito o capitale.

8.3      Penali e incentivi

Allo stesso modo di come la BC potrebbe intervenire in soluzioni alternative di finanziamento degli operatori, essa potrebbe operare per regolare in modo automatico e trasparente la gestione di penali e incentivi.

Attraverso appositi smart contract, potrebbero infatti essere introdotti in BC criteri automatici di premialità nei confronti degli operatori virtuosi o di penalità per gli inadempimenti contrattuali sulla base di predeterminati parametri (es.: ritardo nei tempi di consegna, scostamento da livelli di tolleranza, ecc.).

La gestione in BC di tali meccanismi di responsabilità e merito contribuirebbe in modo significativo a garantire l’attendibilità dei dati inseriti in BC e l’emersione e confinamento di condotte opportunistiche.

8.4      I vantaggi fintech

La possibilità offerta dalla BC di gestire in modo diretto e trasparente i rapporti di valore abilita il conseguimento di notevoli risultati in termini di gestione finanziaria della filiera e incremento della fiducia tra operatori incentivando condotte cooperative.

Gli “effetti valutari” di un progetto BC di filiera meriterebbero un ampio spazio di analisi e descrizione che in questa sede non può essere accordato[60].

In via sintetica, tuttavia, tali effetti possono essere riassunti nei seguenti punti:

• compensazioni di debito-credito immediate, automatiche e senza intermediazione bancaria;
• possibilità di finanziare gli operatori a mezzo di fondo in cripto-asset autogestito;
• introduzione di una cripto-attività ancorata all’economia reale della filiera (e suo impiego per attrarre capitale di rischio);
• costituzione di fondi rischi (surrogato di polizze assicurative) senza commissioni;
• distribuzione del valore lungo tutta la filiera secondo criteri meritocratici e trasparenti.

9.           Dallo storytelling al fact-checking, innovazioni di processo e di sistema

Secondo Cirianni et al.: «Le aziende agricole all’interno della catena agroalimentare e rispetto alla media nazionale hanno bassi valori di costi intermedi sul fatturato ma, avendo bassissimi volumi di vendite e dimensioni modeste, molte di loro non sono in grado di adottare adeguate politiche di marketing e, soprattutto, di penetrare nei mercati esteri»[61].

L’applicazione avveduta e ragionata delle tecnologie blockchain ed in particolar modo dei nuovi modelli di governance finanziabili tramite i fondi destinati alla realizzazione delle politiche di mercato e alla realizzazione della strategia Farm to Fork, potrebbe contrastare i contesti di concorrenza fortemente alterati da grandi investimenti in marketing per riportare l’attenzione sulla qualità del prodotto (eccellenza delle aziende agricole italiane).

L’auspicata trasformazione tecnologica e culturale delle imprese agricole potrebbe diventare l’abilitatore socio-economico principale per il passaggio da logiche di storytelling in favore di logiche di fact-checking effettive e complete, prevedendo, a contorno, la pianificazione di campagne di pubblicità sociale volte a sensibilizzare i consumatori su questi aspetti. A seguito di tale trasformazione del marketing d’impresa, si formerebbero le basi per generare un circolo virtuoso lungo il quale la sola possibilità tecnica di poter verificare e dimostrare la veridicità delle informazioni di rintracciabilità dovrebbe generare una richiesta di accesso a queste informazioni spostando l’attenzione del consumatore sulle qualità e sui valori del prodotto piuttosto che sulla sua narrazione.

In effetti, le tecnologie blockchain producono un valore olistico all’interno della filiera (per cui il sistema complessivo ha valore maggiore della somma delle sue parti), data la loro caratteristica fondamentale di poter organizzare e reingegnerizzare le relazioni fra i partecipanti tramite una tecnologia a supporto della disintermediazione del trust dei consumatori, auditors, regolatori e partecipanti. Dal miglior controllo dei processi e dei dati, potendo contare su una fonte unica di informazioni attendibili condivisa fra le parti (Single Source of Truth), deriverà un miglioramento dell’efficienza aziendale, grazie all’automazione, indipendenza e velocizzazione dei controlli. Questi stessi meccanismi favoriranno altresì lo sviluppo di sistemi decentralizzati di finanziamento del settore in cui la partecipazione potrebbe essere estesa oltre che ai comuni soggetti del sistema anche agli stessi consumatori che riconoscerebbero nell’azienda e nel prodotto un’attività da supportare e finanziare con le proprie risorse.

Implementazione delle BCO

KPI dei progetti BC di filiera

Di seguito sono elencati alcuni Key Performance Indicators (KPIs) per valutare il livello di implementazione delle BCO e attribuire un punteggio a ciascun progetto di filiera.

Framework informativo verificabile

Nel § 6 è stata illustrata la necessità di affiancare alla trasparenza dell’open execution anche la trasparenza della data governance: non ha infatti senso mostrare solo le operazioni di computazione dei dati senza, al tempo stesso, dichiarare quali operazioni e per quale ragione devono essere svolte, nonché chi e quando deve svolgerle.

Questo set di informazioni non riguarda direttamente il prodotto di filiera, ma il ruolo, i compiti e la responsabilità dei soggetti coinvolti nel processo produttivo. La sua ostensione dovrebbe essere utilmente effettuata secondo un framework informativo scritto all’interno di semplici file di testo riferiti ognuno ad uno stakeholder di tipo write e commit il cui insieme descrive, in modo completo ed esaustivo, la data governance di un sistema.

Di seguito è riportato un esempio di tale framework su file in formato human and machine readable (es.: JSON).

Token e material tag

Nel paragrafo 7 è stato illustrato il primo problema del digital twining consistente nelle difficoltà o impossibilità, in alcuni casi, di distinguere un prodotto al fine del suo tracciamento in BC.

Le soluzioni tecniche per conseguire tale distinzione sono numerose e in continuo sviluppo. Quali esse siano, tuttavia, tutte devono risolvere una serie di problemi di ordine logico che, per esempio, i classici QR-Code, spesso impiegati in progetti di tracciamento in BC, non risolvono affatto.

1. Caratteristiche del token

Un token è un asset digitale unico, cioè un documento digitale, che grazie alla tecnologia BC, è durevole, non falsificabile, storicizzato e non duplicabile. Il concetto è già stato accennato nel § 2.5 a proposito della BCO (voce tokenizzazione), e quindi della possibilità di ottenere un titolo digitale avente tutte le proprietà dei tradizionali titoli materiali.

Il concetto va ora ripreso poiché le medesime caratteristiche unicizzanti del token devono essere implementate nel prodotto fisico che questo deve rappresentare.

2. Single-out del prodotto

Per associare un prodotto ad un token occorre innanzi tutto distinguerlo, renderlo cioè unico, così come unico è il token a cui viene associato, e quindi renderlo diverso da tutti gli altri prodotti simili con esso altrimenti confondibili.

L’unicità e distinzione del prodotto (single out) possono essere ottenute attraverso il rilevamento di caratteristiche intrinseche e individualizzanti, oppure attraverso l’apposizione sul prodotto di un material tag.

In tutti i casi, il single out deve essere stabile, deve cioè mantenersi fino al momento del consumo o almeno fino dalla vendita al consumatore finale, ovvero fino al momento in cui la distinzione non è più necessaria ai fini di tracciamento del prodotto[63].

Il single out ottenuto per caratteristiche intrinseche del prodotto è per definizione stabile e si mantiene per tutta la vita del prodotto fino alla sua alterazione (consumo o danneggiamento). In tal caso, quindi, la connessione univoca del prodotto al token non presenta particolari problemi tecnici, se non relativi alla lettura delle caratteristiche uniche del prodotto, e cioè relativi allo strumento necessario per rilevare tali caratteristiche.

Discorso diverso deve essere invece fatto nel caso in cui il prodotto che si intende tracciare in BC non sia dotato di caratteristiche unicizzanti tali da poter essere facilmente rilevate. In tali casi, la distinzione è operata artificialmente attraverso l’utilizzo di un tag apposto sul prodotto che diventa tutt’uno con esso conferendogli carattere di unicità.

3. Caratteristiche del tag.

Il tag, proprio come il token a cui deve fare riferimento, deve essere durevole, inalterabile (non falsificabile) e non duplicabile. Deve essere cioè stabilmente associato ad un prodotto, e ad uno solo: un tag facilmente riproducibile su altri prodotti o facilmente modificabile o rimovibile non è in grado di conferire unicità al prodotto e, quindi, garantire la sua associazione univoca ad un determinato token in BC.

Le caratteristiche del material tag possono pertanto essere così sintetizzate:

• Originalità. Il tag deve essere prodotto con metodi che non consentono la creazione di due tag identici.
• Unicità. Il tag non deve essere riproducibile su altri prodotti (se non con costi che non giustificano l’operazione)[64].
• Inalterabilità. Il tag non deve essere modificabile (se non secondo quanto stabilito da un eventuale protocollo di aggiornamento).
• Incorporazione. Il tag non deve essere rimovibile dal prodotto se non a costo della sua distruzione o alterazione rilevabile.

[1] Nel presente lavoro il termine “blockchain” (BC) sarà in via generale utilizzato come sinonimo di “DLT”. Per un approfondimento sull’utilizzo tecnico di questi due termini, si rinvia alle definizioni ISO 22739:2020 “Blockchain and distributed ledger technologies — Vocabulary”.

[2] Alcuni esempi di applicazione di BC in settori non fintech, sono citati da V. Nandishwar Jain e D. Mishra M.S., Blockchain for Supply Chain and Manufacturing Industries and Future It Holds!, in International Journal of Engineering Research & Technology (IJERT), Vol. 7 Issue 09, settembre-2018. Vi sono peraltro robuste evidenze che applicazioni BC sono state applicate alla supply chain management (SCM) subito dopo l’apparizione di questa tecnologia (Y. Tribis, A. El Bouchti & H. Bouayad, Supply chain management based on blockchain: A systematic mapping study, MATEC web of conferences, EDP sciences, 2018, 200) con una crescita annuale di oltre l’80% (Y. Chang, E. Iakovou & W. Shi, Blockchain in global supply chains and cross border trade: A critical synthesis of the state-of-the-art, challenges and opportunities, arXiv:1901.02715. arXiv preprint, 2019).

[3] Con ICT – information and Communication Technology si intendono tutti i processi e le pratiche connesse alla trasmissione, ricezione ed elaborazione di dati e informazioni.

^[4] Agricoltura 4.0: il termine mutua le stesse logiche dell’Industria 4.0, per arrivare al paradigma in cui basandosi su tecnologie avanzate (gestione dell’impresa agricola, irrigazione e fertilizzazione mirata, monitoraggio remoto di coltivazioni, animali, macchinari, ecc.) si arriva ad una produzione agricola più efficiente e sostenibile.

[5] Programma d’azione per le persone, il pianeta e la prosperità sottoscritto nel settembre 2015 dai governi dei 193 Paesi membri dell’ONU. Essa ingloba 17 Obiettivi per lo Sviluppo Sostenibile – Sustainable Development Goals, SDGs (https://www.un.org/sustainabledevelopment/) – in un grande programma d’azione per un totale di 169 ‘target’ o traguardi.

[6] Cfr. Da adozione a valorizzazione: la sfida dello smart agrifood, Osservatorio Smart Agrifood, Politecnico di Milano in collaborazione con l’Università degli Studi di Brescia, marzo 2023). Si veda anche l’analisi comparativa fatta da G. Mirabellia e V. Solina, Blockchain and agricultural supply chains traceability: research trends and future challenges, in International Conference on Industry 4.0 and Smart Manufacturing (https://doi.org/10.1016/j.promfg.2020.02.054).

[7] Assieme ai consumatori i soggetti indicati rappresentano i componenti della cosiddetta Food Value Chain (FVC, Catena del valore alimentare)

[8] “Corporate sustainability information” – IAF (International Accreditation Forum) – 2023.

[9] Get It Fair “GIF ESG rating and reporting assurance scheme” è al momento in cui si scrive il primo e unico programma al mondo valutato per finalità di accreditamento da un ente nazionale riconosciuto (Accredia) rispetto alla norma ISO 17029 e avente lo scopo di rilasciare un rating ESG e la valutazione di conformità della relazione di sostenibilità (come previsto dalla Direttiva EU 2022/2464 più nota come CSRD). Il programma Get It Fair soddisfa tutti i 10 principi definiti da IAF ed è promosso dall’Associazione Diligentia ETS (www.diligentia.it).

[10] Il 16 dicembre 2022 è stata pubblicata nella Gazzetta Ufficiale dell’Unione Europea la Direttiva 2464/2022, “Corporate Sustainability Reporting Directive” (“CSRD”) che ha introdotto a decorre via via dal 1° gennaio 2024 l’obbligo di due diligence sociale e ambientale a carico delle imprese stabilite in Europa su tutti i loro fornitori (inclusi quelli stabiliti extra UE). Il futuro gioco competitivo, quindi, si svolgerà tra interi sistemi del valore capaci di fornire a tutte le parti interessate (banche, investitori, clienti, consumatori) il maggior numero possibile di informazioni di sostenibilità relative al prodotto e delle performance di responsabilità sociale (o anche rischi ESG) delle organizzazioni cumulative di tutta la filiera.

[11] Gli obiettivi sopra descritti hanno una chiara indicazione all’interno della strategia “Farm to Fork” (F2F) delineata dalla Commissione Europea (https://ec.europa.eu/food/farm2fork_en). Anche l’OECD (Organisation for Economic Co-operation and Development) punta decisamente sull’impiego della blockchain per traguardare gli obiettivi ESG e ha a tale fine costituito un forum permanente (https://www.oecd.org/daf/blockchain/).

[12] Per la redazione del presente lavoro sono state compulsate centinaia di pubblicazioni aventi ad oggetto la tecnologia blockchain in generale e, in particolare, la sua applicazione in soluzioni di filiera. Gli Autori riscontrano che la quasi totalità di esse non è in realtà centrata sugli effettivi vantaggi conseguibili con questa tecnologia, ma si limitano ad illustrare per lo più gli evidenti vantaggi della digitalizzazione di processi e documenti, della corretta gestione dei dati, della organizzazione o cooperazione degli attori in filiera e dell’impiego di tecnologie complementari (IoT, RFID, ecc.; per una lista delle presunte prerogative della BC, vedi per tutti J. Xu et al. (2020), Blockchain: A new safeguard for agri-foods. Artificial Intelligence, in Agriculture, 4:153-161). In altri casi gli scritti assumono in premessa come elemento dato che le DLT costituiscono una occasione unica per lo sviluppo del settore agroalimentare (ex multis, v. Tripoli, M. & Schmidhuber, J. (2018), in Emerging Opportunities for the Application of Blockchain in the Agri-food Industry, FAO and ICTSD: Rome and Geneva, § 6, p. 25), senza tuttavia spiegare tale assunzione, senza cioè chiarire come dovrebbe essere implementata una blockchain in filiera per garantire i risultati promessi.

[13] Come ricorda B. Kralingen, (IBM, Maersk Joint Blockchain Venture to Enhance Global Trade, https://www.ibm.com/blogs/think/2018/01/maersk-blockchain/, 2018), il data flow nell’industria logistica è ancora per lo più gestito su carta e estremamente inefficiente per costi e procedure. Va tuttavia sottolineato che il progetto Maersk-IBM è stato abbandonato per mancanza di adesione degli operatori del settore (intermodale e altro), forse proprio per l’errata comprensione delle reali opportunità offerte dalla BC oggetto del presente lavoro. Stessa sorte, il progetto sviluppato da IBM-Walmart.

[14] L’Associazione ha censito i progetti di filiera in blockchain che molte aziende italiane hanno pubblicizzato negli ultimi anni. Nonostante ogni buon sforzo, al di là delle pubblicazioni di taglio promozionale, non sono stati reperiti contributi tecnici che spieghino come in concreto sia stata implementata la tecnologia, né le aziende, pure contattate, hanno fornito chiarimenti a tale riguardo. Inoltre, come chiunque può constatare, ad oggi non sono presenti sul mercato prodotti che il consumatore apprezza per qualità e origine per il fatto di essere “tracciati” in blockchain. Per una panoramica dei progetti BC di cui poi, nonostante gli investimenti milionari, si sa poco o nulla, v. N. Patelli e M. Mandrioli, Blockchain technology and traceability in the agrifood industry, in Journal of Food Science, Vol. 85, Iss. 11, 2020; nonché A. Kamilarisa, A. Fontsa, F.X. Prenafeta-Boldύ, The rise of blockchain technology in agriculture and food supply chains, in Trends in Food Science & Technology, 2019, 91:640-652.

[15] Ovvero prima della pubblicazione del famoso articolo di Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System.

[16] Si parla di certificazione quando la “verità” è riconosciuta in via mediata, cioè tramite l’intervento di una autorità in cui riponiamo fiducia. Si parla invece di verifica quando la “verità” è riconosciuta in via immediata, cioè per osservazione o deduzione diretta. Diversamente dalla certificazione e verifica, la “verità” in blockchain è ottenuta solo per validazione, ovvero attraverso lo sfruttamento della capacità del network blockchain di abilitare in ambiente informatico protocolli decisori a consenso distribuito che quindi fanno a meno di un certificatore o di un verificatore. Si tratta tuttavia, almeno nei protocolli criptovalutari, di verità matematiche consistenti nella riconciliazione di partite contabili di dare-avere, come tali non applicabili, senza le opportune considerazioni, a dati di natura qualitativa. Vedremo nei successivi paragrafi come la validazione può essere utilmente impiegata anche in un processo produttivo, a patto che si faccia effettiva applicazione di alcune proprietà dell’architettura distribuita della blockchain (le cc.dd. BCO in § 2.5).

[17] Come si vedrà al capitolo 2.5, la blockchain storicizza i dati rendendoli al tempo stesso resilienti e immodificabili. Per questo motivo si parla spesso (impropriamente) di “notarizzazione”. Tuttavia, il concetto di notarizzazione implica anche un elemento fiduciario, il notaio o pubblico ufficiale rogante, che per sua vocazione è del tutto assente in un protocollo blockchain.

[18] Contra, v. Tripoli, M. & Schmidhuber, J. cit., § 3.2.5, p. 15.

[19] La blockchain è impiegata in progetti di Self Sovereign Identity (SSI), ovvero in soluzioni che consentono l’identificazione di un soggetto attraverso la verifica di una o più dichiarazioni di terze parti attendibili (verifiable credentials). Si tratta tuttavia di implementazioni in cui la blockchain non è necessaria, né funzionale all’identificazione in sé, ma impiegata per abilitare una gestione decentralizzata e disintermediata delle dichiarazioni.

[20] Si è in attesa da anni delle Linee Guida che l’AgID avrebbe dovuto emanare entro maggio 2019 in esecuzione dell’art. 8-ter del D.Lgs. 35/2018 (il c.d. Decreto Semplificazioni 2018) per attribuire efficacia di forma scritta agli smart contract. Si tratta di regole tecniche che probabilmente non vedranno mai la luce se non dopo una riscrittura della norma che allo stato crea non pochi dubbi interpretativi.

[21] Molti contributi si assestano sull’apodittica e acritica elencazione delle asserite caratteristiche peculiari della BC, come proposte da racconti di carattere per lo più sensazionalistico. Oltre a J. Xu et al., Blockchain cit., si veda anche J.F. Galvez, J.C. Mejuto, J. Simal-Gandara, Future challenges on the use of blockchain for food traceability (disponibile su https://doi.org/10.1016/j.trac.2018.08.01).

[22] Come vedremo nel paragrafo successivo, la blockchain sequenzia i dati; li dispone cioè in un unico registro in ordine cronologico. Tale attività ha un effetto particolare che chiamiamo storicizzazione e che non è del tutto assimilabile al time stamping poiché, rispetto a questo, aggiunge la non duplicazione (uniqueness) dei documenti. Infatti, fuori dalla blockchain, sebbene i documenti digitali possano essere sottoposti a tecniche criptografiche che li rendono immodificabili, essi rimangono comunque duplicabili un numero indefinito di volte e di essi possono essere create altrettante copie “apocrife”. Pertanto, la storicizzazione è qualcosa di diverso dalla mera immodificabilità, spesso citata come prerogativa esclusiva della blockchain.

[23] Come segnala M. Hussey, 5 companies using blockchain to give the fashion industry a makeover, disponibile su https://medium.com, un container che trasporta merci dalla Cina all’Europa richiede l’approvazione di almeno 30 organizzazioni e fino a 200 interazioni.

[24] È proprio questo il punto di fallimento di molti use case giacché le architetture di governance del dato sottostanti, come anche proposte software house multinazionali con i loro progetti BC di filiera, lasciano il controllo delle informazioni nelle sola e piena disponibilità del committente. Utilizzare questa tecnologia senza costituire un network peer-to-peer di contributori di dati, ma lasciandone il caricamento e governo nelle mani di uno solo, non ha alcuna utilità e anzi comporta solo un appesantimento di processi e un aumento di costi di gestione.

[25] Il concetto di smart contract viene sviluppato da Nick Szabo nel 1996 con la pubblicazione di un contributo intitolato Smart Contracts: Building Blocks for Digital Markets, quindi molto tempo prima della blockchain (2007-2008). Originariamente intesto come mero protocollo informatico, assume spesso con la blockchain un significato più esteso – ed errato – di sostituto digitale dei più comuni contratti redatti in linguaggio naturale (sull’origine della locuzione e sul suo inquadramento giuridico, v. F. Rampone, Smart Contract, né smart né contract, in Riv. Dir. Priv., 2019, 2, p. 1).

[26] Lo smart contract eseguito in ambiente blockchain ha comunque caratteristiche diverse da quello eseguito su piattaforma centralizzata poiché codice, input e output sono trasparenti (potenzialmente conoscibili da chiunque, storicizzati e inalterabili) e la sua esecuzione è necessitata, cioè non prevenibile unilateralmente. Si tratta di proprietà che devono essere opportunamente sfruttate per una corretta e utile applicazione della blockchain nella gestione e monitoraggio di una filiera produttiva (v. infra a proposito delle proprietà denominate open execution e validazione nel § 2.5).

[27] Vedi per tutti il rapporto dell’OCSE redatto ad esito del Global Blockchain Policy Forum del 12-13 settembre 2019 (Is there a role for blockchain in responsible supply chains?, 2019, disponibile su http://mneguidelines.oecd.org) che riassume la percezione che hanno gli operatori a proposito dell’applicazione della BC nel business SCM. Pur richiamando le (presunte) prerogative della BC, l’Organizzazione così conclude: «It is too early to say whether blockchain can add value to companies’ existing supply chain due diligence efforts». Va sottolineato, tuttavia, che la tecnologia BC alla data di pubblicazione del paper aveva già superato i dieci anni di età (!).

[28]

[29] Molti Autori propongono una diversa lista di blockchain opportunities. Molte di queste classificazioni, tuttavia, annoverano qualità che sono invero attribuibili alla tecnologia digitale e informatica in generale come visto nel paragrafo 2.4. Fanno eccezione, ancorché in termini più sintetici rispetto alla lista qui proposta, J. Xu, S. Guo, D. Xie, et al., Blockchain: A new safeguard for agri-foods (p. 3), in Artificial Intelligence in Agriculture (2020), disponibile su https://doi.org/10.1016/j.aiia.2020.08.002.

[30] Una piattaforma BC davvero distribuita, deve esserlo a tutti i livelli, non solo tecnologico ma anche, e forse soprattutto, di governance (vedi successivo § 3). Realizzare un network peer-to-peer soggetto ad una governance oscura o dichiaratamente centralizzata o con privilegi, vanifica in grande misura – se non del tutto – la proprietà trustless della BC.

[31] L’open execution è pertanto la possibilità offerta dalla blockchain di rendere trasparente l’elaborazione dei dati consentendo a chiunque di verificare l’attendibilità delle dichiarazioni dei partecipanti. (v. Salah, Damiani, Al-Fuqaha-et al., Open Execution—The Blockchain Model, in IEEE Blockchain Technical Briefs, 2018).

[32] Esistono alcuni protocolli blockchain che consentono la cancellazione dei dati da parte di determinati nodi. In tali casi, tuttavia, tale funzione è comunque condivisa tra i partecipanti che quindi ritengono utile attribuire ad alcuni di loro una particolare autorità. In particolare, alcune piattaforme permettono la cancellazione logica di una transazione marcandola come “deleted”, altre ancora addirittura offrono, in casi specifici, la funzionalità di cancellazione fisica. Questa funzionalità mina l’attendibilità e completezza dei dati registrati nella DLT che la implementa ed è dubbia la sua utilità (v. i cc.dd. contratti selfdestruct di Ethereum recentemente deprecati, in EIP-6049 https://eips.ethereum.org/EIPS/eip-6049).

[33] Il criterio di accettazione dei dati in blockchain risponde in genere a principi maggioritari (come accade, ad esempio, nel protocollo bitcoin), per cui i dati entrano nel network solo laddove essi sono proposti in modo identico dalla maggioranza dei nodi in una medesima scansione di tempo. Un ingresso di dati “falsi”, pertanto, implica l’esistenza di un accordo fraudolento tra la maggioranza dei partecipanti. È l’ipotesi del c.d. “attacco 51%”. La numerosità dei nodi, unitamente alla loro eguaglianza, autonomia e indipendenza, ha impedito fino ad oggi che il network bitcoin (la blockchain di gran lunga più famosa ed estesa) sia stata oggetto di un siffatto attacco.

[34] La “storia” caricata in blockchain è unica, nel senso che non possono essere scritte in blockchain sequenze alternative di dati. Cosa invece possibile adottando altre tecnologie con le quali la disponibilità dei dati è in capo ad un unico soggetto che può opportunisticamente modificare la cronologia dei dati oppure il contenuto di documenti.

[35] K.N. Khaqqi, J.J. Sikorski, K. Hadinoto, M. Kraft (2018), Incorporating seller/buyer reputation-based system in blockchain-enabled emission trading application, in Applied Energy, 209, 8–19; S. Sharma (2017), Climate change and blockchain (2017), disponibile su SSRN: https://ssrn.com/abstract=3088990.

[36] Il successo di bitcoin e dell’omonimo protocollo poggia proprio sulla risoluzione in ambiente digitale del c.d. double-spending problem, ovvero l’impossibilità, prima di allora, di consentire la circolazione del credito attraverso un online cash system (S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008).

[37] Un titolo di credito, al pari di una banconota, altro non è che un documento, non riproducibile e non falsificabile che attribuisce un credito al suo possessore.

[38] Naturalmente, tale rappresentazione fa fede solo in un determinato network. Ogni diverso network può contenere una rappresentazione digitale altrettanto affidabile del medesimo oggetto del mondo reale. Ciò può creare un potenziale conflitto tra rappresentazioni del medesimo oggetto in diversi network. Quale sia più affidabile tra loro, sarà rimesso alla reputazione dei nodi, alla trasparenza dei protocolli e a tutti i parametri di coerenza adottati.

[39] Per «governance di processo» si intende l’insieme delle regole, dei soggetti, dei modi e tempi in cui questi intervengono, nel compiere l’insieme degli atti preordinati al conseguimento di un fine determinato.

[40] In soluzioni pubbliche, come ad esempio in Bitcoin, la corporate governance parrebbe assente, ma non lo è. Essa è piuttosto ridotta per struttura al minimo possibile trattandosi di fatto di un contratto associativo aperto senza vincoli di partecipazione le cui regole sono tacite, direttamente scritte nel codice, condivise su piattaforme sociale e integrate da usi e costumi. I proprietari dell’infrastruttura tecnologica, infatti, sono tutti coloro che volontariamente e autonomamente decidono di partecipare e che sottostanno alle regole implementate nel Bitcoin Core, ovvero nel codice di gestione e aggiornamento dei ledger. Nei protocolli pubblici, inoltre, la corporate governance si articola nelle regole di interazione e collaborazione della comunità degli sviluppatori e partecipanti che discutono e decidono gli eventuali aggiornamenti e fork del protocollo.

[41] Secondo il diritto italiano, considerate le esigenze di partecipazione paritetica e di comunanza di scopo degli stakeholder, un modello particolarmente adatto è senz’altro l’associazione no profit o, più opportunamente, il consorzio ex art. 2602 c.c. In tale struttura, gli obblighi e i contributi dei consorziati sarebbero relativi ai dati in loro possesso e alla capacità di calcolo e di archiviazione informatica per costituirsi come nodi. Peraltro, il consorzio potrebbe svolgere attività esterna (art. 2612 c.c.) avendo in parte anche finalità di lucro. Infatti, un progetto BC di filiera potrebbe implicare la necessaria collaborazione di uno o più partner informatici (qualora non fossero solo i nodi a fornire le competenze e le risorse necessarie), ma potrà anche dare accesso a pagamento ai propri dati a soggetti non contributori, svolgendo a tali fini una vera e propria attività imprenditoriale, sebbene volta al solo autofinanziamento e non alla produzione e distribuzione di utili ai consorziati. In tale prospettiva, il consorzio potrebbe opportunamente assumere la forma di società di capitali (art. 2615-ter c.c.).

[42] Nel protocollo Bitcoin, come in qualsiasi altro protocollo criptovalutario, si parla comunemente di validazione della transazione. Tuttavia, in un network BC di natura non valutaria, riferirsi al data entry solo in termini di transazione è riduttivo poiché i dati proposti in ingresso alla BC non attengono necessariamente ad una operazione di pagamento, ma a dichiarazioni degli stakeholder write che non hanno natura necessariamente contabile (es.: data consegna della merce).

[43] Se in sede di data governance emerge l’esigenza di validare il dato “X” confrontandolo con il dato “Y”, la platform governance provvederà alla scrittura in codice del relativo smart contract.

[44] Sui temi di governance della BC, richiamano l’attenzione (sebbene con esempi forse un po’ poco aderenti ad una realtà di breve e medio termine), R. van Pelta, S. Jansena, D. Baarsb e S. Overbeeka, Defining Blockchain Governance: A Framework for Analysis and Comparison, in Information System Management, 2021, Vol. 38, No. 1, 21–41.

[45] Alcuni di questi livelli di servizio (SLA) potranno essere monitorati con appositi smart contract elaborati anch’essi al livello dela platform governance.

[46] In ambito ISO (ISO 17029), i termini “verifica” e “validazione” assumono un significato tecnico peculiare in funzione dell’orizzonte temporale a cui si riferiscono. Si definisce “validazione” la conferma di plausibilità di assumptions per un uso futuro (es.: un rischio ESG di tipo “looking forward); si definisce “verifica” la conferma di veridicità di dati pregressi. Allo stesso modo, in un progetto BC di filiera, la “validazione” del dato avviene all’ingresso in BC attraverso appositi smart contract ed è declinata in termini di coerenza con i dati pregressi (coerenza con la storia scritta in BC). La verifica è invece attività successiva allorché la validazione di dati successivi rendono via via meno attendibile un dato validato precedentemente. In alcuni casi, un dato validato con livello di attendibilità “ragionevole” o “assoluto” può degradare a “limitato”; circostanza che potrebbe far attivare un protocollo di auditing di terza parte.

[47] Un soggetto è uguale ad un altro se non assume rispetto a questo un ruolo diverso o gli è riconosciuto un peso decisionale maggiore. Un soggetto è autonomo allorché le proprie decisioni sono assunte senza vincoli di obbedienza e soggezione a terzi. Un soggetto e indipendente nella misura in cui può provvedere da sé alla propria esistenza e sostentamento. Naturalmente, nessun soggetto è uguale ad un altro, né è autonomo e indipendente in termini assoluti. Si tratta, invero, di accertare, relativamente gli uni agli altri, i parametri di eguaglianza, nonché di accertare il diverso grado di autonomia e indipendenza. Ciò deve essere fatto secondo parametri misurabili ricorrendo ad indici oggettivi (es.: governance di voto nelle società commerciali, rapporti di colleganza societaria, ammontare delle commesse provenienti da unico committente, ecc.). In tale prospettiva, un protocollo BC potrebbe ben prevedere (e in alcuni casi “deve” prevedere) ruoli diversi dei nodi e degli stakeholder, diverso loro peso decisionale, parziale dipendenza economica, senza che ciò infici necessariamente l’architettura distribuita del protocollo di validazione (vedi Appendici 1 e 2).

[48] Come efficacemente scrive il World Economic Forum (Inclusive Deployment of Blockchain for Supply Chains: Part 1 – Introduction, marzo 2019, disponibile su https://www.weforum.org/whitepapers/), «Blockchain is a Team Sport» (p. 19).

[49] L’elemento della numerosità degli stakeholder di tipo W è tipico di progetti BC non meramente contabili. Al contrario, nel protocollo Bitcoin, tipico protocollo BC di tipo contabile, non è necessario che ricorra una moltitudine di stakeholder W in quanto la validazione è effettuata solo in esito di una verifica di carattere matematico (eseguita dagli smart contract, ovvero dalle macchine degli stakeholder di tipo C) e non di coerenza con altri dati forniti in precedenti input degli stakeholder C o risultanti dall’output degli smart contract.

[50] Si riferisce alla necessità di provvedere ad un «controllo incrociato dei dati» anche M. Di Cillo, L’applicazione delle tecnologie smart contract e blockchain al settore agrifood: profili innovativi e criticità, in Camminio Diritto, 11/2021, disponibili su https://rivista.camminodiritto.it/articolo.asp?id=7788; nonché rapporto Accenture (Tracing the Supply Chain. How blockchain can enable traceability in the food industry, Dublin, 2018) secondo il quale, concludendo, «Sharing product data on the blockchain is key to establishing and tracking provenance. Tracing a food commodity digitally requires consistent data on the identity of the commodity as it passes through the supply chain» (p. 47).

[51] È questo il principale punto di caduta dei progetti BC esaminati dagli Autori di questo contributo. In tutti i casi esaminati, benché si faccia ricorso a piattaforme esistenti che soddisfano il primo requisito del MVE, il data entry è poi ridotto all’iniziativa e responsabilità di un solo operatore, il che contrasta inevitabilmente con l’obiettivo trustless che dovrebbe essere alla base dello sviluppo di un progetto BC.

[52] Vedi. S.C.L. Koh, A. Gunasekaran, T. Goodman, Drivers, barriers and critical success factors for ERPII implementation in supply chains: a critical analysis, in J. Strat. Inf. Syst. 20 (4), (2011) 385–402; R. Addo-Tenkorang, P. Helo, Enterprise resource planning (ERP): a review literature report, in Proceedings of the World Congress on Engineering and Computer Science, 2011 Vol II, San Francisco, USA.

[53] Molte aziende che hanno adottato progetti di filiera in BC pubblicano purtroppo solo articoli di carattere pubblicitario nei quali, peraltro, non è dichiarato l’obiettivo perseguito. Ciò rende pressoché impossibile, anche per il consumatore, accertare la bontà ed efficacia dei progetti stessi.

[54] Ancora pochi gruppi di lavoro internazionali stanno discutendo sullo sviluppo framework di governance simili a quello presentato nel presente lavoro. Fra questi, la Hyperledger Aries RFC 0430, proposta di commento di Daniel Hardman (Chief Architect di Evernym, azienda recentemente acquisita da Avast, e board member tecnico di Sovrin) ed il gruppo IEEE P2145 “Blockchain Governance Standards Working Group”. Meno specifico, ma degno di nota, il gruppo ISO/TC 309 “Governance of organizations” nonché i gruppi relativi alle tecnologie di Self-Sovereign Identity (SSI) dedicati allo sviluppo di framework di governance e data agreement su sistemi decentralizzati come la Trust Over IP Foundation (ToIP).

[55] L’espressione è stata coniata ben prima dell’avvento della BC (che può farsi risalire al seminal paper di Satoshi Nakamoto del 31 ottobre 2008) quando con essa si intendeva la modellizzazione digitale di un prodotto e dei suoi componenti per gestire le fasi produttive, verificare le fasi di assiemaggio e testare la resistenza e funzionalità del prodotto già in fase di progettazione.

[56] Spesso, in letteratura e nelle presentazioni di progetti BC di filiera, è spiegato che le informazioni devono essere associate ad un token digitale. Tuttavia, non è affatto necessario ricorrere ad un token per il tracciamento, a meno che non si voglia negoziare l’asset fisico sottostante (il prodotto di filiera) su un marketplace on line.

[57] A marzo 2022, il consorzio del Parmigiano Reggiano ha annunciato l’impiego in via sperimentale di un P-Chip commestibile (micro-transponder più piccolo di un grano di sale ed altamente resistente) integrato nell’etichetta di caseina di forme di formaggio per garantire l’autenticità e tracciabilità del prodotto (https://www.parmigianoreggiano.com/it/news/parmigiano-reggiano-consorzio-pchip-corporation-kaasmerk-microchip/).

[58] Va ribadito che questo flusso dal virtuale al reale, non pregiudica o sminuisce il flusso inverso dal reale al virtuale. Ogni passaggio produttivo di filiera deve naturalmente essere caricato in BC in associazione al token gemello. Senza tale fondamentale tassello, il twining perderebbe via via di significato in quanto l’asset fisico “assomiglierà” sempre meno a quello virtuale.

[59] Il Consiglio dei Ministri il 17 aprile 2023 ha approvato il Disegno di Legge di ratifica con cui anche l’Italia aderisce al Protocollo addizionale alla Convenzione CMR (Convention des Marchandises par Route) per l’utilizzo della lettera di vettura elettronica (c.d. e-CMR). L’intervento è disposto nell’ambito del Regolamento (UE) 2020/1056 relativo alle informazioni elettroniche sul trasporto merci (eFTI), le cui disposizioni saranno efficaci dal 21 agosto 2024.

[60] L’Associazione Blockchain Italia sta lavorando su diversi tavoli tematici all’indagine scientifica e pratica di diverse soluzioni fintech da adottare in filiere produttive e nei rapporti tra privati e pubblica amministrazione.

[61] ISTAT Working Paper 4/2021, Struttura produttiva e performance economica della filiera agroalimentare italiana (p. 15).

[62] Questa particolare applicazione della blockchain può essere un driver molto interessante, soprattutto nelle filiere che si prestano ad affrancarsi dalla dipendenza economica da un player primario o che possono implementare soluzioni incentivanti di condotte virtuose degli stakeholder. Il tema dell’applicazione delle proprietà criptovalutarie della blockchain è vasto e complesso. Una filiera che esegue operazioni di settling in blockchain delle partite di pagamento potrebbe con il tempo adottare una soluzione sul modello elaborato nel 2019 dalla Libra Association, in cui la riserva è utilizzata per l’emissione di una nuova unità di conto (valuta) tanto forte e appetibile, quanto più il prodotto della filiera ha successo nel mercato. Tale valuta, sarebbe una sorta di quota societaria ancorata però alla qualità e credibilità di un prodotto (domanda) anziché ad un soggetto giuridico. In tale scenario, la valuta diventa marchio d’impresa e il suo valore diventa la capacità evocativa del segno.

[63] Il noto marchio di distribuzione di articoli sportivi Decathlon, inserisce dei tag su tutti i prodotti (RFID) che comunicano con le casse automatiche al momento dell’acquisto e si disattivano una volta eseguito il pagamento in modo da non far scattare gli allarmi antifurto quando il prodotto è portato al di fuori dei locali commerciali.

[64] L’unicità del tag (non duplicabilità) può essere ottenuta anche “a posteriori”, attraverso cioè la vidimazione del tag al momento dell’acquisto con il passaggio del prodotto alla cassa. In tale ipotesi, la cassa opera come ultimo stakeholder di tipo write e la vidimazione consiste sostanzialmente nell’aggiornamento delle informazioni associate al token qualificando il prodotto come “venduto” (non più vendibile). Pertanto, l’eventuale duplicazione fraudolenta del token impedisce il passaggio del prodotto contraffatto alla cassa e, dunque, la sua vendita (salvo che il prodotto contraffatto sia venduto prima dell’originale il che, comunque, svelerebbe la frode).