One of the “qualities” of blockchain technology (and also one of the main causes of its disruptive advent on the global technological scene) is undoubtedly immutability. Not surprisingly, a tool that can guarantee the integrity of data and prevent their fraudulent and unauthorized alterations (or deletions) arouse increasing enthusiasm. However, we have to deal with the GDPR and the right to be forgotten.
The subect becomes particularly relevant in the context of permissioned blockchains, precisely because, being non-public distributed ledgers, they seem to be the most suitable for handling sensitive data.
However, the fact that permissioned blockchains, by their nature, limit access only to authorized parties (with consequent restriction of the usability of sensitive data), does not solve the problem of the right to be forgotten. The characteristic “immutability” of the information, in fact, remains: data entered on a distributed register theoretically has eternal life, and we certainly cannot rely on the good faith of the subjects legitimately authorized to access the channel: in case of changed circumstances or of the loss of the trust relationship between the stakeholders, they would still be able, for example, to transfer a copy of the information to third parties.
To overcome this drawback, one of the solutions considered to be the most reliable up to now (especially for the management of highly sensitive data such as health data) consists in continuing to store raw data off-chain, entering on blockchain only the corresponding hashes , arranged in a tree structure culminating in a root hash, a sort of synthesis of the hashes processed in a given “round”. It is clear that the off-chain data can thus be eliminated at any time at the request of the interested person, in full compliance with the GDPR. It is equally true, however, that, by keeping the information out of the blockchain, the verification of the integrity of the data would be “manual” , ie carried out by the owner of the information (and of the corresponding hash), repeating the path from the single hash to the root hash and verifying that the result obtained corresponds to the root hash stored on blockchain. Although this solution has proved to be extremely functional for some types of operations (for example, to autonomously prove to an institution the authenticity of an obtained certification ), it could instead be rather complex (and certainly inconvenient) in other contexts, for example in the entrepreneurship field.
In this case, solutions such as Hyperledger Fabric are usually preferred. Hyperledger Fabric, due to its extreme modularity, guarantees high levels of “customization” of the network, according to the specific needs of its users. With regard to the removal of private data, Hyperledger Fabric provides the possibility of using a parameter called “blocktoLive“, which allows you to define how long data must stay on the private database in terms of blocks, before being “eliminated” by marking them as “obsolete” for the network.
However, this solution presents some partially unanswered questions:
– It is possible to decide in advance and in a generic way how long some data must be kept, but it is not yet perfectly clear how it is possible to eliminate information in real time at the request of a single interested person.
-The blocktolive parameter determines the “expiration” time of the data quantifying it in terms of new blocks added on the chain (eg: data will be deleted when an X number of blocks has been added), but it would be necessary to “translate” the conservation time of the information in terms of real time (it seems that this possibility is obtained by using an additional parameter called timeToLive)
– The architecture of private data in Fabric consists of four types of databases with different functions. It is not yet completely clear whether the data deletion function has been implemented for all four types of databases involved.
-Until now, these implementation attemps give no certainty about the fact that data can be “securely deleted” , as required by the GDPR.
Sources:
https://hyperledger-fabric.readthedocs.io/en/release-1.4/private_data_tutorial.html
For the italian version of the article: https://giovannacento.com/2019/05/20/garantire-il-diritto-alloblio-sulle-permissioned-blockchains-ksi-blockchain-e-hyperledger-fabric/
Giovanna CENTO PERSONAL BLOG 