È stato spiegato il concetto base della proposta nella seconda parte di questa serie. Si spiega ora perché IOTA non è stato fin dall’inizio progettato in questo modo e perché la soluzione proposta non può sostituire completamente il modo in cui le transazioni vengono gestite in questo momento.

Spoiler Alert: alla fine di questo post speriamo di vedere che possiamo ancora costruire una soluzione praticabile che combini il meglio dei due mondi.


Iniziamo osservando i vantaggi e gli svantaggi di questo nuovo approccio.


Argomenti a favore dell’approccio proposto

  • La ricezione di fondi richiederebbe meno risorse sul lato ricevente, poiché i destinatari non devono generare nuovi indirizzi per ogni pagamento in entrata ed il destinatario deve monitorare un numero inferiore di indirizzi al fine di determinare se i fondi sono stati ricevuti
  • Ciò a sua volta mitiga un possibile attacco simile a DOS, in cui il destinatario viene bombardato da richieste di pagamento, costringendolo a generare e monitorare un numero quasi illimitato di indirizzi (presupponendo un approccio di secondo livello funzionante per gestire tali richieste)
  • Potrebbero anche essere necessarie meno risorse sul lato dell’invio, in quanto il mittente non dovrà più richiedere continuamente nuovi indirizzi di ricezione
  • I wallet possono implementare rubriche per il salvataggio dei contatti con indirizzi persistenti prevedibili
  • Di conseguenza, le società e gli individui potrebbero comunicare i loro dettagli di pagamento sulle fatture. Diventano possibile pagamenti ricorrenti come addebiti diretti e ordini permanenti ad indirizzi statici diventano possibili, rendendo IOTA una soluzione praticabile per i modelli di attività commerciali tradizionali
  • L’approccio faciliterebbe un sistema decentralizzato simile al DNS, in cui gli indirizzi “complicati” IOTA sono mappati ad indirizzi facili da usare dalle paersone. Sarebbe possibile fare riferimento ai contatti utilizzando alias (e.g. indirizzi email); rendendo  IOTA immediatamente utilizzabile come i sistemi di pagamento esistenti (ad esempio PayPal o servizi bancari tradizionali)
  • La convalida del front-end di questi alias di indirizzo potrebbero impedire la perdita dei fondi, se l’utente viene avvisato che l’alias  digitato non è mappato ad un indirizzo IOTA valido
  • I fondi ricevuti sono sempre sicuri al 100%, in quanto i fondi non possono finire su un indirizzo utilizzato
  • Gli attacchi di riproduzione non sarebbero efficaci a causa della chiave pubblica modificata
  • La chiamata API wereAddressesSpentFrom può essere deprecata: questa soluzione temporanea crea attualmente un elenco sempre crescente di indirizzi che limita la scalabilità
  • I bundle si ridurrebbero, perché una transazione completa (transazione di resto) può essere omessa, riducendo il traffico di rete richiesto per le spese.

Il tema comune di questi vantaggi è che la proposta rende IOTA più user-friendly per gli esseri umani e alla fine porterà a un’adozione più ampia. Sono quindi molto preziosi e non dovrebbero essere prontamente liquidati.

Indirizzi prevedibili faciliterebbero la gestione dei contatti e le  transazioni all’interno di  un gruppo di messaggi. Potrebbe questa essere una versione futura di Trinity?

Argomentazioni contro l’approccio proposto

Come accennato all’inizio di questo post, la soluzione proposta introduce alcuni problemi che potrebbero impedire la completa sostituzione della modalità attuale di gestire le transazioni. Di seguito si espongono questi problemi uno per uno, insieme a possibili mitigazioni.

1. L’ordine delle transazioni è importante

Un problema con questo nuovo approccio è che l’ordine delle transazioni ora conta. Una transazione successiva può essere confermata solo se e quando la transazione precedente nella catena è stata vista (ed infine confermata) dalla rete.

Ad esempio, se si inviano rapidamente 10 pagamenti consecutivi da un indirizzo riutilizzabile, la prima transazione modifica la chiave pubblica dell’indirizzo e la nuova chiave pubblica è necessaria per la transazione successiva (e così via). Se la prima transazione non viene confermata e deve essere ricollegata (reattached), ciò significherebbe che le seguenti transazioni saranno posticipate fino a quando tale ricollegamento non sarà confermato. Potrebbe quindi essere necessario ricollegarli (eventualmente più volte) finché non vengono accettati dalla rete nell’ordine desiderato.

