MAM, il Masked Authenticated Messaging, è una delle caratteristiche più notevoli del protocollo IOTA. Supponiamo che il mondo coperto da piccoli dispositivi IoT, in cui i loro piccoli lavori, il flusso di dati microscopici e i nano-pagamenti vanno e vengono costantemente.

Il protocollo IOTA, il cui obiettivo è quello di diventare lo strato fondamentale di tale società (digitale), è attualmente il progetto più previdente che sfida questo incombente cambiamento di paradigma. MAM è la sua forza motrice principale, che distingue il protocollo IOTA da altri ledger distribuiti (blockchain, hashcash, etc…) rendendo il flusso di dati e le transazioni molto più economici, più sicuri e onnipresenti.

MAM è ancora in fase di sviluppo (voci di corridoio parlano già dello sviluppo di MAM+, n.d.t.), nonostante il fatto che sia immensamente importante per IOTA ed il suo futuro,  per quanto riguarda la sua attuazione tecnica solo una quantità limitata di informazioni sono attualmente disponibili al pubblico.

Questo articolo cerca di spiegare nel modo più comprensibile possibile questa tecnologia, per permettere a più persone di avvicinarvisi.

Canali MAM (MAM Channels)

Come YouTube ed altri media, MAM utilizza dei canali (Channel), dove si incontrano il proprietario che pubblica e gli spettatori che si iscrivono (un po’ come i topic di mqtt). Il proprietario del canale pubblica nuovi dati sul proprio canale e gli spettatori si iscrivono al canale per ottenere i dati disponibili. La proprietà (essere prorpietario) del canale è implementata e protetta in IOTA dal seme (seed).Mai, esporlo e conservarlo in modo sicuro.

Modalità del canale (channel mode)

Per l’editore (publisher) Sono a disposizione 3 (tre) opzioni al momento della pubblicazione dei messaggi sul proprio canale.

Pubblico (Public): tutti possono vedere, Privato (Private): solo l’editore (e.g. chi possiede il seme/seed) può vedere, e Limitato (Restricted): è possibile specificare quali sono gli spettatori, comunicando a loro una chiave. Questa chiave è chiamata chiave secondaria (sideKey) nel codice sorgente. In questo articolo questa chiave si chiamerà sideKey. Mentre per le altre modalità si parlerá di rootkey, che funziona quale idenrificatore di messaggio ed è data agli spettatori per trovare il messaggi sul Tangle.

Public: Messaggio mascherato decrifato con rootkey.

Private: indirizzo=hash(rootkey). Messaggio mascherato decifrato conrootkey.

Restricted: indirizzo=hash(rootkey). Messaggio mascherato decifrato con sideKey.

Messaggi incatenati (Message Chain)

Nel protocollo IOTA, come molti altre DLT (Distributed Ledger Technology), è possibile allegare messaggi arbitrari alle transazioni. A differenza delle altre technologie in IOTA questa operazione è priva di commissioni! Tuttavia, limita il mittente ad allegare un solo messaggio alla volta e non è possibile pubblicare messaggi correlati consecutivi con contesto arbitrario.

Ad esempio, se si desidera pubblicare i dati della temperatura attuale ogni 15 minuti, senza MAM, è necessario inviare ogni messaggio allo stesso indirizzo. Poiché qualsiasi DLT incluso il Tangle è accessibile pubblicamente, è facile per gli attaccanti identificare tale
indirizzo che si aggiorna ogni 15 minuti e interferire con delle transazioni spam. Anche se si decidesse di cambiare indirizzo ogni volta che nuovi dati sono pubblicati, è obbligatorio tenere traccia di tutti gli indirizzi. Ed il loro monitoraggio è relativamente costoso in termini di archiviazione delle informazioni online.

MAM, tuttavia, grazie al suo design di Messaggi incatenati, permette di proteggere il nostro canale da transazioni spam e ci libera dalla gestione di indirizzi cumulativi.

MAM pubblica ogni messaggio in un indirizzo diverso, ma con informazioni dettagliate che li connettono. Su questa catena di messaggi, da una generazione alla generazione successiva, il messaggio attuale porta sempre al messaggio successivo. Il suo flusso è a senso unico.

