Approvazioni, saldi e doppie-spese

Finora abbiamo parlato di DAG, passeggiate aleatorie e vari meccanismi di selezione dei tip; questa parte parlerà di soldi. E’ giunto il momento di spiegare cosa intendiamo quando diciamo che la transazione A approva la transazione B.

Come accennato nel primo articolo della serie, ogni transazione contiene le informazioni del tipo “Alice ha dato Bob 10 IOTA”. E’ compito dell’approvatore assicurarsi che Alice avesse davvero quei 10 IOTA in primo luogo.

Ci si potrebbe chiedere a questo punto: da dove sono venuti questi IOTA? La risposta è che sono stati tutti creati nella primissima transazione nel Tangle, chiamata transazione di genesi. Nessun IOTA aggiuntivo sarà mai creato. Dalla genesi gli IOTA sono stati trasferiti sui conti degli investitori originali del progetto, in proporzione all’importo da loro messo in gioco. In seguito, hanno venduto alcuni dei loro IOTA ad altri, ed alla fine è stata creata una rete di trading.

Tornando ad Alice e Bob, diamo un semplice esempio. La scatola rappresenta una transazione. Per comodità, scriviamo anche i saldi dei conti di Alice e Bob prima e dopo la transazione. Vediamo che all’inizio Alice aveva 10i, che ha dato a Bob, dopo di che Bob ha 10i e Alice non ha nulla.

Alla fine qualcuno, diciamo Charlie, vuole fare il suo pagamento. Egli esegue l’algoritmo di selezione dei tip, e si scopre che ha bisogno di approvare la transazione di Alice. Per fare questo, deve verificare che Alice avesse davvero i 10i che ha speso. Charlie farebbe meglio a prendere sul serio questo compito: se approva una cattiva transazione, la sua stessa transazione non sarà mai approvata!

Per essere assolutamente sicuro, Charlie deve elencare tutte le transazioni approvate direttamente ed indirettamente dalla transazione di Alice, fino alla genesi. Finisce con una lunga lista, che può assomigliare a questa:

  • Genesi crea 15i
  • Genesi dà a Bob 2i
  • Genesi dà  ad Alice 8i
  • Genesi dà a Charlie 5i
  • Charlie dà a Donna 3i
  • Bob dà ad Alice 2i

Questa è solo una delle opzioni naturalmente; qualsiasi lista che finisce con 10i nel conto di Alice e 0 in quello di Bob è accettabile. Charlie deve anche tenere traccia di tutti gli altri conti del sistema, per assicurarsi che non scendano sotto lo zero: se uno qualsiasi dei saldi nelle sezioni “prima” o “dopo” è negativo, la sua transazione non è valida.

Diamo un’occhiata ad un caso in cui Alice cerca di dare più IOTA di quello che ha:

Alice ha pagato Bob 100i anche se ne aveva solo 10. La transazione di Alice, e qualsiasi transazione futura che la approvi, sono considerate non valide dalla rete. I saldi negativi non sono ammessi.

La situazione diventa più interessante quando approviamo due transazioni piuttosto che una:

Bob aveva ragione nell’approvare le transazioni di Alice, perché aveva appena abbastanza soldi sul suo conto per pagare entrambi senza scendere sotto lo zero.

Cosa succederebbe se il totale fosse superiore a quello che ha lei? Questo è mostrato di seguito. In questo caso, Bob non può approvare entrambe le transazioni di Alice, perché si traduce in un saldo negativo per Alice. Se Bob fa questo, sta infrangendo le regole del protocollo IOTA, e nessuno approverà la sua nuova transazione.

Quest’ultima situazione si chiama doppia spesa, perché Alice ha speso i suoi soldi due volte. Si noti che non ha infranto il protocollo, perché aveva abbastanza soldi per ogni singola transazione. Forse non intendeva nemmeno raddoppiare le spese, ma ha inviato la sua transazione due volte per errore. Ha comunque creato due rami nel groviglio che non possono essere riconciliati. Questo crea un problema per gli utenti onesti del protocollo IOTA: quale ramo dovrebbero approvare?

La soluzione a questo problema è ancora una volta la passeggiata ponderata che abbiamo appreso nella terza parte. Alla fine uno dei rami crescerà più pesante dell’altro, e quello più leggero verrà abbandonato. Questo implica anche che una transazione non può essere considerata confermata subito dopo l’emissione, anche se ha qualche approvazione, poiché potrebbe far parte di un ramo che alla fine verrà abbandonato. Per essere sicuri che la vostra transazione sia confermata, dovete aspettare che la sua fiducia di conferma sia sufficientemente alta. Questo sarà l’argomento dell’articolo della prossima parte.

Come sempre, siete i benvenuti a fare domande su Discord, @alongal#3938.

Parte 1: Introduzione illustrata al Tangle
Parte 2: Tassi di transazione, latenza e passeggiate aleatorie
Parte 3: Pesi cumulativi e passeggiate aleatorie ponderate
Parte 5: Consenso, fiducia della conferma ed il coordinatore


Il testo originale in lingua inglese si trova qui: https://blog.iota.org/the-tangle-an-illustrated-introduction-1618d3e140ad


Da oggi è possibile dare il vostro supporto su Patreon https://www.patreon.com/antonionardella

Per ulteriori informazioni in italiano o tedesco trovate i miei contatti a questa pagina.
Se avete trovato utile la mia libera traduzione, accetto volentieri delle donazioni 😉

IOTA:
QOQJDKYIZYKWASNNILZHDCTWDM9RZXZV9DUJFDRFWKRYPRMTYPEXDIVMHVRCNXRSBIJCJYMJ9EZ9USHHWKEVEOSOZB
BTC:
1BFgqtMC2nfRxPRge5Db3gkYK7kDwWRF79

Non garantisco nulla e mi libero da ogni responsabilità.


Also published on Medium.