Va notato che questo problema esiste anche con l’attuale approccio di IOTA. Una spesa consecutiva può essere verificata solo una volta che la transazione che sposta i fondi all’indirizzo resto è stata vista dalla rete (questo indirizzo sarebbe altrimenti visualizzato come vuoto). Tuttavia, con il nuovo approccio, è più difficile implementare un meccanismo che consenta funzionalità come scoperti temporanei (in cui una transazione successiva trasferisce i fondi di una transazione precedente): il cambio di chiavi significa che non è possibile facilmente verificare la firma di queste transazioni quando vengono elaborate nell’ordine sbagliato.

Anche supponendo che i nodi prestino attenzione all’ordine e “mettano in ordine” le transazioni internamente mentre determinano la loro validità, come aumenterebbe la complessità di verificare le transazioni e richiederebbe più potenza di elaborazione. Questi cicli della CPU potrebbero essere utilizzati per elaborare altre transazioni, quindi questo potrebbero ridurre la capacità di elaborare un numero elevato di transazioni al secondo.

Possibile soluzione:

Parti di questo problema possono essere risolte facendo riferimento direttamente o indirettamente ad una spesa precedente in una spesa consecutiva se la precedente è ancora in sospeso. In questo modo, possiamo garantire la validità di un sub-tangle senza dover prendere in considerazione parallelamente i sub-tangle, nel determinare la validità di queste transazioni in sospeso. Poiché la passeggiata aleatoria avviene da “passato” a “presente”, vediamo automaticamente le transazioni nel loro ordine corretto ed è possibile evitare di ordinarle internamente, ciò alleggerirebbe questi problemi. Questo comportamento aumenta anche il peso della spesa precedente e aumenta pertanto la sua possibilità di essere accettata dalla rete. Una spesa consecutiva dovrebbe quindi comportarsi come una promozione della transazione precedente.

Dovremmo tenere presente che questo problema si manifesta solo se stiamo cercando di inviare contemporaneamente molte transazioni di spesa da un indirizzo riutilizzabile, senza aspettare che venga confermata quella precedente (questo argomento sarà affrontato nella proposta finale alla fine di questo post).

2. Privacy ridotta

Se tutti i fondi appartenenti ad un utente risiedono in un unico indirizzo riutilizzabile, il saldo esatto di tale indirizzo sarà di dominio pubblico. Ciò sarebbe ulteriormente esacerbato dai servizi di mappatura che potrebbero identificare gli utenti tramite il loro alias. Questa riduzione della privacy potrebbe incoraggiare gli hacker e altri criminali ad accedere ai fondi attraverso attacchi tradizionali al di fuori della rete IOTA.

Possibile soluzione:

Il metodo attuale di utilizzare gli indirizzi una sola volta ed inviare i fondi rimanenti ad un nuovo indirizzo funzionerà ancora. Possiamo regolarmente inviare i fondi dal nostro indirizzo pubblico riutilizzabile ad un indirizzo “non riutilizzabile”, che continuerà a funzionare come al momento.

La privacy di questi fondi raccolti può quindi essere ulteriormente aumentata applicando servizi come “mixer(articolo in inglese). Questi sono argomenti di ricerca aperti e si vedranno ulteriori sforzi per aumentare la privacy sul Tangle. Per ora è sufficiente supporre che è possibile spostare i fondi dall’indirizzo riutilizzabile ad quello tradizionale.

3. Si alzano i requisiti per l’archiviazione sui nodi

Poiché i nodi devono memorizzare un campo aggiuntivo nella tabella del registro distribuito, i requisiti di archiviazione aumentano di 243 trits per indirizzo, il che porterebbe ad una dimensione maggiore del database. Inoltre, gli indirizzi svuotati non possono più essere rimossi dal database poiché è necessario tenere traccia della chiave pubblica aggiornata, nel caso in cui l’indirizzo riceva ulteriori fondi in futuro. Un utente malintenzionato potrebbe facilmente inviare spam a questa tabella del registro distribuito ed esaurire molto rapidamente lo spazio sui nodi.

Possibile soluzione:

