Protocollo IOTA: perché chi si occupa di IoT deve conoscerlo

Il protocollo IOTA è progettato per eseguire transazioni di dati e di valore tra persone e macchine, oltrepassando i limiti dell’IoT tradizionale.

La diffusione delle architetture Service Oriented oggi

La maggior parte delle applicazioni e dei servizi fruiti via Internet sono basati sull’architettura SOA o Service Oriented Architecture.

Una architettura SOA è composta da molti elementi funzionali e in modo semplificato si possono raggruppare in due parti: un lato client e un lato server.

Ad esempio, possiamo accedere con un web browser (il client) a un server web e scaricare una pagina HTML.

Il modello architetturale è molto affidabile anche perché basato su una rete di comunicazione che virtualmente garantisce la trasmissione senza errori su qualsiasi media sufficientemente veloce: il protocollo TCP/IP.

Questo protocollo, alla base della rete Internet, crea una connessione virtuale tra due end point e si occupa direttamente di gestire la perdita di pacchetti entro un limite ragionevole. Superato questo limite, la connessione “cade”. In pratica, anche se i due end point non sono direttamente connessi, TCP/IP produce l’effetto di una comunicazione diretta mediante un media fisico che può subire disturbi o essere interrotto.

Il modello client-server è adottato comunemente anche quando il servizio offerto dal server consiste nel mettere in contatto due client. Ad esempio, applicazioni come Telegram, Messanger o WhatsApp usano un server per ricevere e ritrasmettere i messaggi tra due utenti di una chat. Il motivo principale di questa scelta architetturale consiste ovviamente nel dover garantire l’asincronicità tra invio e lettura dei messaggi perché il ricevente potrebbe non essere connesso. Pertanto i messaggi devono essere memorizzati sul server.

Se portiamo questo modello in uno scenario IoT con device molto piccoli, alimentati a batterie e connessi mediante canali wireless con poca banda condivisa, le motivazioni per intermediare la comunicazione tra due device si riducono significativamente. La necessità di mantenere attivo il collegamento TCP/IP tra device e server richiede che il device sia costantemente alimentato e che mantenga attiva la connessione inviando messaggi di controllo al server.

Se il media trasmissivo è inaffidabile e condiviso (ad esempio un canale radio), il rischio è che il solo traffico di controllo di migliaia di device porti alla saturazione del canale di comunicazione.

Per questo motivo è stato progettato il protocollo MQTT, il cui modello organizzativo può essere descritto in modo semplificato come “client-broker-broker-server”.

Questa architettura permette al broker del server di coordinare i broker di molti client affinché inviino messaggi sul media in modo coordinato, senza rischiare conflitti che comportino errori di trasmissione.

Il protocollo MQTT, in pratica, interrompe la connessione diretta tra client e server e permette quindi anche la connessione indiretta tra due client.

Questo passo in avanti verso “l’Internet delle cose” non è tuttavia sufficiente per supportare miliardi di device. L’architettura MQTT ha due importanti limiti:

• non fornisce strumenti per creare comunicazione riservate tra i device;
• richiede che i device siano costantemente attivi per poter ricevere messaggi.

Il primo punto è critico per molte applicazioni e in generale richiede altre tecnologie per accertare l’origine e l’autenticità dei dati ricevuti o semplicemente per garantirne la riservatezza.

Il secondo punto è particolarmente critico per molte applicazioni che “consumano” dati ma non necessitano di riceverli in tempo reale. Ad esempio, un sistema di analisi dei parametri di un motore può essere attivato periodicamente e necessita di accedere ai dati solo in quel momento. La richiesta di invio dei dati on demand richiederebbe la capacità del device di monitoraggio di inviare un picco di dati in poco tempo e imporrebbe quindi la disponibilità di un media molto performante.

La soluzione normalmente adottata in questi casi consiste nel mantenere attivo un collettore di dati che li memorizza in un database. La soluzione è efficiente ma ha alcuni importanti limiti:

• i dati vengono “segregati” in un contenitore accessibile solo da specifici utenti e con particolari metodologie;
• si crea un punto di attacco dove è possibile manipolare i dati;
• la scelta delle sorgenti e quali dati collezionare deve essere effettuata preventivamente.

Di solito, se si decide di non raccogliere alcuni dati, si agisce sulla configurazione del device che li crea e ciò impedisce ai ricevitori con esigenze diverse di usare lo stesso device che potrebbe produrre dati per entrambi.

In sintesi, sebbene MQTT risolva molte problematiche di comunicazione di piccole reti di device IoT, non è adatto a supportare le esigenze di applicazioni complesse e in particolare non è adatto alla creazione della “Machine to Machine Economy” ovvero un mercato di dati in cui non esiste alcuna relazione predefinita tra produttori e consumatori.

