Come analizzato nella sezione precedente la BCoT presenta una serie di re- quisiti che devono essere rispettati affinch´e il sistema sia implementabile. Questi, tuttavia, non sono sufficienti per definire il sistema funzionante e so- pratutto funzionale, in quanto i primi esempi di integrazione tra blockchain e IoT hanno portato alla luce alcune inefficienze e conseguenti problemi de- rivanti dall’attuale implementazione della tecnologia blockchain di tipo per- missionless.
Il principale problema in questo tipo di integrazione ´e dato dall’alto tasso di transazioni per secondo (TPS) generate da un numero massivo di dispo- sitivi IoT, il quale risulta incompatibile con la necessit´a dei ledger permis- sionless di evitare spam e quindi limitare il numero di transazioni effettuabili contemporaneamente. A questo si aggiunge la presenza di tempi di confer- ma relativamente lunghi nelle tradizionali implementazioni e la richiesta di commissioni di trasferimento (come nel caso di Bitcoin) che non facilitano l’integrazione con dispositivi il cui scopo sia quello di inviare anche varie transazioni al minuto per effettuare monitoraggio. Per risolvere questo ti- po di problematiche sono stati proposti protocolli DLT alternativi che non sfruttano il ledger blockchain tradizionale o che lo implementano in maniera permissioned, in modo da limitare la necessit´a di algoritmi di consenso one- rosi ed eliminare del tutto le commissioni.
Una di queste implementazioni ´e sicuramente Hyperledger, che rappresenta ad oggi il pi´u sviluppato esempio di blockchain permissioned, accanto alla quale troviamo IOTA, pensata gi´a dalla sua realizzazione iniziale per supportare micro-transazioni senza commissioni ed essere integrata su dispositivi IoT.
Risulta quindi evidente come ad oggi, per applicazioni di tipo industriale, siano pi´u appetibili soluzioni di tipo permissioned, che si dimostrino adatte a gestire alti volumi di dati in maniera contemporaneamente sicura e affida- bile. Questo tipo di implementazione risponde certamente alla richiesta di una immutabilit´a dell’informazione e di una sua decentralizzazione, abilitan- do una serie di modelli di business dove gruppi di aziende condividono dati internamente tra partner autorizzati; ´e quindi decisamente possibile ottenere “tracciabilit´a” completa di una supply-chain tramite un sistema BCoT che sfrutti blockchain permissioned. Tuttavia, l’ecosistema che ne emerge non ´
e considerabile del tutto trasparente, per quanto i prodotti siano tracciati; rimane infatti una criticit´a di questo tipo di configurazioni il fattore “traspa- renza”, che deve essere sempre garantita nell’idea di creare un “trust-layer” decentralizzato sui dati che vengono forniti. Infatti, sebbene le blockchain permissioned garantiscano gli stessi benefici delle implementazioni permis- sionless ai loro utilizzatori, non garantiscono completamente l’immutabilit´a e la trasparenza a tutti gli utenti esterni che debbano solo visualizzare i da- ti o parte di essi. In una implementazione permissioned, anche qualora si decida di fornire ad utenti esterni al sistema i soli permessi di lettura sui dati, ´e impossibile per l’azienda che li mostri garantire che questi siano in- tegrali e che non vengano o verranno mai manipolati in qualche forma, se non ponendosi come autorit´a superiore garante di queste qualit´a; l’autorit´a che gestisce il sistema permissioned pu´o infatti in ogni momento modificare
L’introduzione del concetto di fiducia centralizzata, derivante dall’introdurre un’autorit´a garante dei dati, sopratutto qualora questa fosse la stessa che li fornisce (e che quindi non ha nessun interesse a mostrare dati che siano reali ma che potrebbero alimentare un’immagine negativa) ´e in netto contrasto con le caratteristiche della blockchain e ancora di pi´u della BCoT. Questa conseguenza delle blockchain permissioned ´e la principale fonte di discussioni in ambiente blockchain, dove si scontrano due differenti opinioni: da una par- te i sostenitori dell’uso delle sole blockchain tradizionali (Bitcoin, Ethereum e simili), dall’altra coloro che vedono anche in queste nuove implementazioni permissioned la possibilit´a di allargare il campo di applicazione di questa tecnologia.
Volendo provare a proporre una soluzione per risolvere questa contro- versia, sfruttando il caso industriale di partenza di BlockWEEE, si ´e deciso per un’implementazione di tipo ibrido che ad oggi non trova alcun riscon- tro in letteratura. Il sistema che verr´a presentato, dove ad una blockchain permissioned realizzata tramite Hyperledger Fabric ´e affiancata la registra- zione dei dati sul Tangle di IOTA, ´e pensato per unire benifici di blockchain permissioned e permissionless, mantenendo i dati sempre in duplice copia e garantendoli tramite un ledger decentralizzato e pubblico all’utente finale; mentre l’azienda utilizza la blockchain privata per velocizzare i processi di scambio informazioni e la loro registrazione, l’utente comune ´e in grado in ogni momento di controllare autonomamente la completezza e integrit´a del- l’informazione ottenuta.
I nodi BCoT possono essere quindi usati per collezionare dati provenienti da tutti gli attori della catena di produzione facenti parte di un consorzio, utilizzando Fabric per realizzare la rete che colleghi produttori, operatori logistici e distributori di un prodotto. I nodi blockchain, installati in ogni punto chiave della supply-chain, realizzano un DB decentralizzato e condivi- so sul quale i vari attori possono registrare dati con la sicurezza che questi non possano essere modificati o eliminati da parte di altri utenti; sullo stesso DB poi i dispositivi IoT, usati per automatizzare il maggior numero possi- bile di processi, agendo laddove l’intervento umano potrebbe portare ad una potenziale alterazione o falsificazione dell’informazione: in questo modo ´e possibile ottenere un sistema che garantisca trasparenza e affidabilit´a su tut- ta la supply-chain, fornendone un’immagine trasversale a tutti i vari attori che vi partecipano, oltre che ad utenti esterni.