ZKP could help resolve blockchain tensions with GDPR

Europe commissioned a new law called GDPR in 2018. It gives EU citizens control over who collects their personal data and how it’s handled. The pop-ups on websites seeking permission to gather and access your data result from the compliance need the act has imposed. Companies globally (if interacting with EU citizens) are subject to GDPR rules with onerous fines for non-compliance. GDPR definitions were clear on data protection until blockchains became mainstream, and a few use cases challenge the boundaries of technology and regulation.

Companies storing your data are called data controllers, and those that work with your data are called data processors. The data controller is usually also the data processor, but they could be different entities. The data controller is the entity responsible for GDPR compliance and if the personal data of EU citizens are involved, including for non-EU companies (e.g., Microsoft, Meta, etc.).

GDPR definitions of personal data

GDPR definitions of personal data are complicated. Other types of data are easier to define (e.g., age, gender, race, etc.) given they link these attributes directly to an individual. However, numbers like phone numbers, IP addresses, Bitcoin wallet addresses and credit card numbers, which can be indirectly linked to individuals via companies like telcos, crypto exchanges or banks, are also considered personal by GDPR.

It covers any information relating to an identified or identifiable natural person — making the line between pseudonymity and identification very thin. Blockchains store personal data like transaction history, making them subject to GDPR.

Problems: GDPR vs. blockchains

Data on blockchains are immutable and distributed with no centralized authority. However, they conflict with privacy and GDPR. There are three specific sections in GDPR at odds with blockchains.

Article 16 (right to correct data)

This covers the right to correct data someone has on you (you can change the inaccurate data and add missing data). Adding data on blockchains is easy, but the inherent immutability attribute of blockchains makes it impossible to change data.

Article 17 (right to be forgotten)

The same problem of blockchain immutability creates issues of being unable to delete your data from the chain, making GDPR compliance impossible. Blockchains forget nothing.

Article 18 (prevent data usage by companies)

If data is wrong or unlawfully collected, GDPR lets you prevent companies from using this data. Most blockchains cannot use your data for any intent, which also means they may not process the data by GDPR rules either, making things challenging.

Range of sub-optimal solutions

Join the community where you can transform the future. Cointelegraph Innovation Circle brings blockchain technology leaders together to connect, collaborate and publish. Apply today

A range of options have been proposed to discuss these issues; some were impractical, commercially unviable or negated the advantages of using public blockchains.

Encryption

Encrypting personal data before storing it on the blockchain was an option proposed in the early days. This means that only the person or entity with the decryption key can do anything with the data. The person or entity with the keys has absolute power to add, change and delete data, creating a “trust” issue. Others have made arguments against this solution stating that it is only a matter of time before encryptions can be broken, revealing this data as computing power gets faster and cheaper.

Permissioned or private blockchains

Everyone can see the data stored on public blockchains and add to it; private blockchains are access controlled and restricted to a few parties. This can help follow Article 18 and who can process the data, but it still has the immutable properties of blockchains unable to follow Articles 16 and 17.

Hashing and off-chain

Storing personal data off-chain with read-and-write access, such as with a secure server, and storing a reference to that data like a pointer is a common solution deployed for blockchain use cases not involving GDPR or personal data. This pointer is created by making a digital fingerprint of the data using a one-way hash function and storing it on-chain. A hash can verify the integrity of files on the centralized server, ensuring that no one has tampered with it. Secondly, hashes are one way you can create a hash of a piece of data, but you cannot take that hash and recreate the original data.

The right to be forgotten can be executed by removing the actual data from the server, rendering the hash useless and pointing to nothing. While this solution is accepted and works for most blockchain use cases where personal data is not involved, it poses challenges where personal data comes into play (e.g., marketing, DeFi, loyalty, etc.).

According to GDPR, even though a hash appears to be a string of random characters, it qualifies as personal data as it’s linked to the data on the server. The hash solution is also not perfect because blockchains are supposed to be decentralized and this adds a centralization vector.

Optimal solutions

Zero-knowledge proofs (ZKP)

ZKP technologies allow proof without revealing the underlying data. On blockchains, one can verify a cryptocurrency transaction without revealing the amount or destination of the transfer. Zcash protocol uses this. ZKP enables minimal transmission and storage of personal data while addressing GDPR compliance.

Hybrid blockchain

The patterns of cloud adoption reveal that blockchain may be on a path to a hybrid configuration. This means the private data remains closed and the public data is open. These implementations come at a higher cost and still require a privacy layer like ZKP but satisfy GDPR optimally.

Liability ambiguity

Blockchains create legal conundrums as the law states that the data controller (storer of data) is responsible for most of the legal compliance, but no one entity controls the blockchain. There are different participants on the blockchain.

Everyone cannot be liable because they do not control what others store on the blockchain. Block validators/creators cannot be held accountable because they might not know whether the data is personal data or not. Protocol developers cannot be held liable for GDPR compliance given they only produce the tools that are a means.

Given the participants, their roles and GDPR definitions, there is some work to do.  

The information provided here is not legal advice and does not purport to be a substitute for the advice of counsel on any specific matter. For legal advice, you should consult with an attorney concerning your specific situation.

Nitin Kumar is a growth CEO and co-founder at zblocks. He is a recognized leader, author, former consulting partner and VC investor.

This article was published through Cointelegraph Innovation Circle, a vetted organization of senior executives and experts in the blockchain technology industry who are building the future through the power of connections, collaboration and thought leadership. Opinions expressed do not necessarily reflect those of Cointelegraph.

Learn more about Cointelegraph Innovation Circle and see if you qualify to join