Un ulteriore elemento da tenere in considerazione è quello economico: MQTT, e più in generale il modello client-server, comportano costi crescenti in modo lineare al crescere del numero di client connessi al server.

Peer-to-Peer, una soluzione alternativa

Una alternativa al modello architetturale client-server è il peer-to-peer, che prevede la comunicazione diretta tra due (o più) end point. Sul peer-to-peer si basa, ad esempio, il VoIP per creare canali efficienti di comunicazione audio e video tra due device.

Un esempio di applicazione di scambio dati basata su modello Peer-to-Peer è BitTorrent.

BitTorrent è usato in molte applicazioni IoT per distribuire aggiornamenti software a device remoti, o in generale quando occorre inviare lo stesso dato a molti destinatari.

BitTorrent sfrutta l’asimmetria dei collegamenti low cost (ad esempio la A di ADSL sta per Asymmetric) per velocizzare il download di file da una rete di “peer”. Con peer si indica sia il client che il server perché in una rete BitTorrent ogni device può svolgere entrambi i ruoli condividendo dati in suo possesso. Il peer ha molta banda in ricezione e poca in trasmissione, quindi può attivare connessioni TCP/IP dirette con molti peer in parallelo. In BitTorrent, ogni peer che possiede una copia di un file richiesto ne invia una parte (il protocollo permette di coordinare i peer evitando duplicazioni). Ogni peer che invia un blocco del file impegna poche risorse computazionali perché ha poca banda in upload, ma sufficiente per inviare un blocco del file in un tempo limitato. Dall’altro lato del collegamento, ogni blocco trasmesso occupa una parte della ampia banda disponibile in ricezione. Il risultato è un trasferimento molto veloce dell’intero file diviso in blocchi trasmessi da molte sorgenti in parallelo.

L’assenza di un elemento centrale, tipico del modello client-server, elimina ogni possibile collo di bottiglia nella comunicazione tra i peer e rende il sistema scalabile con costi non lineari e dipendenti dal numero di dispositivi di cui è composta la rete.

Il modello Peer-to-Peer è alla base della Distributed Ledger Technology (DLT in sigla) o registri distribuiti.

I DLT sono nati per scambiare valore tra utenti e, come si comprende dal nome, forniscono un servizio di registrazione di eventi (transazioni economiche) su una rete distribuita e decentralizzata di sistemi (anonimi e indipendenti).
L’idea alla base del progetto IOTA consiste nell’utilizzare il registro distribuito come media di comunicazione tra device IoT.

Questa idea a prima vista può sembrare curiosa e inadatta, ma osservando più attentamente l’architettura, emerge che il rapporto tra un client e un nodo della rete IOTA è esattamente lo stesso che esiste tra un publisher e un broker in un sistema MQTT.

Le differenze emergono quando si analizza quello che accade tra i broker MQTT rispetto a quanto avviene tra i nodi IOTA.

A differenza dei broker MQTT, i nodi della rete IOTA non comunicano in modo sincrono e coordinato da un broker centrale: interagiscono mediante un canale “gossip” in modo totalmente asincrono e decentralizzato.

Questa caratteristica della rete IOTA ha diversi effetti positivi per applicazioni IoT.

Il primo evidente vantaggio è che le prestazioni della rete non dipendono né dal numero di nodi, né dal numero di client. Ogni nodo riceve e ritrasmette messaggi di client o di altri nodi quindi, al massimo, al crescere delle dimensioni della rete, si può osservare una crescita della latenza tra due device connessi a nodi distanti della rete.

Il secondo vantaggio consiste nell’affidabilità del canale di comunicazione prodotto dalla rete tra due device che deriva da due caratteristiche della rete IOTA:

• ogni nodo IOTA è connesso direttamente a cinque o più altri peers (la connessione tra i nodi è basata sul modello P2P) e i peers cambiano periodicamente per garantire che nessun nodo resti isolato;
• nell’inoltrare un messaggio, il nodo lo memorizza nella propria copia del registro immutabile.

Un esempio di applicazione IoT con piattaforma centralizzata

Si deve rilevare e vendere dati di stazioni metereologiche sparse su un territorio. Le stazioni sono connesse alla piattaforma che riceve e memorizza i dati in un database. Il singolo dato raccolto ha un valore esiguo e anche i dati di molte stazioni, aggregati in un unico dataset, non raggiungono valori significativi; tuttavia questi dati sono preziosi per molte applicazioni e distribuirli in tempo reale a molti clienti produce un valore complessivo significativo.

Questo scenario pone molteplici sfide come l’autenticazione dei clienti alla piattaforma, la certezza dell’origine e della correttezza del dato, della sua immutabilità, e così via. Infine, il processo ammnistrativo che gestisce la fatturazione del servizio e il pagamento aggiungono altri costi.

Tutti questi requisiti e gli accorgimenti per risolvere le criticità individuate, elevano notevolmente il costo dell’applicazione e rendendo difficilmente sostenibile un business basato sulla raccolta e vendita di questi dati elementari.

