Hans Moog ci parla di come la IOTA Foundation propone di risolvere la questione degli indirizzi riutilizzabili. Chi come me utilizza i token IOTA è alla ricerca di una soluzione per utilizzare un singolo indirizzo per diversi scopi (donazioni, pagamenti, etc...).
Questo articolo è stato originariamente pubblicato in due parti, qui trovate entrambe le parti tradotte.

Parte 1

IOTA è stato criticato per aver fatto scelte progettuali che sono fondamentalmente diverse dagli altri nel campo dei registri distribuiti.

Una di queste scelte consisteva nell'utilizzare uno schema di firma quantum resistant, che (pur essendo al sicuro dai computer quantici) non consente di spendere più volte dallo stesso indirizzo senza mettere a rischio i fondi su quell'indirizzo.

La maggior parte dei critici di questa funzionalità sostengono che problemi come l'elaborazione quantica non sia una minaccia imminente e che possono essere apportati aggiustamenti, quando le vulnerabilità degli algoritmi di firma divenranno un problema reale. Soprattutto se l'alternativa crea problemi di usabilità per gli utenti attuali.

Per capire la scelta della IOTA Foundation, tuttavia, è importante capire cosa sta cercando di ottenere IOTA:

Lo IOTA mira a costruire la spina dorsale per la prossima rivoluzione industriale in cui le macchine si scambieranno informazioni e valore indipendentemente dall'uomo (l'Internet delle cose, Internet of Things).

I dispositivi IoT di solito utilizzano tecnologie come FPGA (field programmable gate array) e ASIC (application specific integrated circuit), che non sono facilmente aggiornabili (patchable). La loro logica è fissa (hard-wired) per renderli il più efficienti possibile dal punto di vista energetico. Una volta installati dovranno lavorare esattamente così come sono stati costruiti fino alla fine del loro ciclo di vita. In questo contesto, ha davvero senso pensare alle minacce di domani, per permettere ai produttori di dispositivi di garantire che i loro dispositivi possano funzionare in modo sicuro negli anni a venire.

Prendendo in considerazione i problemi di oggi

Il futuro che la IOTA Foundation immagina impone di pensare in anticipo alle possibile sfide e spesso di scegliere la "via difficile". Essndo anche i membri della IOTA Foundation umani, condividono le stesse preoccupazioni e necessità degli altri. Sarebbe bello avere l'opzione di avere almeno un indirizzo riutilizzabile (come un conto bancario tradizionale) che possa essere tranquillamente utilizzato per cose come:

• pagamenti regolari (donazioni, stipendi o contratti con altre imprese)
• "Rubriche" nei portafogli che ci permettano di salvare un contatto senza dover chiedere un nuovo indirizzo di ricezione più e più volte a quella particolare persona o macchina

In passato sono state viste una serie di soluzioni alternative creative, come quella proposta da Eric Hop di introdurre assegni (in lingua inglese) per l'invio e la ricezione di donazioni. Altri hanno suggerito un approccio di secondo livello per lo scambio di indirizzi aggiornati. Ma finora tutte queste idee hanno svantaggi significativi rispetto agli indirizzi riutilizzabili:

• La negoziazione automatica di nuovi indirizzi di ricezione richiede che il destinatario sia "online" in ogni momento per rispondere a qualsiasi richiesta. In alternativa, devono consegnare le loro chiavi priavate od il seme ad una macchina, che può quindi gestire gli indirizzi per loro conto (soluzione insicura)
• Il controllo dell'assegno deve essere eseguito manualmente o, se automatizzato, richiedere al momento del controllo che il destinatario sia online. Questo alla peggio rallenta il tempo fino a quando i fondi arrivano sicuri nel proprio portafoglio

Inoltre possono verificarsi le condizioni di gara quando la parte mittente non riceve l'indirizzo di ricezione aggiornato in un tempo adeguato (a causa della latenza della rete o ritardi nella comunicazione manuale). Si potrebbe quindi spedire accidentalmente fondi ad un vecchio indirizzo (che è stato nel frattempo speso) nonostante si abbiano buone intenzioni.

