La tecnologia dei distributed ledger è nata per permettere la creazione di reti di partecipanti, persone o istituzioni, coinvolti in un insieme di transazioni senza richiedere nessun tipo di trust a priori tra i partecipanti. Ogni transazione avviene direttamente tra due partecipanti, senza mediazione di terzi. Il fatto che una informazione inserita nella blockchain possa essere modificata solo a prezzo di un carico computazionale estremamente elevato e che sia possibile inserire una transazione non corretta solo quando si controlla almeno la metà più uno dei partecipanti alla rete, ha suggerito di utilizzare i distributed ledger come memoria permanente e affidabile in cui memorizzare informazioni di qualsiasi dimensione e formato, da cartelle cliniche a immagini, da transazioni economiche a schede elettorali. In questo caso le informazioni vengono associate a delle transazioni tra i vari appartenenti alla rete.
Le regole della blockchain
Esistono regole ben definite per decidere se una transazione è corretta. La mancanza di fiducia implica necessariamente la capacità di ogni partecipante di verificare la correttezza delle transazioni e l’impossibilità di utilizzare soluzioni centralizzate. Le transazioni tra i partecipanti vengono registrate in blocchi che formano una catena sequenziale, il registro o ledger, che è replicata a tutti i partecipanti. Una volta memorizzata in un blocco inserito nella catena, una transazione non può essere modificata o annullata. Complessivamente, il distributed ledger realizza un database replicato con un meccanismo di consistenza che permette di ottenere il consenso sull’ordine cronologico in cui sono avvenute certe transazioni. Possono esistere diversi meccanismi di consenso che vanno dalla proof-of-work alla proof-of-stake al practical byzantine fault tolerance. Ognuno di questi meccanismi ha complessità e costi, anche energetici, diversi e uno stesso ledger li può comporre per ottimizzare costi e prestazioni. Ad esempio, alcuni meccanismi di consenso sono molto robusti rispetto a sybil attack, ovvero alla creazione da parte di uno stesso partecipante di più identità per controllare il meccanismo di consenso. Esistono diversi distributed ledger, ad esempio ogni criptomoneta ha un proprio ledger con un meccanismo di consenso. La blockchain di Bitcoin è uno degli esempi più popolari di ledger in cui il meccanismo di consenso è la proof of work. Nella blockchain l’integrità delle informazioni inserite è garantita da meccanismi di hashing e di firma.
Utilizzare un distributed ledger come memoria permanente
La soluzione di memorizzare direttamente nel distributed ledger le informazioni di interesse non è generale né efficiente. Per provarlo, consideriamo le due soluzioni possibili:
- sviluppare un nuovo ledger,
- utilizzare un ledger pubblico già esistente.
Premettiamo alcune considerazioni ortogonali alla scelta della soluzione e relative a come memorizzare le informazioni.
Il distributed ledger è fondamentalmente una struttura dati che deve poter essere letta, ad esempio per verificare la correttezza delle transazioni, e replicata in sistemi di elaborazione autonomi e gestiti da persone e organizzazioni diverse. La replicazione garantisce una elevata affidabilità ed accessibilità delle informazioni. Ad esempio, alcuni distributed ledger di criptovalute sono stati utilizzati per conservare e diffondere documenti di gruppi di opposizione in paesi non democratici. Affidabilità, accessibilità e permanenza sono attributi importanti ma che possono entrare in contrasto con la necessità di poter concedere e revocare il diritto di accedere all’informazione.
Dati e privacy
La gestione dei diritti di accesso è spesso fondamentale e comunque decisiva nella scelta della soluzione di memorizzazione. Si considerino, ad esempio, dati personali protetti dalla GDPR, che non possono essere memorizzati in chiaro su un ledger, anche se privato, in quanto potrebbero farvi accesso soggetti non legittimati e non potrebbero essere cancellati, per esempio per rispettare il right to be forgotten o per altri diritti degli interessati. In generale, il diritto di operare sul ledger e verificare la correttezza delle transazioni deve essere distinto da quello di accedere alle informazioni associate alle transazioni.
Quindi, in generale, le informazioni dovranno essere memorizzate in modo cifrato in modo da comunicare la chiave di decifratura soltanto a chi può accedervi. Notiamo, inoltre, che l’impossibilità di modificare le informazioni memorizzate implica la necessità di utilizzare un meccanismo di gestione delle versioni per aggiornare le informazioni memorizzate. Si considerino, ad esempio, documenti quali certificati di residenza e simili. Ogni aggiornamento del documento deve provocare la memorizzazione della nuova versione in un blocco più recente del ledger.
Dove memorizzare le informazioni
Esaminiamo ora il problema di dove memorizzare le informazioni con questo tipo di tecnologia. Consideriamo inizialmente l’utilizzo di un ledger pubblico e supponiamo di usare quello di Bitcoin. In questo caso, vi sono due possibili soluzioni per memorizzare in un blocco altre informazioni oltre a quelle delle transazioni. Le informazioni per memorizzare una transazione non utilizzano 40 byte tra quelli dei record per ricordare una transazione che sono il tipo di dato elementare per costruire i blocchi della blockchain. Ricordando la possibilità di avere più destinatari di una transazione, alcune soluzioni propongono di individuare ulteriori byte utilizzando le posizioni riservate per codificare l’hash dei destinatari delle varie transazioni. Questa soluzione permette di aumentare lo spazio disponibile al costo di non poter riutilizzare le somme destinate ai vari destinatari della transazione.
Per ogni destinatario sono così disponibili ulteriori 32 byte. Qualsiasi soluzione si adotti, è evidente l’elevato numero di transazioni, e quindi di blocchi, necessari per memorizzare anche una quantità non elevata di dati. Ovviamente, la memorizzazione di dati quali immagini ad alta risoluzione o non comprimibili non può che peggiorare il problema.
Ovviamente, un ledger costruito ad hoc permette di associare a ogni transazione uno spazio di memoria adeguato. In questo caso lo svantaggio è il ridotto numero di nodi che verificano la correttezza della transazione. È quindi meno complesso raggiungere il controllo della metà più uno di questi nodi. Inoltre, abbiamo una maggiore omogeneità tra i nodi e quindi il rischio che una singola vulnerabilità permetta di attaccare con successo tutti i nodi.
Distributed ledger, l’integrazione di una memoria esterna
Verificata la maggior robustezza di un ledger pubblico è quindi necessario utilizzare un supporto di memoria alternativo per l’informazione I che si vuole memorizzare. Una possibile soluzione è quella ricordare in una transazione sul legder la coppia H(I), P(I) dove H(I) è un hash I e P(I) il puntatore all’informazione nel supporto alternativo. In questo modo, le garanzie di integrità della blockchain garantiscono di poter rilevare ogni eventuale modifica ad I nel supporto di memoria secondario. Se l’unico vincolo di interesse è quello della rilevazione di modifiche, la memorizzazione di H(I) nel ledger è una soluzione efficace. In questo caso, la bassa quantità di memoria che anche distributed ledger pubblici possono offrire non pone vincoli significativi.
La situazione cambia se interessa estendere anche alle informazioni memorizzate le proprietà di affidabilità e accessibilità offerte da un distributed ledger. È quindi opportuno utilizzare un approccio p2p in modo da utilizzare un supporto di memoria che garantisca queste proprietà a partire dalla condivisione delle informazioni tra un elevato numero di nodi fisici. Un supporto particolarmente interessante è InterPlanetary File System, un file system distribuito che ambisce a fondere idee di successo da precedenti sistemi peer-to-peer come DHTs, BitTorrent, Git ed SFS. L’innovazione che IPFS vuole portare è quella di semplificare e integrare tecnologie già validate in un unico sistema, in modo coerente. IPFS offre una nuova piattaforma per lo sviluppo di applicazioni e un nuovo sistema per distribuire e gestire le versioni di insiemi di dati. IPFS è peer-to-peer: nessun nodo è privilegiato e i nodi IPFS memorizzano oggetti IPFS localmente.
Come è organizzato un protocollo IPFS
I nodi sono connessi tra di loro e trasferiscono oggetti che rappresentano file e altre strutture dati. Il protocollo IPFS è organizzato come uno stack di protocolli, ognuno responsabile di diverse funzioni che vanno dal routing al naming alla gestione delle identità. I file IPFS non possono essere modificati, visto che il loro identificatore viene generato in base al loro contenuto, ma possono esistere versioni diverse dello stesso file. Utilizzando il meccanismo di gestione delle versioni è possibile realizzare un mutable file system che offra una interfaccia per aggiornare i vari file. È inoltre possibile definire dei cluster di peer per replicare file tra i peer del cluster in modo da garantire la disponibilità di un file anche in presenza di guasti permanenti o temporanei. Sottolineiamo come il numero di copie di un file in IPFS, che dipende dalla dimensione del cluster, sia del tutto indipendente dal numero di copie del distributed ledger, che dipende dal numero di miner o di verificatori.
Conclusioni
È evidente la necessità di integrare in un unico sistema un distributed ledger e un file system p2p. L’integrazione è necessaria, non avrebbe senso memorizzare hash di un file in un distributed ledger e il file in un file system tradizionale. Solo un file system p2p permette di ottenere le prestazioni di interesse in termini di affidabilità e disponibilità dei file. Queste prestazioni dipendono però, sostanzialmente, dal file system p2p, quindi il ruolo che gioca il distributed ledger è limitato visto che le proprietà di immutabilità sono già garantite dal file system p2p. È significativo che IPFS contenga già meccanismi di base per distributed ledger. Una soluzione alternativa è di usare un insieme di file system tradizionali gestendo esplicitamente i problemi legati alla presenza di copie multiple, la cifratura dei file e la gestione delle chiavi.
La necessità di definire e implementare meccanismi per gestire le versioni, controllare gli accessi degli utenti e gestire le varie chiavi di cifratura coinvolte esistono anche quando si sviluppa un nuovo distributed ledger per la memorizzazione di informazioni diverse da quelle associate alle transazioni. Infatti un distributed ledger non offre come funzioni primitive dei meccanismi per affrontare questi problemi.
Riassumendo, possiamo dire che nella creazione di un sistema general purpose per la gestione di informazioni che garantisca la non modificabilità, la disponibilità e la confidenzialità un distributed ledger ha un ruolo limitato. Invece indubbiamente un distributed ledger, anche pubblico, permette di semplificare notevolmente la verifica che alcune informazioni non siano state modificate. Un punto che vale comunque la pena di ricordare è la perdita della governance delle informazioni che si vanno a inserire in un distributed ledger pubblico. Infatti, se e quando le informazioni verranno inserite nella blockchain dipende totalmente dai vari miner e dagli incentivi che si offrono. Per applicazioni commerciali questo non è ormai più un problema come testimoniato dal ricorso sempre più pesante all’outsourcing anche in paesi non comunitari. Invece potrebbe, o dovrebbe, essere un problema per la gestione dei dati delle pubbliche amministrazioni o comunque soggetti a vincoli legislativi o di riservatezza.
Riferimenti
- Benet, Juan. “Ipfs-content addressed, versioned, p2p file system.”, arXiv preprint arXiv:1407.3561(2014).
- Mingxiao, D., Xiaofeng, M., Zhe, Z., Xiangwei, W., & Qijun, C. (2017, October). A review on consensus algorithm of blockchain. In 2017 IEEE international conference on systems, man, and cybernetics (SMC) (pp. 2567-2572). IEEE.
- Kumar, R., & Tripathi, R. (2019, November). Implementation of distributed file storage and access framework using IPFS and Blockchain. In 2019 Fifth International Conference on Image Information Processing (ICIIP) (pp. 246-251). IEEE.