Struttura di base di un pacchetto MAM (Basic Structure of MAM Bundle)

I pacchetti MAM ha approssimativamente due sezioni, sezione firma (Signature) e sezione MAM, ogni dettaglio verrà spiegato più avanti in questo articolo. I loro dati sono memorizzati come signatureFragment (frammento di firma) delle transazioni nel pacchetto. La firma è utilizzata per la proprietà (essere proprietario) di MAM e quindi il suo controllo di validità. La sezione MAM memorizza l’attuale messaggio mascherato.

mam bundle

Indirizzo: dove viene salvato MAM (Address: Where MAM is being stored)

L’indirizzo che salva il messaggio mascherato è un hash della con la rootkey. L’algoritmo di hash è un calcolo complicato non invertibile che mappa una stringa di lunghezza arbitraria in una stringa di lunghezza minore e non permettere di risalire, in un tempo confrontabile con l’utilizzo dell’hash stesso, ad un testo che possa generarlo. (spiegazione di hash presa da wikipedia)

if (channel.mode !== 'public') {
    // private, restricted mode
    address = Crypto.converter.trytes(Encryption.hash(81, Crypto.converter.trits(mam.root.slice())));
} else {
    address = mam.root;
}

Nota:

Nell’articolo di Paul Handy è scritto che la modalità restricted address =hash(rootkey+sideKey). Ma come si vede nel codice sorgente qui sopra address =hash(root). Quindi in questo articolo sarà spiegato address = hash(root) per restricted mode.

Modalità pubblica (Public Mode)

root è l’indirizzo. root è la chiave di cifratura e decifratura.

02_mam_public
nextRootè un puntatore di connessione al prossimo messaggio. Quando il messaggio mascherato di una generazione viene decifrato, il messaggio non mascherato contiene nextRootche viene utilizzato dai visualizzatori per trovare il messaggio di prossima generazione del canale. In poche parole, è come se trovassi la chiave per aprire la seconda cassa del tesoro, nella prima casssa del tesoro. È possibile rintracciare tutti i messaggi sulla catena dalla genesi del canale. Quando si riceve l’accesso ad una generazione in mezzo, è possibile iniziare a leggere la catena da quel punto. Non è possibile risalire e visualizzare i messaggi precedenti.

Modalità limitata (Restricted Mode)

hash(root) è l’indirizzo. sideKey è la chiave di cifratura e decrifatura.

03_mam-restricted

L’idea di fondo è identica a quella della modalità pubblica. L’unica differenza è l’utilizzo della sideKey per cifrare e decifrare i messaggi mascherati. Chi fosse in possesso della root può trovare la posizione del messaggio, ma solo grazie alla sideKey è possibile decifrare il contenuto.

Proprietà del canale (Ownership of Channel)

Consideriamo il seguente caso:

Alice ha appena pubblicato il suo primo messaggio sul suo canale e vuole che Bob legga il suo post. Quindi, Alice gli ha da la sua root e la sua sideKey. Bob ha visitato il suo messaggio generando address(=hash(root)) e decodificato con sideKey. Bob ha apprezzato il suo post e ha pensa “voglio leggere il prossimo!”. Avendo nextRoot nel corrente messaggio decifrato, tramite questo può generare il prossimo indirizzo. Ma, realizza che Alice non ha ancora pubblicato il prossimo messaggio, al prossimo indirizzo. Bob ha deciso di attaccare il canale di Alice. Essendo in possesso di nextRoot e sideKey, potrebbe postare il suo messaggio cifrato con sideKey all’indirizzo hash(nextRoot)e potrebbe dirottare il canale di Alice.

Dalle informazioni spiegate finora, non c’è contraddizione e potrebbe funzionare.  Questo sarebbe il fallimento di MAM. Non preoccupiamoci, in quanto MAM è stato progettato in modo tale che persone come Bob non possano attaccare il canale. Il prossimo argomento da trattare è come Alice eviti che la sua catena di messaggi possa essere modificata da chiunque altro.

Qui entra in gioco la firma in MAM.