I benefici della stessa applicazione su rete IOTA

Lo stesso scenario realizzato su rete IOTA semplifica significativamente il progetto e riduce i costi. La soluzione può essere realizzata in vari modi.

Il modo più semplice prevede che ogni stazione pubblichi i propri dati con una transazione firmata e criptata.
Il ricevitore potrà ottenere qualsiasi messaggio pubblicato da qualsiasi stazione semplicemente acquistando il la chiave di decifratura e l’indirizzo di pubblicazione.

Un metodo più sofisticato consiste nell’uso di una particolare tecnologia sviluppata dal team di progetti della rete, che permette di creare stream di dati inseriti in messaggi concatenati. Nessuno, senza possedere le chiavi di sicurezza dello stream è in grado di aggiungere messaggi e quindi i dati ottenibili dallo stream sono certamente prodotti dalla sorgente autorizzata. Una nota: gli IOTA Stream sono sottoposti a RFP da un importante istituto di standardizzazione quindi questo strumento diventerà entro l’anno uno standard industriale.

Come nel caso precedente, il ricevitore può acquistare le chiavi per scaricare dalla rete lo stream e decodificarlo, messaggio per messaggio.

L’ultima opzione consiste in una estensione dello scenario precedente: invece di acquistare la chiave (o volendo, il diritto di decifrare i dati della stazione) il ricevitore può inviare token IOTA all’indirizzo della stazione. Con un protocollo simile a quello usato per criptare in modo specifico le comunicazioni tra client e server, stazione e ricevitore si scambiano la chiave di cifratura dello stream, permettendo al ricevitore sia di accedere ai dati già pubblicati, sia ai nuovi messaggi in real time.

In questo scenario vengono abbattuti drasticamente tutti i costi del sistema, incluso quello amministrativo e le commissioni sui pagamenti presenti sui sistemi tradizionali.

Il lettore attento potrà tuttavia sollevare un’osservazione: lo scambio di chiavi tra device e ricevitore richiede che il device sia connesso e abbia una adeguata capacità computazionale.

Ciò è vero in questo momento, tuttavia entro la seconda parte del 2021, la rete IOTA sarà in grado di eseguire dei veri e propri processi computazionali autonomi, capaci di gestire in modo sicuro le transazioni economiche: gli smart contract. Ciò significa che i device potranno essere dedicati a creare stream di dati, mentre la distribuzione delle chiavi di accesso sarà gestita in totale autonomia da uno smart contract che sarà attivato inviando una transazione economica contente le specifiche del dato o del device.

Con la rete IOTA si possono dunque sviluppare nuovi modelli di business "intelligenti" nell'IoT e consentire ai dispositivi connessi e alle macchine di condividere in modo sicuro le informazioni sulla base di un nuovo quadro di 'Trust in the Data'.

A tal proposito, uno dei progetti pilota creato dalla Fondazione IOTA è lo IOTA Data Marketplace. Si tratta di una piattaforma che permette a un dispositivo connesso di accedere a un mercato di dati decentralizzato. Una visione da riassumere direttamente con le parole dell’organizzazione:

“Nel prossimo decennio, ci saranno più di 75 miliardi di dispositivi connessi che interagiranno in modi diversi. Questo darà origine a una "Machine Economy" in cui i dispositivi si scambieranno tutto, dallo stoccaggio, al calcolo/analisi, all'elettricità e ai dati dei sensori. Il commercio di dati in questo progetto pilota evidenzierà ed esplorerà il potenziale di questi sviluppi. Con la prospettiva di decine di miliardi di dispositivi che generano dati, vedremo una proliferazione di dati che non ha eguali nella storia.”

Oltre i limiti dell’IoT: liberare le potenzialità dei BIG DATA

Il primo e più grande ostacolo che impedisce la realizzazione della vision dei 'Big Data' è il fatto che la stragrande maggioranza dei dati rimane “chiusa” in quelli che vengono chiamati 'Data Silos'. I silos non condividono i propri dati al di fuori del proprio ambiente e questo può provocare due problemi: lo spreco di dati magari preziosi per altri settori e un aumento di costi per l’accesso.
Di conseguenza, è possibile anche che nella trasmissione dei Big Data subentrino intermediari e burocrazia, rallentando il processo di acquisizione dei dati utili per il proprio progetto.
Un terzo ostacolo, non meno importante dei precedenti, è dato dal fatto che non in tutti i casi sia garantita l’autenticità e la tracciabilità dei dati.

L’architettura basata sul protocollo IOTA Tangle supera queste complessità e permette di:

• decentralizzare a costo zero tutte le transazioni dei dati, grazie all’utilizzo della DLT open source;
• disintermediare e rendere veloce lo scambio di dati grazie al sistema di micro-transazioni a basso requisiti di risorse;