4. IOTA: DLT per l’ Internet of Things
4.4. Sviluppi Futuri
4.4.1. Coordicide
L'uso di un "dispositivo per la verifica delle transazioni" centralizzato, il Coordinator, è stato necessario per garantire la sicurezza durante l'infanzia della rete, rinunciando a parte della decentalizzazione della rete (almeno a livello teorico). La soluzione del Coordicide garantirà che la rete rimanga feeless, preservando al tempo stesso il decentramento e la sicurezza e promuovendo una scalabilità senza precedenti. L'obiettivo è che la rete raggiunga il consenso senza bisogno del Coordinatore, assicurando al tempo stesso che abbia le seguenti caratteristiche:
• Scalabilità: Il tasso di transazioni nella rete non è limitato dal protocollo.
• Sicurezza: Un aggressore non deve poter influenzare il consenso.
• Decentralizzazione: Tutti i nodi onesti possono far parte del processo di consenso.
Le attuali soluzioni DLT possono garantire al massimo due di queste tre caratteristiche contemporaneamente. Questo problema è noto come "scalability trilemma". Una conferma di questo tipo di problema si può vedere in blockchain come Bitcoin, dove si raggiungono sicurezza e decentralizzazione, ma si hanno fondamentali problemi dal punto di vista della scalabilità; per preservare le altre caratteristiche, la blockchain di Bitcoin deve avere dei limiti in termini di dimensioni del blocco, che porrà un limite al tasso di transazioni approvate nell’unità di tempo. IOTA stessa con l’utilizzo del Coordinatore ha dovuto rinunciare in parte alla sua decentralizzazione.
La sola rimozione del Coordinatore non è però sufficiente per ottenere il decentramento. Infatti, il meccanismo di consenso originariamente proposto nel white paper di IOTA richiedeva che la maggior parte delle transazioni provenisse sempre da client onesti. Tuttavia, senza i miners, in IOTA non sussiste il concetto di una potenza di calcolo onesta e costante. Di conseguenza i nodi onesti dovrebbero
91
inviare un flusso continuo di transazioni, indipendentemente dal fatto che stiano effettivamente utilizzando la rete.
Al centro della soluzione fornita dal Coordicide c'è un meccanismo di voto attraverso il quale i nodi richiedono il parere di altri nodi per decidere quali transazioni debbano essere incluse nel Tangle e quali debbano invece rimanere orfane.
Per rimuovere il Coordinatore, è necessario risolvere una serie di problemi. A causa della complessità della soluzione, il Coordicide rende il DLT di IOTA un software modulare. In questa maniera, ogni modulo può essere sostituito in maniera indipendente qualora nuove ricerche rivelino ulteriori miglioramenti, limitando la stagnazione degli aggiornamenti ed aumentandone la flessibilità.
Di fatto il Coordicide è un meccanismo di consenso migliorato, dove i tempi di approvazione della transazione sono ridotti (pochi secondi), i nodi posseggono una loro identità e votano per risolvere i conflitti chiedendo agli altri nodi lo stato del loro registro.
4.4.2. Smart Contracts.
Gli smart contracts di IOTA possono essere definiti come “macchine a stato immutabile”:
Macchine a stato: Ogni contratto intelligente ha uno stato ed è allegato al Tangle.
Lo stato contiene dati come i saldi dei conti, le condizioni di input e le conseguenze nel tempo. Ogni aggiornamento di stato rappresenta una transizione sul Tangle.
Immutabile: Lo stato e il codice del programma del contratto smart sono entrambi immutabili perché sono memorizzati sul Tangle. Lo stato può essere aggiornato in modo incrementale allegando nuove transazioni.
92
Il Tangle fornisce una prova verificabile delle transizioni di stato. Ci permette di confidare che le transizioni di stato siano valide e non possano essere corrotte o erronee.
Per facilitare i casi d'uso eseguibili con IOTA, si sta costruendo contratti off-Tangle.
Sebbene i contratti on-Chain di Ethereum siano popolari per le loro proprietà, hanno alcuni svantaggi significativi; man mano che la rete cresce, la quantità di elaborazione necessaria per produrre lo stesso risultato aumenta. Questa è un'enorme barriera in termini di scalabilità. Inoltre, il costo per l'esecuzione di questi contratti intelligenti diventa proibitivo.
Gli smart contracts di IOTA sono invece attivati in un contesto localizzato, senza costringere l'intera rete ad eseguirli, evitando impedimenti alla scalabilità della rete.
Ogni contratto intelligente ha un proprietario, che è responsabile di:
Creare il programma di contratto smart e presentarlo alla rete.
• Decidere quanto grande sarà il comitato (il numero N) e selezionare i nodi della rete che ne faranno parte.
• Decidere quanti nodi del comitato devono raggiungere un consenso sugli aggiornamenti dello stato del contratto smart (numero è chiamato quorum).
• Definire altri parametri generali di configurazione del contratto smart.
Un proprietario può essere una singola entità, come un'organizzazione o una persona, oppure può essere un insieme decentralizzato di pari, come un consorzio di organizzazioni. In ogni caso, il proprietario gestisce solo l'impostazione e la configurazione del contratto, a seconda del loro contesto e del loro scopo, e non partecipa alla sua gestione. Ad esempio, un contratto smart che gestisce transazioni di alto valore può richiedere un ampio comitato di nodi. Mentre un contratto smart che gestisce microtransazioni può richiedere solo 20-30 nodi nel comitato.
Ci sono molte possibili ragioni per voler creare o gestire uno smart contract. Uno dei motivi è la ricompensa. Anche se le transazioni IOTA sono feeless, i contratti IOTA smart rappresentano un'opportunità di guadagno per le aziende, ad esempio per la copertura dei costi operativi. Sia i proprietari che i nodi del comitato possono
93
ricevere premi; spetta al proprietario negoziare con i gestori dei nodi del comitato per deciderne il valore minimo.
Un'altra potenziale motivazione per far parte di un comitato è quella di costruirsi una buona reputazione. I proprietari possono scegliere di formare comitati solo di nodi con una buona reputazione. Questo tipo di sistema di reputazione potrebbe creare un mercato aperto per i nodi dei comitati che incoraggi il buon comportamento all’interno della rete.
4.4.3. Streams
IOTA Streams è una nuova versione di MAM, dal quale differisce per alcune caratteristiche che possono essere così riassunte:
• Framework crittografico: IOTA Streams non riguarda solo i canali, essendo invece un vero proprio framework per applicazioni crittografiche.
La funzionalità dei canali, significativamente estesa rispetto a MAM, è ora solo una delle applicazioni che può essere implementata. Per gli scopi in cui i canali non sono la soluzione ideale, è possibile costruire un'applicazione diversa utilizzando il framework IOTA Streams.
• Canali: hanno alcune nuove caratteristiche. Come avveniva anche con MAM, un autore può firmare messaggi e più “abbonati” possono ricevere messaggi. Con Streams però gli abbonati possono ora anche pubblicare anche messaggi non firmati all’interno del canale.
• Tipi di messaggi: nei flussi standard di IOTA, i messaggi hanno una struttura basata sull'intestazione. In MAM invece il formato del messaggio era fisso (public, private, restricted), e se il vostro caso d'uso avesse richiesto strutture di messaggio diverse, sarebbe stato necessario utilizzare canali diversi per ogni struttura. Ad esempio, si potrebbero desiderare diversi tipi di strutture per il monitoraggio dei messaggi standard e dei messaggi di avviso. In IOTA Streams, è invece possibile pubblicare
94
entrambi nello stesso canale, e le applicazioni di lettura li distingueranno in base alle loro intestazioni specifiche.
• Miglioramento nel controllo degli accessi: in MAM è impossibile fare dei fork del canale per condividere varie informazioni con diverse parti. In IOTA Streams, è possibile applicare un diverso meccanismo di crittografia ad ogni messaggio in base al suo tipo, tutto in un unico canale. Ciò significa che messaggi diversi hanno regole di controllo degli accessi diverse in base al loro tipo, e le diverse parti possono visualizzare solo alle informazioni a cui hanno accesso.
• Messaggi di collegamento: in MAM, tutti i messaggi erano indipendenti.
Con Streams, i messaggi possono essere collegati l'un l'altro, permettendo l’accesso ad informazioni supplementari sul messaggio corrente.
Inoltre, in IOTA Streams, è possibile modificare i messaggi precedenti in un canale esistente, e mentre il messaggio più vecchio rimane nel Tangle per garantire l'integrità, le applicazioni possono recuperare direttamente solo il messaggio più recente e valido. Questo rende la sostituzione e la modifica di informazioni come le credenziali molto più semplice di prima. È possibile aggiornare le credenziali legate a un'identità digitale, ad esempio, senza dover creare un nuovo canale.
95