Attualmente la IF sta esaminando una possibile soluzione a questi problemi a livello di protocollo, che possa richiedere solo piccole modifiche al protocollo IOTA. Ciò potrebbe consentire il riutilizzo di indirizzi speciali per un numero illimitato di volte senza ridurre la sicurezza o addirittura rompere la resistenza quantica.

Si descrive questa soluzione nella seconda parte di questo articolo e si accoglie con favore la discussione in corso con la comunità sul server Discord.

Parte 2

Nella prima parte di questo post, sono state discusse le motivazioni per l'introduzione di indirizzi riutilizzabili. Inoltre, è stato suggerito perché questo avrebbe funzionato meglio a livello di protocollo, piuttosto che come approccio di secondo livello. In questa parte del post, si delinea la proposta di base.

Prima di leggere questo articolo, si suggerisce innanzitutto di capire come viene utilizzato il seme IOTA per generare e convalidare gli indirizzi, leggendo questi post approfonditi di Koen Maris ed Eric Hop (n.d.t. in inglese, sarà tradotto in futuro). Per questo articolo, assumeremo che possiamo generare un numero quasi infinito di coppie di chiavi pubbliche/private.

Approccio attuale (un riepilogo)

Ogni volta che emettiamo un pagamento da uno dei nostri indirizzi, firmiamo il messaggio utilizzando la chiave privata che appartiene a quell'indirizzo. I nodi possono verificare che la spesa sia stata emessa dal proprietario dell'indirizzo verificando la firma della transazione rispetto all'indirizzo stesso. Poiché IOTA utilizza uno schema di firma resistivo ai quanti, si rivela una certa parte della chiave privata ogni volta che si firma una transazione. Ciò significa che non è possibile utilizzare la stessa chiave privata più di una volta senza compromettere la sicurezza dei fondi su tale indirizzo.

Per superare questo problema, gli utenti sono invitati a:

1. Non spendere mai da un indirizzo più di una volta
2. Quando si spende un totale parziale di fondi da un indirizzo, tutti i fondi non spesi rimanenti, devono essere inviati contemporaneamente ad un nuovo indirizzo (chiamato indirizzo resto (remainder address) ). Consentendo ai fondi rimanenti di essere spesi in modo sicuro in futuro dal nuovo indirizzo (resto)

Il wallet IOTA si occupa automaticamente di questa operazione in background, per permettere ai fondi degli utenti di essere al sicuro.
Quando Alice invia fondi da un indirizzo, il suo portafoglio IOTA sposta automaticamente i fondi rimanenti su quell'indirizzo in un nuovo indirizzo "resto" nel suo wallet. Questo le permetterà in futuro di spendere i fondi in sicurezza.

 

Dopo aver confermato la spesa, i fondi rimanenti risiedono su un nuovo indirizzo non utilizzato.

Questo meccanismo protegge i fondi di chi spende in modo molto efficiente. Tuttavia, la parte ricevente può ancora avere problemi, se qualcuno invia fondi a un indirizzo dal quale è già stato speso (o per un errore del mittente, o a causa di condizioni di gara, come discusso nel post precedente).

In questo esempio, Alice ha già inviato denaro da un indirizzo a Bob. Sfortunatamente, Dave ha successivamente inviato fondi a questo indirizzo utilizzato.

I fondi su questo indirizzo utilizzato non sono sicuri in quanto la chiave privata di questo indirizzo è già stata parzialmente rivelata. Si noti che Alice (il ricevente) non ha potuto impedire a Dave di inviare token a un indirizzo non sicuro.

Nuovo approccio (la proposta della IF)

Poiché lo schema della firma non può essere modificato senza interrompere una caratteristica fondamentale dello IOTA (ovvero la resistenza quantica), è necessario escogitare un altro metodo per utilizzare una nuova chiave privata che permetta di spendere consecutivamente dallo stesso indirizzo.

Considerando che una nuova chiave privata è sempre associata ad una nuova chiave pubblica, ciò significa in effetti che si deve:

• Separare logicamente l'indirizzo dalla chiave pubblica utilizzata per verificare la firma delle transazioni
• Introdurre un metodo per modificare la chiave pubblica associata ad un indirizzo, per ogni spesa