Schema di firma basato sul merkle tree (Merkle tree based signature scheme)

Lo schema di firma basato su merkle tree (link in inglese, per approfondimento) è la technica utilizzata da MAM.

Pubblicazione MAM 101 (MAM Publish 101): root

root è la radice dell’albero di Merkle (Merkle Tree). Per ottenereroot è necessario prima creare il Merkle Tree. Il Seed (Seme) è utilizzato per creare il Merkle Tree.

Merkle tree ha parametri interi (integer) start (inizio) e size (dimensione). Questi rappresentano l’indice (index) degli indirizzi (address) generati dal seme (seed). Ricordiamoci che prendiamo index (indice) quale uno dei parametri (seed, index, security) quando generiamo gli indirizzi (address). Recentemente spiegato qui.

I seguenti A, B, C, D sono rispettivamente chiavi private generate con index = 0,1,2,3. Mentre A’, B’, C’, D’ sono indirizzi corrispondenti.

Merkle Tree

Quindi A”, B”, C”, D” sono hash(address). Fino alla radice root, stringendo verso il basso mediante l’hashing combinato di ciascuna coppia. Si noti che non è possibile procedere prima di root.

Ora abbiamo root. In modalità pubbclia questo root è utilizzato direttamente come indirizzo MAM, in altre modalità è utilizzato address =hash(root).

Pubblicare MAM 102 (MAM Publish 102): Sezione MAM (MAM Section)