Si propone di mantenere vivo un indirizzo riutilizzabile nella tabella del registro distribuito se contente un saldo. Ciò significa che un utente deve depositare una certa quantità di IOTA (e.g. 1 IOTA) che dovrà sempre risiedere su quell’indirizzo se vuole essere in grado di usarlo più volte. Una volta che il saldo sull’indirizzo scende al di sotto di questo importo, si dichiara che questo indirizzo non è effettivamente più utilizzato e verrà eliminato dai nodi. In pratica, ciò significa che l’indirizzo viene reimpostato sulla sua prima chiave pubblica e che tutti i fondi in entrata saranno ora su un indirizzo “usato”. Idealmente i wallet si occuperebbero della gestione dei fondi depositati in modo che non si possa accidentalmente spenderli e finire sotto la soglia, quando si invia un pagamento.

Se implementato in questo modo, molto probabilmente si ridurrebbe anche il requisito di archiviazione perché i fondi in entrata non avrebbero più bisogno di essere distribuiti su innumerevoli indirizzi, ma verrebbero accumulati su un numero inferiore di indirizzi.

4. Problemi in relazione ai cluster economici

Anche se il concetto di cluster economici è ancora un argomento di ricerca piuttosto che un problema di implementazione, l’idea di base è chiara. Questo concetto si basa sull’idea che alcune attività in una rete ad alto transazioni (throughput) possono essere viste solo da una certa parte della rete piuttosto che da tutti i nodi esistenti.

Per gli indirizzi riutilizzabili, i nodi devono vedere la transazione originale che aggiorna la chiave pubblica, prima che possano convalidare qualsiasi spesa successiva da tale indirizzo. Questa transazione originale potrebbe essere visibile solo in alcuni cluster ma non in altri.

Possibile soluzione:

Per poter inviare pagamenti tra cluster, è necessario utilizzare indirizzi non riutilizzabili per i pagamenti. Ciò consentirebbe ai nodi lontani di verificare la firma anche senza conoscere la chiave pubblica aggiornata. Poiché è possibile spostare i fondi da un indirizzo riutilizzabile ad un indirizzo tradizionale prima di inviare transazioni, questo non è un problema.

In effetti si suggerisce l’uso di indirizzi non riutilizzabili (quando possibile) per inviare fondi, preferendo indirizzi riutilizzabili quando si ricevono fondi.


Conclusione

È stato dimostrato che la soluzione proposta non può sostituire completamente la modalità attuale di effettuare transazioni e che le decisioni di progettazione prese in passato erano ben fondate.

Può tuttavia fungere da opt-in per ricevere fondi in modo sicuro, senza doversi preoccupare del riutilizzo degli indirizzi e delle condizioni di gara. Dispone inoltre di numerosi miglioramenti dell’usabilità che promuoveranno l’attuale adozione del protocollo da parte del mondo reale.

Implementazione suggerita:

Per bilanciare i pro e i contro, si propone l’introduzione di un indirizzo riutilizzabile per portafoglio, che può fungere da punto di contatto unico per i pagamenti in entrata. Il saldo di questo indirizzo può essere periodicamente spostato su di un indirizzo normale non riutilizzabile, il che rende i fondi disponibili per essere spesi. La spesa da indirizzi regolari (non riutilizzabili) non dipende dal mantenimento dell’ordine delle transazioni, che consente di elaborarli in modo efficiente in parallelo, allo stesso modo in cui vengono elaborati ora.

Allo stesso tempo questo nuovo indirizzo “pubblico” non esporrà troppe informazioni sui nostri fondi perché viene svuotato regolarmente, distribuendo i fondi a nuovi indirizzi che non possono più essere facilmente associati al nostro indirizzo riutilizzabile.

Schema per indirizzi riutilizzabili e non.
Un unico indirizzo riutilizzabile per le transazioni in entrata. Nota, qualsiasi degli indirizzi normali (non riutilizzabili) potrebbe anche ricevere transazioni dirette, come da protocollo corrente.

Rendendo questo nuovo approccio una funzione di opt-in, non si rinuncia a nessuno dei vantaggi del protocollo di base che sono richiesti per scenari come l’IoT ed i cluster economici, mentre allo stesso tempo si apre la tecnologia ad modello di utilizzo più umano-centrico. Questo sarà un passo importante per raggiungere il l’obiettivo di adozione diffusa della tecnologia per le persone e le macchine.

Si invita la comunità a discutere questa proposta su questo argomento del forum e sul Discord di IOTA, in particolare eventuali vantaggi o potenziali problemi che potrebbero essere stati trascurati


Il testo originale in lingua inglese si trova qui: https://blog.iota.org/a-proposal-for-reusable-addresses-part-3-9ec6fa1929d7


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.