Per raggiungere questo obiettivo, si propone:

1. L'introduzione di un nuovo campo nei metadati della transazione, che permette di aggiornare la chiave pubblica di un indirizzo e informare la rete di questo cambiamento
2. La prossima spesa da questo indirizzo dovrà essere verificata rispetto a questa diversa chiave pubblica anziché all'indirizzo stesso

Per ogni spesa sarà generata una nuova coppia di chiavi pubblica/privata che verrà utilizzata per autorizzare la prossima spesa da tale indirizzo, con la chiave pubblica per la prossima transazione impostata dai metadati della transazione corrente. L'algoritmo per l'invio di una transazione può essere riassunto come segue:

Spesa fondi (ennesima volta da un indirizzo)

1. Costruire la transazione
2. Generare una nuova coppia di chiavi pubblica/privata per la spesa successiva (pubkey_n, privkey_n)
3. Includere la chiave pubblica della coppia di chiavi appena generata nei metadati della transazione impostando il campo corrispondente: nextpubkey = pubkey_n
4. Firmare la transazione con la chiave privata appartenente alla chiave pubblica impostata dalla transazione precedente: privkey_n-1 (Nota: la prima spesa utilizzerà la chiave privata appartenente all'indirizzo stesso)
5. Trasmettere la transazione

I passaggi coinvolti coinvolti nell'invio da un indirizzo riutilizzabile.

 

Tutti i fondi residui rimangono presso lo stesso indirizzo, piuttosto che essere spostati in un indirizzo rimanente. In futuro è ancora sicuro inviare fondi a questo indirizzo.

Per essere in grado di elaborare le transazioni in questo modo, i nodi dovranno semplicemente memorizzare un campo aggiuntivo per indirizzo nel loro stato contabile e modificare la chiave pubblica aggiornata ogni volta che viene confermata una nuova spesa.

Lo stato del ledger cambierà da:

a:

Nota:

• La chiave pubblica è l'indirizzo stesso, se non abbiamo ancora speso dall'indirizzo (vedi AddressA nell'esempio)
• KeyB7 implica la settima chiave pubblica per l'indirizzo B
• KeyX9 implica la nona chiave pubblica per l'indirizzo X

Un confronto "reale mondo" (inventato)

L'attuale approccio di IOTA alla firma dei pagamenti può essere paragonato a quello di avere porte fatte di diamante sulla casa. Sono estremamente sicure ma purtroppo sono anche trasparenti. Quindi, ogni volta che si usa la chiave per lasciare la casa per andare in banca, qualcuno che aspetta fuori può "vedere" una piccola parte della chiave che è stata usata per sbloccare la porta. E ad un certo punto, potrebbero vedere abbastanza per essere in grado di falsificare una chiave ed accedere al contenuto dell'indirizzo.

Per evitare che ciò accada, al momento si portano tutti gli averi ad un nuovo indirizzo (resto) (con un nuovo lucchetto ed una nuova chiave) e non si torna più al vecchio indirizzo.

In confronto, questo nuovo approccio può essere paragonato a "cambiare la serratura" dopo aver lasciato la casa, ma rimanendo allo stesso indirizzo. Quindi, anche se qualcuno dovesse vedere la vecchia chiave, non sarà in grado di accedere alla casa/fondi. Inoltre, si ha il bonus aggiuntivo di un indirizzo stabile dove le persone possono inviare posta (o denaro!).

Fantastico, facciamolo! Attendiamo un minuto! Non così in fretta …

Sebbene la soluzione proposta risolva effettivamente il problema del riutilizzo degli indirizzi, introduce anche alcuni nuovi problemi.

La parte finale di questo post del blog esaminerà questi problemi e discuterà le loro soluzioni.

---

Il testo originale in lingua inglese si trova qui:

• Parte 1: https://blog.iota.org/a-proposal-for-reusable-addresses-part1-bc6dbca84cbf
• Parte 2: https://blog.iota.org/a-proposal-for-reusable-addresses-part-2-d83d328ff1b3

---

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à.

---

Posted from my blog with SteemPress : https://antonionardella.it/una-proposta-per-indirizzi-riutilizzabili-parte-1-e-2/

---