Sapevate che il Tangle permette anche di avere una transazione offline?
Il seguente articolo spiega come IOTA ed il Tangle gestisce le transazioni , le conferme ed il consenso generale del Tangle.

Stato iniziale del Tangle

stato iniziale

A differenza delle tecnologie blockchain, IOTA non crea una sequenza di blocchi statici sincronizzati ognuno contenente un numero di transazioni. Con IOTA ogni singola transazione può essere associata a se stessa ed in parallelo ad altre transazioni. Le seguenti diapositive descriveranno come funziona l’aggiunta di transazioni, la convalida ed il consenso in IOTA.

La diapositiva sopra mostra un esempio di un Tangle che sarà utilizzato nelle diapositive successive per illustrare alcuni esempi. In questo ed in altri esempi, le transazioni verdi sono già confermate dalla rete con certezza elevata (scopriremo perché dopo. Spoiler: come per la blockchain, si tratta di probabilità e non ci sarà mai certezza al 100% scolpita nella pietra), mentre quelle blu sono solo parzialmente confermate (con una certezza più bassa). Le caselle grigie (e successivamente gialle) rappresentano tip senza alcuna convalida. Le transazioni rosse, nelle diapositive successive, sono in conflitto o non valide.

Nella diapositiva sopra la transazione “α” è un esempio di una transazione insolita. Fa riferimento alla transazione “h” e “l“. Poiché la transazione “h” è già referenziata dalla transazione “l“, “α” selezionerebbe un tip (“l“) ed una transazione che ovviamente non è più un tip in quel momento (“h“). Tale comportamento sembra non essere un problema e per il momento tollerato dalla rete.

Aggiungere una transazione

aggiungere transazione

Per aggiungere una nuova transazione al Tangle, un utente deve scegliere casualmente due tip del Tangle (non ancora confermati, quelli in blu) e convalidarli. Convalidare significa che l’utente (con il suo wallet) controlla la firma crittografica del tip con il PoW (un minimo Proof-of-Work, “prova di lavoro” come protezione antispam) e si assicura che il tip non sia in conflitto con nessuna delle precedenti transazioni (referenziate direttamente od indirettamente). L’utente aggiunge la nuova transazione se i tip scelti sono validi, facendo riferimento a tali tip scelti.

Transazioni non referenziate direttamente o indirettamente dai tip scelti, sono irrilevanti per il processo di validazione corrente. Qualcun altro, o una transazione successiva, si prenderà cura di convalidarle e intrecciarle nel Tangle.

Un’altra transazione

un'altra transazione

Contemporaneamente (o prima o dopo, indifferentemente) un altro utente potrebbe essere in procinto di aggiungere la sua nuova transazione “2” in una posizione diversa. Scegliendo i tip “z” e “y“. In questo modo, convalida una grande porzione delle stesse transazioni già convalidate tramite la transazione “1 (uno)” (da “a” a “k“, “m” e “n“), più ulteriori che non erano nel percorso di convalida della transazione “1 (uno)” (“l“, “o“, “r“, “t“, “v“, “y” e “z“).

Nuovo stato del Tangle

nuovo stato

Sovrapponendo i percorsi di convalida della transazione “1” e “2“, possiamo vedere che alcune transazioni sono confermate solo da una, mentre altre sono confermate da entrambe le transazioni. Le transazioni convalidate e confermate da tutti i tip attuali sono considerate pienamente confermate. Quindi, la transazione “n” si sposta più in profondità nel Tangle ed ora è diventata verde. Da questo momento in poi, tutte le transazioni successive che si riferiscono ad “1” e/o “2” o ai suoi figli o ai loro figli (e così via) continueranno a riconvalidare e confermare “n“.

