By Marisa Agius and Mona Holocher, students at the Internet Law Clinic
Forget Me Nodes instead of Forget-Me-Nots: Blockchain, GDPR, and the Battle Over the Right to Be Forgotten
Part 2: How to Make the Immutable Erasable
In Part 1 of this two-part blog post, we discussed the challenges that blockchain technology creates for data privacy within the context of the European data privacy protection framework, specifically the General Data Protection Regulation (‘GDPR’). While this analysis highlighted several points of friction between blockchain technology (particularly with permissionless blockchains) and compliance with the GDPR, our aim was to present an overview of specific issues. This second part then aims to provide some practical recommendations for how the industry can ensure that blockchain technology aligns more closely with EU data privacy requirements, in particular, the ‘right to be forgotten’. We also provide some suggestions for users to better safeguard their personal data from ending up on a blockchain.
Data protection goes beyond simple security measures, such as avoiding sticky notes with passwords. Protecting personal data is a shared responsibility for all parties entrusted with its collection, processing and storage. Within blockchain environments, this includes developers who design the infrastructure, service providers who operate or integrate blockchain-based solutions (such as financial institutions adopting third-party chains), and network participants (i.e., nodes). To remain competitive while adhering to data privacy requirements such as the GDPR, businesses must proactively address the challenges posed by both existing and emerging blockchain technologies.
In particular, and as we pointed out in Part 1, deleting personal data stored on the blockchain is difficult or even impossible. This causes a conflict with the ‘right to be forgotten’ enshrined in Article 17 of the GDPR. While the right to be forgotten does not necessarily require the deletion of data, the person who is in charge of processing the data (the so-called data controller) must ensure the data cannot be accessed anymore (e.g., by anonymising the data).
Recommendations for the Industry
The following recommendations aim to provide an overview of what developers could do to better protect our personal data.
Overall, industry should ensure in the design phase of blockchain technology that personal data stored on chain can be rendered anonymous upon request. Integrating privacy principles early in the development process promotes regulatory compliance and enhances user trust and system resilience.
1. Off-Chain storage and On-Chain Hashes
One practical solution is to store only a cryptographic hash of personal data on-chain, while the actual data resides in a traditional database that is off-chain. A hash function is a mathematical function that is transformed into an output value of fixed length after being fed an input value. While hashing does not make data fully anonymous, it reduces the probability of identification. Deletion of personal data can then be achieved by erasing the off-chain content. Ideally, the cryptographic hash can only be reversed by the data subject, although some residual risk always exists. Therefore, it reduces the probability of identification and deletion becomes feasible by erasing the off-chain content.
2. Chameleon Hashes
The use of chameleon hash function is another solution that enables a party with the right cryptographic key (the “trapdoor”) to modify block data without changing the block’s hash. This enables selective redaction or updating of data on-chain while maintaining the chain’s integrity, which could reconcile blockchain immutability with the GDPR requirements.
3. Encryption Key
Similarly to the use of hashes, data could be encrypted before being added to the blockchain. Only the holder of the encryption key can then access the actual data; by encrypting personal data, it becomes inaccessible to third parties. As a result, the stored encryption would not allow third parties to identify it to the data subject.
Deletion of this data could be easily managed by destruction of the encryption key, rendering the data unintelligible. Users and controllers should assume that encrypted data may persist indefinitely on-chain, making strong encryption standards and robust key-management practices.
4. Zero-Knowledge Proof
Zero-Knowledge proofs are cryptographic protocols that allow verification of a statement without revealing the underlying data. Thereby, one party can demonstrate to another party that a statement is true without revealing any information beyond the validity of the statement itself. Operating on a true/false principle, Zero-Knowledge proofs ensure that only the correctness of a claim is revealed, but nothing about the data is used to support it. This technique enables blockchain networks to confirm a transaction has occurred without disclosing the transaction amount or originator.
5. Pruning
Pruning allows for data on the chain to be deleted as soon as it is no longer needed. Nodes can discard certain parts of the blockchain while only retaining the essential information required for validation and consensus. By enabling data minimisation, pruning supports GDPR compliance. Although pruning does not guarantee full deletion, with a possibility of some hashed references remaining accessible, it substantially limits the amount of recoverable personal information. Because blockchain data is replicated across all participating nodes globally, any effective erasure mechanism must render the data permanently inaccessible across every copy of the chain, not merely the originating node. Pruning reduces but does not eliminate this challenge.
Recommendations for Users
While most blockchain systems are built by developers and regulated by lawmakers, everyday users still have agency especially when it comes to protecting their own personal data. Here's what you can do:
1. Think Before You Upload
Your personal data could end up on a blockchain with no recourse to remove it. Never put sensitive personal information (like IDs, addresses, medical info, or financial data) directly on-chain. Even if a platform says it's secure, assume it cannot be deleted later.
2. Ask About Off-Chain Storage
When using a blockchain-based service (like a crypto wallet, DeFi app, or NFT platform), check whether your personal data is stored off-chain. If it’s not clear, ask or read the privacy policy.
3. Use Privacy-Preserving Platforms
Some newer projects use off-chain storage or chameleon hash functions to allow data edits or deletions. Choose services that follow privacy-by-design principles and are transparent about their compliance with GDPR and/or Australian privacy laws.
4. Exercise Your Rights
If your personal data has been collected by a blockchain platform and you have the right to request deletion or correction of that data, for example under the EU GDPR, exercise your rights. If your data has been collected by a blockchain platform:
- Contact the data controller
- Ask where your data is stored (on-chain or off-chain)
- Request erasure where applicable
Even if the platform says it’s “decentralised,” it might still have off-chain records that can be deleted.
6. Support Better Policy
As governments around the world (including Australia) consider stronger digital rights, your voice matters. Support laws that give individuals more control over their data, including the right to be forgotten.
Conclusion: Can Privacy and Blockchain Coexist?
While blockchain systems are built on the principles of immutability, the idea of strict, absolute immutability is being increasingly revisited. Emerging techniques such as encryption and off-chain storage offer stronger privacy protection, however blockchain systems still need to evolve to meet global compliance standards. Privacy frameworks, including the GDPR, shape both blockchain design and development, requiring developers to build these technologies with compliance considerations at the forefront (e.g., the need for effective removal or anonymisation of personal data) rather than as an afterthought.