La sezione MAM (MAM section) contiene il messaggio mascherato che l’editore sta per inviare, il suo messaggio raw (grezzo) in codice ascii di lungezza arbitraria. Prima di essere allegato (attached) al Tangle è meglio convertirlo in trinario (utilizzando la funzione toTrytes(ascii); // from asciiToTrytes.js della libreria) e salvato quale message (messaggio).

Pubblicare MAM 102 (MAM Publish 102): Sezione MAM (MAM Section)  - nextRoot

Per pubblicare un messaggio mascherato di una generazione è necessario creare DUE merkle tree. Il primo tree è per la generazione corrente e l’altro è per la prossima generazione.

Per la generazione genesi (e.g. la generazione 0 zero), il merkle tree tree0 ha i parametri start0 e count(= number of leaves) (numeri di foglie). Per la generazione successiva (e.g. generazione 1), il merkle tree tree1è generato con parametri start1=start0+count e count.

merkle tree gen 0 and gen 1

Da notare che i merkle tree possono avere dimensioni differenti.

Pubblicare MAM 102 (MAM Publish 102): Sezione MAM (MAM Section)  - Indice del ramo (Branch Index)

L’indice del ramo branch_index è scelto qualsiasi indexdi una foglia del merkle tree della generazione corrente. Nell’esempio seguente il merkle tree è stato creato con start=0 e count=4, così branch_index

dovrebe essere uno a scelta di 0,1,2 e 3.

06 indice del ramo

Pubblicare MAM 102 (MAM Publish 102): Sezione MAM (MAM Section) -Sorelle (Siblings)

Prendiamo per esempio la foglia A', per ottenere root è obbligatorio avere ttutte le altre foglie B'C'D'. Ma non è possibile accedere a quelle foglie, allora come si ottiene root? Le sorelle (Siblings) sono un set di hash complementari, che combinati con la foglia data, permettono di generare root. Guardate la figura sottostante:

07 fratelli

Questa figura esemplifica il caso di branch_index=0, dove è dat solo A'. In questo caso B" e Hash(C"D") sono tutto il necessario per ottenere root. Non è necessario avere altre foglie.

In questo esempio B" e Hash(C"D")sono dette sorelle di A'. In MAM questa è referenziata come Sorella del ramo con indice = 0 (Siblings of branch_index=0). Un differente indice di ramo (branch_index) ha differenti sorelle.

Pubblicare MAM 102 (MAM Publish 102): Sezione MAM (MAM Section) – completato ( completed)

Nella sezione MAM una transazione di message, nextRoot, branch_index and Siblings, chiamato messageTrytes è cifrata con root(Public mode) o sideKey(Restricted mode).
La seguente figura esemplifica una ciftratura limitata (restricted) di una sezione MAM.

08 sezione MAM cifrata

Pubblicare MAM 103 (MAM Publish 103): Sezione firma (Signature Section)

Come menzionato per verificare la validità della sezione MAM, l’editore aggiunge la firma (Signature) al bundle. La firma è salvata in signatureFragment della transazione e queste transazioni sono chiamate sezioni firma (Signature section) nel bundle MAM.

Pubblicare MAM 103 (MAM Publish 103): Sezione firma (Signature Section) – firmare (signing)

La firma di un messaggio mascherato è creata dalla chiave privata =key(seed,branch_index,security). I dati firmati sono messageTrytes della sezione MAM. Lo schema di firma è spiegato qui.

09 signing

Recuperare dati MAM (MAM Fetch)

Per recuperare messaggi mascherati servono la radice root e la chiave secondaria sideKey nel caso della modalità limitata (restricted mode).

Prima di tutto calcolare l’indirizzo dalla radice root ricevuta. Cercare il bundle dell’indirizzo e poi decifrare il messageTryte trovato nella sezione MAM (MAM section) del bundle. La chiave per decifrare è root per la modalità pubblica e sideKey per la modalità limitata (restricted mode). Ora dal messaggio decifrato avremo message, nextRoot, branch_index, Siblings.

Il prossimo passo è di verificare la validità del messaggio mascherato. Ora guardiamo la sezione firma (Signature section) La firma nella sezione firma è utilizzata per validtare messageTryte della sezione MAM del bundle quali dati firmati. Il processo di validazione è spiegato spiegato qui.

Dopo il processo di validazione si ottiene l’indiritto il quale è usato quale indiritto foglia dell’indice index=branch_index del merkle tree e combninato con sorelle Siblings per calcolare la radice del tree (albero), chiamato temp_root.

Se temp_root equivale alla root ricevuta allora il messaggio smascherato è un messaggio valido del canale. Altrimenti non è stato pubbllicato dal proprietario del canale (=proprietario del seme).

Fork della catena (Chainfork)

La catena di messaggi MAM può forkare, ed è semplice farlo. Semplicemente si pubblica un messaggio con un differente indice di ramo branch_index per la generazione che si desidera forkare. Il limite dei rami che si possono forkare in quella generazione è la dimensione del merkle tree. Nel caso in cui si faccia un fork oltre al limite dei rami il branch index si riversa nel branch_index della prossima generazione. È possibile impostare diferse sideKey e modalità del canale tra le subcatene (subchains).

10 chain fork

Snapshot

Il messaggio mascherato è memorizzato in signatureFragment delle transazioni. Pertanto, dopo lo snapshot, che elimina tutte le transazioni e gli indirizzi a saldo zero, tutti i MAM che hanno preceduto lo snapshot vengono eliminati.

Per evitare che ciò avvenga, i MAM vengono memorizzati in Permanode, che non esegono snapshop. Sebbene un permanode richieda spazio di archiviazione, larghezza di banda e alta velocità, attualmente è in esecuzione senza incentivi finanziari. La nostra comunità deve discutere su come l’infrastruttura IOTA dovrebbe essere mantenuta ed essere premiata per sostenere la sua stabilizzazione.

Riferimenti

MAM JS Library: https://github.com/iotaledger/mam.client.js

IOTA github: https://github.com/iotaledger/iota.lib.js

Introducing MAM: https://blog.iota.org/introducing-masked-authenticated-messaging-e55c1822d50e


Sull’autore

@abmushi on twitter, Discord

Tradotto dal suo articolo originale in giapponese qui

Per donare ad abmushi:

BTC: 1ACGpgpAMgaAKbGpPq2sDa467MnRNdW4wX

IOTA: G9XNCNYYHRKNPKLXFKUSINZ9OIAQGSNGJVODC9TNWQMILXZH9PNHXDGNEUFLEQNNVJUCIWWKZBTJLDXAYOZHZEZSN9

Il testo originale in lingua inglese si trova qui: https://medium.com/@abmushi/iota-mam-eloquently-explained-d7505863b413


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.