Cosa abbiamo imparato?

  • Nessuno ha bisogno di vedere e convalidare tutte le transazioni. Ogni utente ha solo bisogno di selezionare e convalidare due transazioni ed le loro transazioni genitore. In tal modo un utente convalida solo una parte del Tangle. Dato il fatto che altri utenti selezionano e convalidano diversi tip e percorsi, ne emerge una convalida collaborativa dell’intero Tangle
  • Con il passare del tempo, quando una transazione si troverà in una posizione abbastanza profonda del Tangle, si creerà un percorso diretto o indiretto a questa transazione da un qualsiasi tip più recente. Tale transazione è considerata pienamente confermata e sarà nuovamente convalidata e riconfermata da ogni singola nuova transazione. Possiamo presumere che sia stata confermata da tutti gli utenti (e macchine) ed abbia un’elevata certezza.
  • Per verificare la conferma, un destinatario deve solo verificare se la transazione si riferisce direttamente od indirettamente a tutti i tip attualmente disponibili (oppure se è accettata con una certezza inferiore da una certa percentuale di essi, come e.g. 80%). Nessuna riconvalida o simile è necessaria. Nota: potrebbero esserci migliaia di tip. Invece di controllare i genitori di ciascuno di essi, è possibile selezionare un campione casuale e fare una valutazione statistica.

Nota che la transazione “n” non è stata ancora confermata perché ora abbiamo meno tip. La prossima diapositiva mostra lo stesso campione con più tip.

Livelli di conferma

conferma

Sono stati aggiunti alcuni nuovi tip per mostrare un esempio esteso. È stato evidenziato il precorso di validazione per ogni nuovo tip. Dalla colorazione è possibile differenziare quali transazioni sono convalidate da quanti tip e i loro livelli di conferma.

Un commerciante può scegliere un livello di conferma/certezza personalizzato. Se la velocità della transazione è più importante del valore della transazione (ad esempio una micro-transazione od una transazione con valore zero) o se il mittente è un amico, è possibile accettare con un livello di conferma del 75%. Ad un livello di certezza del 75% (3 su 4 tip) le transazioni “l“, “o” e “t” potrebbero essere considerate confermate.

Ritardo di propagazione

propagazione

In teoria potrebbe accadere che una transazione lenta “5” sia visualizzata in ritardo a causa del rallentamento del PoW (Proof-of-Work) o dei ritardi di propagazione. Ora che sappiamo della transazione “5“, la transazione “n” non è più completamente confermata da tutti i tip. Tuttavia, la loro certezza di conferma è ancora piuttosto alta con 4 tip su 5 (in realtà ci sarebbero migliaia invece di soli 5 tip). Si tenga a mente: si tratta di un’alta probabilità di certezza – proprio come nelle tecnologie blockchain con le sue conferme in cui ogni blocco aggiuntivo aumenta la probabilità di certezza.

Si noti che la transazione “5” in questo esempio NON sta capovolgendo lo stato della transazione da “confermata” a “non confermata”. Cambia semplicemente il numero matematicamente esatto di certezza (ad esempio se c’erano 100 tip in totale, dal 100% al 99%). Una volta che alcuni successivi riferimenti alle transazioni (e.g.)1” e “5“, la transazione “n” è completamente e nuovamente confermata da tutti i tip. Tali minori variazioni del livello di conferma si verificheranno sempre meno, quando le transazioni si spostano più nel profondo del Tangle.

È da tenere presente che un livello di conferma/certezza del 100% potrebbe essere difficile da ottenere in ogni caso, poiché potrebbe esserci sempre qualche tip da parte dei troll (ad es. un riferimento a qualcosa di inutile o non conforme al protocollo).

Doppia spesa (Double Spend)

double spend

Immaginate una situazione in cui un utente aggiunge due transazioni in conflitto in aree diverse del Tangle (“w” e “y“). Gli utenti successivi potrebbero avere solo una di queste transazioni in conflitto nel loro percorso di convalida (in base alla loro selezione di tip e forse a causa di ritardi di propagazione). Ad esempio, gli utenti che allegano le transazioni “1” e “2” non vedranno il conflitto e confermeranno i loro tip scelti. Quindi, il tentativo di doppia spesa ha avuto le sue prime conferme. Tuttavia, prima o poi deve succedere, che entrambe le transazioni in conflitto siano nel percorso di convalida di una transazione. Ad esempio, la transazione “5” vedrebbe il conflitto e non si collegherebbe ai tip eletti. Invece, riselezionerà i tip fino a quando non troverà dei tip non conflittuali, in modo da essere sicura che si trasformi in una transazione valida.

