Algorand and Right To Be Forgotten on Blockchain
Right To Be Forgotten (RTBF) is a right that anyone can exercise as per the regulations issued by the European Union and some other countries. It means that personal and transactional data that is shared in the open network (to an extent but not completely), if the owner wants — he can request the same to be removed from permanent records.
RTBF applies to personal data only but can extend to any piece of data that can be used to identify the data subject. It is possible to get data removed from central databases (if there are no multiple records available) easily but when one wants to remove data from the internet or search engines, it gets a bit tricky due to the multiple ways in which the records are searched, stored and downloaded on the internet. There are restrictions on what constitutes a valid RTBF request which is determined by whether the request is for personal data or non-personal data which is available as a public/legal record.
Is RTBF possible on blockchain
When thinking about blockchain, which has inherent features of immutability, security and transparency, it becomes evident that deleting past records, to adhere to the RTBF request, from the blockchain cannot be done without disrupting the chain completely. Or can it?
In essence, this may only be true for legacy blockchain systems due to its consensus protocol making its current transactions dependent on past transactions.
On Balanced Blockchains, blockchains in which present transaction validation doesn’t depend on past transactions rather just the balance recorded, as balances capture essential information rather than personal information and balances can be maintained even if all past specific records are erased; complying with an RTBF for payment transaction related data is possible but when the same request is made for personal data it gets difficult without modifying the block structure or breaking the blockchain itself.
How does Algorand tackle it?
The short answer — by modifying its block structure! If other blockchains modify their structure, they can do it too.
In the new envisioned block structure, the erasable and non-erasable parts are stored separately (the hash of any data is never erased) thereby modifying the traditional structure of the blocks and transactions. In practicality, RTBF requests are more difficult to be executed for data transactions than for payment transactions as data itself is a broad category. But, in due time for a truly decentralized, permissionless blockchain ecosystem; RTBF requests for personal data have to be worked out.
Considering only personal data privacy scenarios, there are two important aspects to store the data properly to allow RTBF requests to be entertained. They are:
a. Storage of data with consent request
b. Proper tagging of data as per erasable and non-erasable classifications
A decentralized blockchain such as Algorand, functions due to 2 important categories of users:
a. The consensus participants → Primarily validators
b. Information Service Providers (ISPs) → Enablers to access stored information who cannot store the information and enablers to join the consensus protocol to obtain information needed
Handling an RTBF request with ease and security is something not possible on multiple blockchains but Algorand enables ISPs to answer with a short and easy process, based on the unambiguous genesis block, to verify proof. Authorities can cross check whether the RTBF request has been executed or whether the ISP is RTBF compliant by checking whether it returns the information that had been requested to be forgotten but verifying if it still stores in some form is tough. The honest ISPs of Algorand will not merely abstain from providing information that has been requested to be forgotten but will actually delete/erase the information from the chain without any glitches or changes in the overall functionality of the chain. Of course, de-linked pages and pages stored offline by users cannot be erased. It is not an RTBF requirement either.
It is a given that not all requests for RTBF can be accommodated by any blockchain, thus the following points become imperative for the blockchains:
Ease of Usage: A clear communication describing which details fall under the RTBF category and which the blockchain can accept and execute. With the fast and swift Atomic transfer characteristics, Algorand guarantees it
Forward Compatibility: Any blockchain can become RTBF compliant by switching to Algorand’s transaction and block structure, for now (though it is still a work in progress).
Partial Adoption: Algorand’s transaction and block structure ensures honest ISPs work in a RTBF compliant manner and dishonest ones can be easily identified.
Concluding thoughts
By design, Algorand enables and encourages users and developers alike to work with the RTBF. Trust and transparency provided by a public and truly decentralized blockchain are benefits which are to be provided by all blockchains in addition to working with legislators to help enforce the RTBF wherever possible.
