(For the english version: https://giovannacento.com/2019/05/20/the-right-to-be-forgotten-in-permissioned-blockchains-ksi-blockchain-and-hyperledger-fabric/ )

Una delle “qualità” della tecnologia blockchain (ed anche una delle principali cause del suo avvento così dirompente sul panorama tecnologico mondiale) è senza dubbio l’immutabilità. Non sorprende affatto che uno strumento in grado di garantire l’integrità dei dati e di prevenire fraudolente e non autorizzate alterazioni ( o eliminazioni)  degli stessi susciti crescente entusiasmo. Tuttavia, c’è da fare i conti con il GDPR e con il diritto all’oblio.

Il tema diventa particolarmente rilevante nell’ambito delle permissioned blockchains, proprio perché, trattandosi di registri distribuiti non pubblici, sembrano essere i più adatti per la gestione di dati sensibili.

Tuttavia, il fatto che le permissioned blockchains, per loro natura, limitino l’accesso ai soli soggetti autorizzati (con conseguente restrizione della fruibilità dei dati sensibili), non risolve il problema del diritto all’oblio. La caratteristica “immutabilità” delle informazioni, infatti, permane: i dati immessi su un registro distribuito godono teoricamente di vita eterna, e non si può certo fare affidamento sulla buona fede dei soggetti legittimamente autorizzati all’accesso che, con il mutare delle circostanze o con il venir meno del rapporto di fiducia fra le parti, sarebbero comunque in grado, ad esempio, di cedere una copia delle informazioni a terzi.

Per ovviare a questo inconveniente, una delle soluzioni ritenute fino ad adesso più affidabili ( soprattutto per la gestione di dati altamente sensibili come quelli sanitari) consiste nel continuare a conservare le informazioni off-chain, immettendo su blockchain soltanto i corrispondenti hashes, sistemati all’interno di una struttura ad albero culminante in un root hash, un hash radice, una sorta di sintesi degli hashes elaborati in un determinato “round”. E’ chiaro che i dati off-chain possono essere in tal modo eliminati in qualsiasi momento su richiesta del soggetto interessato, in piena conformità al GDPR. E’ altrettanto vero, però, che, conservando le informazioni fuori dalla blockchain, la verifica sull’integrità dei dati sarebbe di tipo “manuale”, cioè effettuata dal titolare delle informazioni ( e del corrispondente hash), ripetendo il percorso dal singolo hash all’hash radice e verificando che il risultato ottenuto corrisponda al root hash conservato su blockchain. Sebbene questa soluzione si sia rivelata estremamente funzionale per alcune tipologie di operazioni ( ad esempio per provare autonomamente ad un’ente l’autenticità di una certificazione ottenuta), potrebbe invece risultare piuttosto complessa (e sicuramente scomoda) in altri contesti, ad esempio per quanto riguarda il mondo dell’imprenditoria e del business.

In questo caso vengono solitamente preferite soluzioni come Hyperledger Fabric che, per la sua estrema modulabilità, garantisce alti livelli di “personalizzazione” del network a seconda delle esigenze specifiche dei suoi utilizzatori.

Per quanto riguarda la rimozione dei dati privati, Hyperledger Fabric prevede la possibilità di utilizzare un parametro definito “blocktoLive”, che consente di definire per quanto tempo i dati debbano sostare sul database privato in termini di blocchi, per poi essere “eliminati” contrassegnandoli come “obsoleti” per il network.

Tuttavia, questa soluzione presenta alcuni quesiti parzialmente irrisolti:

-E’ possibile stabilire anticipatamente per quanto tempo alcuni dati debbano essere conservati, ma non è ancora perfettamente chiaro come sia possibile eliminare le informazioni in tempo reale su richiesta di un singolo soggetto interessato.

-Il parametro blocktolive determina il tempo di “scadenza” dei dati quantificandolo in termini di nuovi blocchi aggiunti sulla catena (es. : il dato verrà eliminato quando un numero X di blocchi sarà stato aggiunto), ma  sarebbe necessario tradurre il tempo di conservazione delle informazioni in termini di tempo reale ( pare che questa possibilità sia ottenuta utilizzando un parametro aggiuntivo denominato timeToLive)

-L’architettura dei dati privati in Fabric consta di quattro tipi di database con funzioni diverse. Non è ancora del tutto chiaro se la funzione di eliminazione dei dati sia stata implementa per tutte e quattro le tipologie di database coinvolti.

-Fino ad oggi, questo tipo di implementazione non fornisce certezze sul fatto che i dati possano essere eliminati in modo sicuro, come imposto dal GDPR.