A seconda della selezione del tip e dell’avanzamento del Tangle, potrebbe accadere che molti altri utenti colleghino le loro transazioni a “w” O “y“, prima che il conflitto diventi chiaro. A seconda di dove gli utenti hanno allegato la maggior parte delle nuove transazioni, “w” o “y” sarà ad un certo punto confermata, mentre l’altra sarà abbandonata. Tutte le transazioni successive collegate a quella abbandonata (poiché non potrebbero vedere il conflitto in arrivo) saranno anche loro abbandonate. Tuttavia, non sono perse, ma possono essere prese da chiunque (ma molto probabilmente il destinatario del pagamento) e riattaccate al Tangle per una nuova possibilità di conferma. Il PoW (Proof-of-Work) dovrebbe essere rifatto, ma non sono richieste nuove firme (signatures) dal mittente.

Risoluzione della doppia spesa (Double Spend Resolution)

risoluzione double spend

Nella diapositiva precedente un utente ha provato a collegare una transazione “5” ai tip “1” e “2“. A causa di un conflitto, ha ripetuto la selezione dei tip ed ha deciso di allegare ai tip “1” e “4“. Un altro utente (o forse lo stesso) ha scelto i tip “2” e “3” per allegare la transazione “7“. Sono emersi alcuni tipi di rami, ma solo uno può sopravvivere, a causa della doppia spesa in “w” e “y“. Sulla base della selezione casuale dei tip (e dal peso complessivo delle transazioni), uno dei due rami riceverà più transazioni secondarie (rispettivamente, peso) finché il Tangle non si trasformerà in uno stato in cui non è più possibile legarsi legittimamente a uno di questi rami. Nell’esempio qui sopra, gli utenti potrebbero continuare a collegarsi alle transazioni “5“, “6” e “8” ma non alla transazione “7“. Quindi, le transazioni “y“, “2“, “3” e “7” non saranno mai completamente confermate.

Come descritto nella diapositiva precedente, le transazioni “y“, “2“, “3” e “7” potrebbero essere nuovamente ricollegate al Tangle. Finché sono (ancora) validi, hanno una nuova possibilità di conferma. Le transazioni “2“, “3” e “7” potrebbero essere confermate, mentre la transazione “y” non sarà più valida.

Tangle offline

tangle offlineIl Tangle consente agli utenti di continuare a creare transazioni in modalità offline (ad esempio all’interno di un ambiente intranet aziendale o continuare ad interagire con i vicini durante un’interruzione della connessione ad internet). Per fare ciò, le transazioni vengono create e connesse tra loro come descritto dal protocollo.

Nell’esempio sopra, le transazioni “1” e “2” sono le prime transazioni offline. Sono collegate agli ultimi tip noti del Tangle online. Le transazioni successive vengono allegate come di consueto. Una volta che un commit al Tangle principale è desiderato (o possibile, nel caso di un’interruzione della connessione) il sottogruppo offline viene finalizzato creando la transazione “8“, che unisce il Tangle offline con un recente tip del Tangle online. Successivamente, la transazione “8” diventa un tip legittimo e può essere selezionata e convalidata da successive transazioni online. I prossimi utenti che si collegano alla transazione “8” online includeranno tutte le transazioni offline nella loro routine di validazione.

Si tenga presente che le transazioni offline possono essere pienamente confermate, come qualsiasi altra transazione, solo una volta che sono entrate nel Tangle principale, come mostrato nelle diapositive precedenti. Se qualsiasi transazione all’interno del ramo offline era in conflitto con il Tangle  principale, le transazioni da “1” a “8” non saranno mai confermate. Anche in questo caso potrebbero essere necessarie alcune transazioni successive per permettere al conflitto di essere visibile da tutti (o dalla maggioranza) dei tip del Tangle principale (come descritto nella diapositiva 8 “Doppia Spesa (Double Spend)”).

 

Il testo originale in inglese si trova qui: https://github.com/th0br0/iota-consensus-presentation.


Per ulteriori informazioni in italiano o tedesco trovate i miei contatti a questa pagina.
Se avete trovato utile la mia traduzione, accetto volentieri delle donazioni 😉
IOTA:
CHQAYWPQUGQ9GANEWISFH99XBMTZAMHFFMPHWCLUZPFKJTFDFIJXFWCBISUTVGSNW9JI9QCOAHUHFUQC9SYVFXDQ9D
BTC:
1BFgqtMC2nfRxPRge5Db3gkYK7kDwWRF79
Non garantisco nulla e mi libero da ogni responsabilità.


Also published on Medium.