Irony of Trust - Blockchain

IRONY OF TRUST: BLOCKCHAINS
Ridhish Rajvanshi1
1
Ridhish Rajvanshi is an LL.M. candidate at World Trade Institute, Bern pursuing LL.M. in International Trade
and Investment Law with Diploma of Advance Studies in International and Economic Law. This article was
written in December 2018 and has not been updated since. Any comments and feedback are welcome. He can be
reached at ridhish16@live.com

~ Irony of Trust: Blockchains by Ridhish Rajvanshi ~
~ PAGE | ii ~
TABLE OF CONTENTS
A. Introduction..........................................................................................................................1
B. Distributive Ledger Technology...........................................................................................1
Ledger System: Centralised vs. Decentralised ..................................................................2
How a DLT functions...........................................................................................................2
Authentication......................................................................................................................3
Types of Blockchain.............................................................................................................4
C. General Data Protection Regulation (‘gdpr’) .....................................................................5
Potential conflict between GDRP and DLT.......................................................................5
Potential GDPR provisions applicable on DLT ................................................................5
1. Freedom to do business vs. Protection of Personal Data (Recital 4, GDPR)...............5
2. Data Sovereignty (Recital 6 and 7, GDPR)..................................................................6
3. Material Scope (Art. 2, GDPR)....................................................................................6
4. Territorial Scope (Art.3, GDPR) ..................................................................................7
5. Data Localisation (Art. 44-50, GDPR).........................................................................7
6. Personal data and data subject (Art.5(1), GDPR) ........................................................8
7. Controller (Art. 4(7), GDPR) .......................................................................................9
8. Processor (Art. 4(8), GDPR)......................................................................................10
9. Supervisory authority (Art. 4 (21), GDPR)................................................................10
10.Six privacy principles (Art. 5, GDPR) .......................................................................11
11.The right to access (Art. 15, GDPR) ..........................................................................12
12.The right to be forgotten (Art.17, GDPR)..................................................................12
13.Data Portability (Art. 20, GDPR)...............................................................................13
14.Notification of personal data breach (Art. 33(1), GDPR) ..........................................13
15.General conditions for imposing administrative fines (Art.83(5), GDPR). ...............13
16.Data protection by design and by default (Recital 78, Art. 25, GDPR).....................13
17.Consent (Recital 51, Art. 6-9 GDPR).........................................................................14
D. Conclusion..........................................................................................................................14
E. Bibliography ........................................................................................................................iv
F. Annex – 1: Summary of GDPR and DLT.........................................................................viii
G. Annex – 2: GDPR applicability with Public, Consortium and Private Dlt ........................x

~ PAGE | 1 ~
A. INTRODUCTION
Blockchain, as we know today is generally used to refer to the Distributive Ledger
Technology (DLT).2
However, blockchain is only a subset of DLT. In DLT, data is usually
grouped into blocks that, upon reaching a certain size, are chained to the existing ledger through
a hashing process. The hashing process arranges data in a chronological manner that makes it
difficult to tamper with information without altering subsequent blocks.3
This essay analyses what blockchain is by determining the distinction between centralised
and decentralised ledger system. This is followed by assessing the functioning and the
authentication process involved. The section is concluded by the discussion about types of
blockchains. The terms DLT and blockchain are used interchangeably. In the third section, we
look at the potential conflict that may invoke the GDPR with respect to the new distributive
technology. Next, the relevant provisions are analysed on their applicability with the
technology. The essay is concluded with certain observations on how GDPR and blockchain
may or may not co-exist. Lastly, two annexes has been formulated to have a more precise and
concise understanding of these provisions and which type of distributive ledger system should
be preferred to be compliant with GDPR, respectively.
B. DISTRIBUTIVE LEDGER TECHNOLOGY
This new technology, which has gained significance in the 21st
century, has various
definitions and descriptions. There exists no single definition of this term. A block in the
network consist of three parts: data, hash and hash of previous blocks. And the chain of these
linked blocks, is called the blockchain containing the information that you transact or share.
After literature review, broadly, central elements that qualify a technology as blockchain are –
an electronic, decentralised, immutable transaction ledger4
that provides cryptographic
verification (usually through hash function). The transactions done in a blockchain are recorded
2
DLT generally refers to the distributed, decentralised ledger aspect of blockchain technology. With DLT, a
ledger can be maintained, secured, and authenticated by relying on a network of computers (decentralised) rather
than a single, centralised authority. As a result, copies of the ledger can be kept and maintained by many
individuals or organisations (distributed) and no copy is the master or lead copy. see, Mark Fenwick, Wulf A Kaal
and Erik PM Vermeulen, ‘Legal Education in the Blockchain Revolution’ [2017] SSRN Electronic Journal
<http://www.ssrn.com/abstract=2939127> accessed 16 December 2018.
3
Whereas data stored on a blockchain is often described as ‘immutable’, this is not quite the case as such
information can be modified in exceptional circumstances through human intervention, which however requires
the collusion between a majority of the network’s nodes, this has been referred as 51% attack. see. M Finck,
‘Blockchains and Data Protection in the European Union’ (2018) 4 European Data Protection Law Review 17.
4
A ledger is a record of accounts.

~ PAGE | 2 ~
and time-stamped. The information once added into a blockchain cannot be modified, and
allows to look at the ledger of information added. The transactions are recorded, shared and
verified on a peer-to-peer basis by anyone with the appropriate permissions.5
Ledger System: Centralised vs. Decentralised
Blockchain removes the intermediary(-ies)
in transactions involved and makes it a peer to
peer system. It shifts the trust from a
centralised authority or an organisation to a set
of peers, making the transaction decentralised6
.
The figure in left depicts a decentralised distributive system wherein information can transfer
from one peer (called node) to another directly. The one on right depicts a centralised
distributive system that requires information to pass through a centralised system for transfer
from one peer to another. In the centralised system, a ledger is created and the transaction is
recorded in the centralised server / system, where the original copy is stored. On the other hand,
in the distributive ledger system there is no original copy. The copies of the transaction are
shared with all the participating peers, who either mine7
or validate8
the transaction, and save
it as a new block in the blockchain.
How a DLT functions
Thus, DLT functions like any other transaction or sharing of information between
individuals but is based on trust. The blockchain requires a sender, a receiver and peers for it
to function. The sender, broadcasts a block in the network having the data the individual is
transacting or sharing, which is mined or validated by the peers, confirming that the transaction
or information is accurate, truthful, and consistent thereby validating the block. The block
5
World Trade Organisation WTO, ‘World Trade Report 2018’ (World Trade Organisation 2018)
<https://www.wto.org/english/res_e/publications_e/world_trade_report18_e.pdf> accessed 16 December 2018;
Emmanuelle Ganne, Can Blockchain Revolutionize International Trade? (1st edn, WTO Publications 2018)
<https://www.wto.org/english/res_e/booksp_e/blockchainrev18_e.pdf>.
6
It runs on computers provided by volunteers around the world: there is no central database to hack.
7
With proof-of-work validation, network participants (known as miners) compete to add the next transaction
block to a blockchain by solving a complex cryptographic puzzle, thereby validating prior transactions in the
process and earning transaction fees for their work. see, ‘LIT-FebMar18-Feature-Blockchain.Pdf’
<https://www.steptoe.com/images/content/1/7/v3/171269/LIT-FebMar18-Feature-Blockchain.pdf> accessed 16
December 2018.
8
With proof-of-stake validation, network participants (known as validators) invest digital coins in the blockchain
network, representing their stake in the block. A validator’s chance of verifying a block is proportional to its stake
in the block. see ‘LIT-FebMar18-Feature-Blockchain.Pdf’ (n 6).

~ PAGE | 3 ~
broadcasted contains the data, chain of previous blocks hash and the new hash assigned to that
block when it was introduced in the network. The peers than using the computational power,
authenticate that the block is valid by verifying from the copy of previous blockchain ledger9
that the hash has not been tampered and confirms that transaction or information. The new hash
assigned to the block upon introduction is chained with the previous hash and it is added to the
chain, validating the blockchain. The structure permanently time-stamps and store exchanges
of value. If the block can’t be validated it will not be connected and is referred to as an ‘orphan block’.
Authentication
With DLT, authentication is achieved through cryptographic means and consensus10
. All
participants have access to the same, up-to-date ‘version of the truth’. No single user can
control it, which allows people who have no particular confidence in each other to collaborate
without having to rely on intermediaries, instead relying on the trusted outcome of the system.
The DLT users (peers) authenticate the transaction or information by solving cryptographic
puzzles involving one-way functions known as hashes.11
A cryptographic hash function
generates small digital fingerprints, each unique to the data set entered into the function,
allowing a quick comparison of large data sets and providing a secure way to verify that the
underlying data has not been altered.12
This is how consensus is achieved within the system
without having to perform a line-by-line comparison of each participant’s ledger. Without
needing to understand how cryptographic hash functions work, it is enough to understand that
there is only one possible output for any input data set.13
9
A blockchain is a kind of distributed ledger. It is “distributed” in that there is no master copy. Any participant in
the network can maintain an instantiation of the ledger, yet be confident it matches all the others. Venture capitalist
Albert Wenger calls blockchains logically centralised (there is only one ledger), but organisationally decentralised
(many entities maintain copies of that ledger). Computers directly participating in a blockchain network, often
called full nodes, are in constant communication to remain synchronised. Maintaining that synchronisation, called
consensus, is the hard part, because there is no canonical master copy. see, Kevin Werbach, ‘Trust, but Verify:
Why the Blockchain Needs the Law’500.
10
Consensus means that participants in a network have confidence that their ledgers are both accurate and
consistent. It affirms the integrity both of each individual transaction and of the ledger as a whole. It does so by
aggregating transactions together into blocks.
11
A hash function takes some input string (such as a document file) and turns it into an output string—the hash—
with a specified length. Although in theory multiple input strings could map to the same hash, cryptographic hash
spaces are sufficiently large that such “collisions” are infinitesimally rare. It is easy to compute the hash function
of any file. An input string will produce the same output string every time. However, there is no known way to go
from a hash back to the input string other than trial and error.
12
Board of Governors of the Federal Reserve System (U.S.) and others, ‘Distributed Ledger Technology in
Payments, Clearing, and Settlement’ (2016) 2016 Finance and Economics Discussion Series
<http://www.federalreserve.gov/econresdata/feds/2016/files/2016095pap.pdf> accessed 16 December 2018.
13
Board of Governors of the Federal Reserve System (U.S.) and others (n 14).

~ PAGE | 4 ~
Types of Blockchain
Having discussed how DLT works, it is necessary to discuss the three types of DLT before
we address the issue concerning how either DLT or GDPR affects each other: public,
consortium and private. A public DLT14
is one which is accessible by all. It is a fully
decentralised and uncontrolled networks with no access permission required, anyone can view
the ledger and participate in the consensus process to determine which transaction blocks are
added.15
On the other hand, a consortium DLT16
operates under the leadership of a group. The
consensus process for new transaction blocks is controlled by a fixed set of members, such as
a group of financial institutions where pre-existing trust is high.17
Lastly, for a private DLT18
the access permissions are tightly controlled, with rights to read or use the blockchain restricted
to certain individuals. The transaction speed of a privately run blockchain can be faster than
other blockchain solutions because there are fewer nodes on the chain and trust level is high.19
Further, DLT can be classified as permissioned or permissionless. The latter allows an open
participation in the DLT. Usually, public DLT are permissionless, anyone over the internet can
join in the network of the DLT. On the other hand, private DLT is permissioned, and the
consortium can sway between permissioned and permissionless DLT.
14
“[A] public blockchain is a blockchain that anyone in the world can read, anyone in the world can send
transactions to and expect to see them included if they are valid, and anyone in the world can participate in the
consensus process-the process for determining what blocks get added to the chain and what the current state is.
As a substitute for centralised or quasi-centralised trust, public blockchains are secured by cryptoeconomics-the
combination of economic incentives and cryptographic verification using mechanisms such as proof of work or
proof of stake, following a general principle that the degree to which someone can have an influence in the
consensus process is proportional to the quantity of economic resources that they can bring to bear. These
blockchains are generally considered to be “fully decentralised[.]”. see, Ethereum Foundation, ‘On Public and
Private Blockchains’ <https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/> accessed 16
December 2018.
15
‘Blockchain – The Legal Implications of Distributed Systems’ <https://www.lawsociety.org.uk/support-
services/documents/blockchain-legal-implications-law-society-horizon-report/>.
16
“[A] consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of
nodes; for example, one might imagine a consortium of 15 financial institutions, each of which operates a node
and of which 10 must sign every block in order for the block to be valid. The right to read the blockchain may be
public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks
being public together with an API that allows members of the public to make a limited number of queries and get
back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered “partially
decentralised[.]”, see, Foundation (n 16).
17
18
“[A] fully private blockchain is a blockchain where write permissions are kept centralised to one organisation.
Read permissions may be public or restricted to an arbitrary extent. Likely applications include database
management, auditing, etc [sic] internal to a single company, and so public readability may not be necessary in
many cases at all, though in other cases public auditability is desired.).” see, Foundation (n 16).
19

~ PAGE | 5 ~
C. GENERAL DATA PROTECTION REGULATION (‘GDPR’)
The GDPR came into effect on 25 May 2018, and is said to implement stricter restrictions
on the usage of data. Data protection and privacy are considered to be used in similar context,
but one can argue that data protection is rather a subset of privacy. This section focuses on the
effect of data protection regulation on blockchain, unless otherwise discussed in the context of
data privacy as whole.
Potential conflict between GDRP and DLT
The strain between the GDPR and DLT (decentralised databases) undeniably exposes a
conflict between two normative objectives of EU supranational law: fundamental rights (FR)
protection on the one hand, and the promotion of innovation on the other. While one may argue
for DLT to be disruptive in nature, decentralising business models, forms of human interaction
and markets, by transforming the technology and ease of doing business; but from a data
protection perspective, the rise of the DLT may not be transformative in protection of FR.
Whereas the GDPR was fashioned for a world where data is centrally collected, stored, and
processed, DLT decentralises these processes. With a paradigm shift of such radical contours,
we must enquire about the applicability of a legal framework constructed for a sphere of
centralisation to one of decentralisation.20
Any form of encrypted data can be subject to GDPR.
Even though DLT uses cryptographic means (cryptographically modified data stored on a
distributed ledger, in addition to public keys), it will fall within the scope of GDPR.
Potential GDPR provisions applicable on DLT
In this section, we have a look at various recitals, articles of GDPR and try to understand
the effect either may have on each other.
1. Freedom to do business vs. Protection of Personal Data (Recital 4, GDPR)
As discussed earlier, the GDPR tries to create a balance between the right to protect the
privacy of EU citizens and providing space for growth and innovation. This very recital states
that right to protection of personal data is not an absolute right. It is to be considered in balance
with other rights by the application of the principle of proportionality in case of conflict. The
DLT, is still in its innovation stage, which leaves the question on its impact unanswered.
20
Finck (n 2).

~ PAGE | 6 ~
The processing of personal data should be designed to serve mankind. The right to the protection of
personal data is not an absolute right: it must be considered in relation to its function in society and be
balanced against other fundamental rights, in accordance with the principle of proportionality. This
Regulation respects all fundamental rights […], in particular […] freedom to conduct a business […].21
However, the possible ground on which protection may prevail over DLT is that the recital
mentions ‘freedom to conduct business’. DLT as we know data is shared amongst peers, who
are not technically22
conducting a business. Therefore, only private DLT will have proportional
right of freedom to do business against the protection of personal data.
2. Data Sovereignty (Recital 6 and 7, GDPR)
The GDPR in its recital discusses how both, public and private entities autonomously
collect, store, process and monetise our data trails.23
This raises concerns on protection of
personal data of a natural person. One may see DLT as a saviour here, which promises
decentralisation for handling data and data sovereignty24
, because of which individual data
does not get concentrated only with few entities. Further, the GDPR acknowledges the data
sovereignty objective ensuring control of natural persons over their own personal data.25
The
DLT can be regarded as inconsistent with Recital 7, as in a public DLT, the data added to the
block is available for public access. This undermines the right of the natural person to have full
control over his/her data. This however, may be contained by using consortium or private DLT.
3. Material Scope (Art. 2, GDPR)
This article regards a direct application on the foundation of a DLT. As discussed earlier,
DLT is a system which is solely based on algorithms and computational power. Thus, it is
completely automated in nature. The DLT processes data (which may or may not be personal)
wholly by automated means, which may have little human intervention, and becomes part of a
filing system in form of series of sequential blocks. Therefore, DLT may fall within the material
scope of GDPR.
21
Recital 4, General Data Protection Regulation 2016 (2016/679).
22
A validator or miner, is investing his/her resources (time, energy, computing power, etc.) to validate the block
and in return receives a transaction costs, for solving the hash function. This can be regarded as business for the
individual as, he/she receives consideration for the service provided.
23
Recital 6, General Data Protection Regulation.
24
Data sovereignty, is a concept that focuses on giving individuals control over their personal data and allowing
them to share such information only with trusted parties. see, ‘Identity & Blockchain: The Road to Self Sovereign
Identity’ (BlockchainHub, 17 October 2017) <https://blockchainhub.net/blog/blog/decentralized-identity-
blockchain/> accessed 17 December 2018.
25

~ PAGE | 7 ~
4. Territorial Scope (Art.3, GDPR)
The article provides protection of personal data of its subjects even outside the territory of
the Union: “All personal data of all EU citizens are subject to comply to the GDPR. This means Non-EU
companies that aim to process personal data of EU citizens must abide by the GDPR.” It also covers those
organisations which do not process or analyse data in the EU, but outside of EU data subjects
i.e. where processing activities relate to either the offering of goods or services (paid or unpaid)
to a data subject based in the EU26
or where they monitor behaviour that takes place in the
Union.27
. Thus, the territorial scope of GDPR is applicable all around the globe for EU’s data
subjects. Where a controller not established in the EU processes personal data in a place where
Member State law applies by virtue of public international law, the GDPR also applies.28
DLT is a technology which is cross-border, transnational in nature having nodes from all
around the world. Thus, by virtue of the provision laid in the regulation, any or all nodes (peers)
are subject to GDPR for processing or validating any transaction concerning EU data subjects.
If one were to address each of these nodes, some of which may not be found29
in a single
jurisdiction, this would create two sets of problems. First, a large amount of nodes would need
to be contacted and compelled to comply, as opposed to a single controller in a data silo
scenario. Second, this may lead to forcing all nodes to stop running the blockchain software
where GDPR rights cannot be achieved through alternative means. This would result in a
situation where an entire blockchain would be taken down in one jurisdiction for non-
compliance with a single data subject’s rights, which may be considered disproportionate.
5. Data Localisation (Art. 44-50, GDPR)
The EU restricts transfer of data to third countries, unless met with specific conditions.
GDPR specifies “transfer of personal data which are undergoing processing or are intended for processing
after transfer to a third country or to an international organisation shall take place only if, subject to the other
provisions of this Regulation”.30
The conditions laid down require that the third country ensures an
adequate level of protection,31
provide appropriate safeguards, and on the condition that
26
Art. 3(2)(a), General Data Protection Regulation 2016 (2016/679).
27
Art. 3(2)(b), General Data Protection Regulation 2016 (2016/679).
28
Art. 3(3), General Data Protection Regulation 2016 (2016/679).
29
Through a ‘getaddr’ message, nodes are asked for information about known active peers. Ethernodes,
‘Ethernodes.Org - The Ethereum Node Explorer’ <https://www.ethernodes.org/network/1> accessed 16
December 2018.
30
Art. 44, General Data Protection Regulation 2016 (2016/679).
31

~ PAGE | 8 ~
enforceable data subject rights and effective legal remedies for data subjects are available,32
and binding corporate rules by supervisory authority in EU are ensured.33
DLT may have just one node in the EU, rest outside EU, it shall still be required to be
brought under the ambit of GDPR. It is clear from the regulation that unless specified, any
transfer of data to third country will be inconsistent with GDPR. This poses threat to the DLT,
which functions on anonymity of the nodes. In order to ensure that DLT runs, the nodes would
have to be identified, which fails the purpose of DLT. There is no centralised authority which
tracks database of where each node is located.
6. Personal data and data subject (Art.5(1), GDPR)
The GDPR states that the information is not personal data (or anonymised data) only if
there is no way imaginable to link it to a person, Pseudonymised data, on the other hand, is
data that cannot directly be re-identified. The article states that “‘personal data’ means any
information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person
is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an
identification number, location data, an online identifier or to one or more factors specific to the physical,
physiological, genetic, mental, economic, cultural or social identity of that natural person.”
The personal data definition specifically includes specific data types, such as biometric,
genetic and health information, as well as online identifiers. It does not extend any rights to
deceased persons. The regulation is applicable only to ‘identifiable person’ and/or ‘data
subject’.34
Two sets of data stored on DLT can potentially be defined as personal data for the
purposes of the GDPR; transactional data stored in the blocks and public keys. Data can be
stored on a DLT in three alternative fashions: plain text, in an encrypted form, or by hashing it
to the chain. GDPR, only limits its scope to personal data, rest all kind or form of data are non-
personal. Soon, there may exist no difference between personal and non-personal data due to
technological advancements in machine learning which over period of time will be able to
identify a person using non-personal data.
A plain text in DLT containing personal data shall fall within the scope of GDPR, as data
in plain text form and stored on the ledger is available for its peers to see and identify the person
with the data on the ledger. The data stored in encrypted form on DLT, may still fall under the
32
33
34

~ PAGE | 9 ~
scope of GDPR as with proper decryption keys, the encrypted stored in any type of blockchain,
can be accessed by any individual or firm and can identify the owner of that data. One might
think that the data hashed, will not be covered by GDPR as it entails a more robust privacy
protection, this is not true. The hashing process qualifies as a technique of pseudonymisation,
not anonymisation as it is still possible to link the dataset with the data subject.35
Art. 4(5) GDPR defines pseudonymisation as “the processing of personal data in such a manner
that the personal data can no longer be attributed to a specific data subject without the use of additional
information, provided that such additional information is kept separately and is subject to technical and
organizational measures to ensure that the personal data are not attributed to an identified or identifiable person”
A public key36
is data that ‘can no longer be attributed to a specific data subject’ unless it
is matched with ‘additional information’ such as a name or an address. Where these two sets
of information are combined, identification is plausible, explaining why public keys cannot
qualify as anonymous data. We have already seen that for data to qualify as being anonymous
identification must be irreversibly prevented.
7. Controller (Art. 4(7), GDPR)
The GDPR requires that the data which is stored, managed, operated or controlled for
processing, its purpose be determined by entities, solely or jointly. The article states that
“‘controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly
with others, determines the purposes and means of the processing of personal data; where the purposes and means
of such processing are determined by Union or Member State law, the controller or the specific criteria for its
nomination may be provided for by Union or Member State law;”
In a public DLT or even consortium DLT, the scope of Art. 4(7) will fail. The GDPR
requires a central controller who determines the purpose and means of processing personal
data. In this peer-to-peer network of DLT, this is a difficult task to entail who the controller is,
as all nodes (peers) who participate in the DLT, are controller. One may argue that if the DLT
is private it is possible to identify the individual controller, but it will fall under the scope of
GDPR based on the consideration that there is a central entity controlling the private DLT.
Another aspect to be looked at here is the principle of ‘joint controller’ or whether the group
of nodes (peers) in the DLT will qualify as joint controllers. One may argue that they will not
35
Article 29 Working Party, ‘Opinion 04/2014 on Anonymisation Techniques’ (2014) 0829/14/EN, 20.
36
Public keys are a string of letters and numbers that allows for the pseudonymous identification of a natural or
legal person for transactional or communication purposes. Keys are technically always numbers, derived from
large primes, that are however encoded alphanumerically to save space.

~ PAGE | 10 ~
as Art. 26 GDPR as they do not ‘jointly determine the purposes and means of processing’. This
requires a clear and transparent allocation of responsibilities.37
Nodes are free to determine
whether to join the unpermissioned ledger and in what function (i.e. as a full or lightweight
node). Nodes do not commonly determine applicable rules in the sense of Art. 26 GDPR; the
system is rather shaped by the nodes’ individual behaviour.
While a DLT is fuelled by the interplay of various nodes they don’t determine the
modalities of data processing of other nodes. Nodes (i) only see the encrypted or hashed version
of the data; and (ii) are unable to make any changes thereto. Nodes are thus decentralised
entities that cannot respond to the tasks the GDPR requires of centralised agents.
8. Processor (Art. 4(8), GDPR)
We know there are many organisations or entities that process personal information in the
name of a data controller. The article states that: “‘processor’ means a natural or legal person, public
authority, agency or other body which processes personal data on behalf of the controller;”
Data processing is essentially considered anything that is done to the data, including its
storage. An organisation or entity can be both data controller and processor. This point is
specifically important for any considerations of processors (third party service providers)
outside the EU, as the data controller could still be made responsible by a supervisory authority
in such a case. Thus, as discussed above, similar consideration as to that of a controller are
applicable on DLT with respect to the aspect of processor.
9. Supervisory authority (Art. 4 (21), GDPR)
DLT of any type (public, consortium, private) or form (permissioned, permissionless) is
privy to a centralised authority. However, the GDPR lays down the aspect that the data
governing in a jurisdiction will be supervised by a supervising authority, usually a government
organisation in each member state. The article states that: “‘supervisory authority’ means an
independent public authority which is established by a Member State pursuant to Article 51;” The question
lies before is the jurisdiction of this supervisory authority over any DLT. Now, one may argue
that jurisdiction is invoked as soon as there is a breach of the right of the data subject, but the
aspect lies, without any regulation that controls or on operation of a DLT and having
(technically) no controller, it is hard to determine whether it is within the scope of the GDPR.
37

~ PAGE | 11 ~
10. Six privacy principles (Art. 5, GDPR)
The general principles laid down under Art. 5 GDPR, can be said to be rendred inconsistent
in the context of DLT. The DLT processes data in the form of encrypted and hashing functions,
which, one may argue, is even though easily accessible (since blocks are available for public
to view) but may not be in an understandable information due to encryption, and for conversion
to more understandable standard, it is difficult to locate the private key.
Further, the purpose limitation for which data is collected, is neither limited not specified.
DLT does not have any contract or conditions for one to join the network and to either validate
or transact or share. The exception to this can be Smart Contracts.38
However, the above two
cannot be said true for private DLT.
(Article 5) are applied, namely 1) Lawfulness, fairness and transparency, 2) Purpose limitation, 3) Data
minimization, 4) Accuracy, 5) Storage limitation, 6) Integrity and confidentiality.
The concept of data minimisation is opposite to the data storage process in a DLT. We
discussed above that data once added to DLT cannot be modified easily and theoretically not
be removed.39
Distributed ledgers are by definition ever-growing creatures, which augment and
accumulate further data with each additional block. Another reflection of conflict between
GDPR and DLT lies that copy of each ledger is stored with each node in the blockchain, thereby
making it a more impossible task to reduce data and limit storage to what is relevant or required.
This has been true for big data as well.40
The GDPR requires that personal data be accurate and up to date.41
The question on
accuracy of data and to be updated to delete dormant data, comes in conflict with foundation
of DLT on which it is based. DLT carries around sequence of information from the very first
block to the newly added one and to modify or omit a data requires majority consensus from
nodes, which is a highly difficult task. Even though data subjects’ right under Art. 16 GDPR
includes the right to obtain rectification from the controller without undue delay, it is not
possible as the identification of nodes is almost impossible42
and data once added to blockchain
38
A blockchain can execute so called smart contracts, which are programs that replicate together with the
transactions, and every node executing them when receiving these transactions. smart contract would merely
contain the hash to said data rather than the data itself.
39
Blockchains can however perish if nodes stop running them, creating a whole range of different legal questions.
40
Tal Zarsky, ‘Incompatible: The GDPR in the Age of Big Data’ (2017) 47 Seton Hall Law Review
<https://scholarship.shu.edu/shlr/vol47/iss4/2>.
41
Art. 5(1)(b), General Data Protection Regulation 2016 (2016/679).
42
Reasons include that nodes may be online part time, may have closed ports, or frequently change IP addresses.

~ PAGE | 12 ~
cannot be deleted, rather, only modified by addition of subsequent modified information in the
block, which does not address the problem of ratification, modification or omission of data to
be accurate. Since, above is not possible, Art. 19 GDPR cannot be applied on DLT as well,
which requires controller to notify of the modification made.
One general principle that the DLT is consistent with GDPR is integrity and confidentiality,
which is the very basis why individuals around the globe trust this mechanism. This technology
ensures that integrity of the system is maintained with anonymity and providing confidence to
the users of this mechanism, wherein the validation is done by the peers, based on the fact that
the information added cannot be modified, thus making it more reliable.
11. The right to access (Art. 15, GDPR)
In a distributive ledger, since no controller or processor exist, it is nearly impossible to
provide a information to the data subject on how his/her data is being processed.43
Even though
the data subject may be able to go through the ledger tracking the sequence of the block to
identify his/her data, it cannot avail the information on the implementation of any safeguards,
if any, if his/her data was transferred to third country.44
Lastly, the DLT cannot provide copy
of their personal data undergoing processing from controllers, which would be equally
impossible where it has been cryptographically pseudonymised.45
12. The right to be forgotten (Art.17, GDPR)
One of the most powerful right provided to citizens under GDPR is rendered useless in
context of a DLT. As mentioned earlier, a DLT cannot erase data which is once added to the
ledger, thus making it impossible for DLT to be complied with GDPR.
The Right to be forgotten (RTBF) – a data subject has the right to have all related personal data erased.46
Only and if, all nodes are known, and the nodes stop using or validating or mining the
ledger, it will be as if that blockchain never existed and will in some way erase all related
personal data of any or all subjects. As regard to Art. 17(2) GDPR which mentions by usage of
available technology, the focus should be made here on other text from the article “the cost of
implementation, shall take reasonable steps, including technical measures”, thereby making it
43
44
45
46

~ PAGE | 13 ~
clear that right to be forgotten is not an absolute right and such remediation cannot be provided
as the technology is not available and it is not cost effective.
13. Data Portability (Art. 20, GDPR)
The right to data portability enshrines this objective in allowing a data subject to receive
data from a controller in order to give it to another controller. The right to data portability is an
emergent concept in EU law, the contours of which remain largely undefined. There is no
doubt, however, that it seeks to give data subjects more control over personal data. The Art. 29
Working Party for instance considers that the ‘primary aim of data portability is enhancing
individuals’ control over their personal data and making sure they play an active part in the
data ecosystem’.47
14. Notification of personal data breach (Art. 33(1), GDPR)
Since there exist no controller or processor, any notification about breach in storage,
maintenance, operation, processing of personal cannot be reported let alone within 72 hours.
15. General conditions for imposing administrative fines (Art.83(5), GDPR).
It is moreover unclear how fines will be calculated where a data controller on an
unpermissioned blockchain has failed to comply with data protection requirements given that
Art. 83 GDPR calculates them on the basis of annual worldwide turnover. Besides the
determination problem, further questions arise as to how ordinary nodes could ever pay the
hefty fines associated with the GDPR.
16. Data protection by design and by default (Recital 78, Art. 25, GDPR)
Data protection by design and by default is supposed to address privacy risks not only
as a legal restriction for processing personal data, but to meet privacy concerns in the early
stage of IT architecture design: When developing, designing, selecting and using applications,
services and products that are based on the processing of personal data or process personal data
to fulfil their task, producers of the products, services and applications should be encouraged
to take into account the right to data protection when developing and designing such products,
services and applications and, with due regard to the state of the art, to make sure that
controllers and processors are able to fulfil their data protection obligations.
47
Art. 29 Working Party, ‘Guidelines on the Right to Data Portability’ (2017) 16/EN WP 242, 4, fn 1.

~ PAGE | 14 ~
Art. 32 GDPR obliges data controllers to adopt appropriate technical and organisational
measures to ensure a level of security that is appropriate to the risk. Art. 25(2) GDPR however
also requires the controller to implement ‘appropriate technical and organizational measures for ensuring
that, by default, only personal data which are necessary for each specific purpose of the processing are
processed’. This obligation applies to the amount of personal data that is collected, the extent of
its processing as well as the period of storage and accessibility’
17. Consent (Recital 51, Art. 6-9 GDPR)
Consent is one of the most important principle for data protection. If a data subject has
given consent on how to use his/her data, the controller or processor can process or use in any
such way possible that it does not exceed the terms user has consented for.
DLT functions on consent. All nodes consent to participate in the ledger, transact or share,
validate the transaction, etc. However, since the copy of data is stored with all nodes, it is
difficult to differentiate when the use of data for which the user gave consent has exceeded.
But, with surety one may argue that once consent is provided, the scope of GDPR may not
apply as the user agreed for sharing of his data in the distributive ledger of which he was aware
of the risks, if any.
D. CONCLUSION
Distributed ledger technology allows participants to trust the outcome of a system without
trusting any individual participant. Yet trust implies uncertainty or vulnerability48
A blockchain
is a data storage system using sequentially signed blocks. Blockchains only designate the
variants of DLT that record data in packages (‘blocks’) that are hashed (‘chained’) to another.
It is an innovation that itself relies on three concepts: peer-to-peer networks, cryptography, and
distributed consensus using the resolution of a randomised mathematical riddle.
The problem to be solved by the blockchain is achieving and maintaining integrity in a
purely distributed peer-to-peer system that consists of an unknown number of peers with
unknown reliability and trustworthiness.49
Blockchains is both, a new technology for data
storage as well a novel variant of programmable platform and network that enables new
applications such as smart contracts.
48
Kevin Werbach, ‘Trust, but Verify: Why the Blockchain Needs the Law’ 494.
49
Daniel Drescher, Blockchain Basics: A Non-Technical Introduction in 25 Steps (Apress 2017).

~ PAGE | 15 ~
New technology does not just change how we apply existing regulations to new facts but
may also profoundly unsettle the foundations upon which existing regulation rests. In the eyes
of the GDPR, the onus of personal data stewardship rests on singular data controllers and
processors that handle singular data silos. The technological innovation that brought us
blockchains may however turn individuals into data sovereigns that can themselves, copy,
change, share, move their data.
It is now, in the still relatively early stages of blockchain technology, that appropriate data
protection safeguards must be implemented and strongly encouraged by regulators. While
some degree of transparency on a DLT is unavoidable to allow the network to reach
decentralised consensus, transparency is only unavoidable at the ledger’s most basic layer that
applies the consensus algorithm.
We discussed the potential conflict between GDPR and Blockchain, where GDPR
promotes trade and business at the same time balancing it with the rights of the individuals.
Blockchain being new age technology, has high potential scope changing the business
dynamics and way to trade. In this essay we discussed the potential violations of the GDPR by
Blockchain technology. It can be concluded that a public blockchain has most possibilities of
being inconsistent with GDPR compared to a private blockchain which can still be consistent
with GDPR based on the blockchain issuing organisation. The consortium blockchain will be
compliant to the extent more public blockchain characteristics are induced in its design.
One can fairly note the irony of trust in the case of distribute technology like blockchain
which induced trust within peers than a third-party intermediary. Blockchain has always been
talked about as more secure, safe and trusted technology in today’s time, but after reading the
analysis above you may question how much trust can you entrust in technology like blockchain
which does not provide protection of your privacy, data and individual rights and most of the
times does not even fall within the scope and coverage of GDPR.
Only time will reveal whether blockchains’ potential for data sovereignty is confirmed and
whether the interpretation of the EU’s data protection framework allows such models to
develop. In this context, those called upon to interpret and apply the GDPR should of course
not blindly trust DLTs to be by definition furthering of data sovereignty. It is rather also
regulators’ role to make sure that these considerations are incorporated into the software from
the beginning.

~ PAGE | iv ~
E. BIBLIOGRAPHY
1. Allen D and others, ‘Some Economic Consequences of the GDPR’ [2018] SSRN Electronic
Journal <https://www.ssrn.com/abstract=3160404> accessed 16 December 2018
2. Anderson K, ‘Can Blockchain Withstand Skepticism? An Inquiry’ (2018) 38 Information
Services & Use 153
3. April 10th and others, ‘The Rise of the Regulator May Lead to Trouble for the Blockchain’
(LSE Business Review, 10 April 2018) <http://blogs.lse.ac.uk/businessreview/2018/04/10/the-
rise-of-the-regulator-may-lead-to-trouble-for-the-blockchain/> accessed 16 December 2018
4. Bell TW, ‘Copyrights, Privacy, and the Blockchain’ (2015) 42 Ohio Northern University
Law Review 439
5. Berberich M and Steiner M, ‘Practitioner’s Corner ∙ Blockchain Technology and the GDPR
– How to Reconcile Privacy and Distributed Ledgers?’ (2016) 2 European Data Protection Law
Review 422
6. ‘Blockchain – The Legal Implications of Distributed Systems’
<https://www.lawsociety.org.uk/support-services/documents/blockchain-legal-implications-
law-society-horizon-report/>
7. ‘Blockchain Ensures Transparency in Personal Data Usage: Being Ready for the New EU
General Data Protection Regulation’ <https://ercim-news.ercim.eu/en110/special/blockchain-
ensures-transparency-in-personal-data-usage-being-ready-for-the-new-eu-general-data-
protection-regulation> accessed 16 December 2018
8. ‘Blockchain Revolution: Competing with the Internet of Value’ (Don Tapscott)
<http://dontapscott.com/speaking/blockchain-revolution/> accessed 16 December 2018
9. ‘Blockchains and The Internet of Value’ <https://www.versatek.com/blog/blockchain-the-
internet-of-value/> accessed 16 December 2018
10. Board of Governors of the Federal Reserve System (U.S.) and others, ‘Distributed Ledger
Technology in Payments, Clearing, and Settlement’ (2016) 2016 Finance and Economics
Discussion Series
<http://www.federalreserve.gov/econresdata/feds/2016/files/2016095pap.pdf> accessed 16
December 2018
11. ‘Data-Protection-Factsheet-Changes_en.Pdf’ <https://ec.europa.eu/commission/sites/beta-
political/files/data-protection-factsheet-changes_en.pdf> accessed 16 December 2018
12. ‘Decentralizing Everything with Ethereum’s Vitalik Buterin | Disrupt SF 2017 - YouTube’
<https://www.youtube.com/watch?v=WSN5BaCzsbo> accessed 16 December 2018
13. Dorri A and others, ‘Blockchain for IoT Security and Privacy: The Case Study of a Smart
Home’, 2017 IEEE International Conference on Pervasive Computing and Communications
Workshops (PerCom Workshops) (IEEE 2017)
<http://ieeexplore.ieee.org/document/7917634/> accessed 16 December 2018
14. Drescher D, Blockchain Basics: A Non-Technical Introduction in 25 Steps (Apress 2017)

~ PAGE | v ~
15. Efanov D and Roschin P, ‘The All-Pervasiveness of the Blockchain Technology’ (2018)
123 Procedia Computer Science 116
16. ‘Ethernodes.Org - The Ethereum Node Explorer’ <https://www.ethernodes.org/network/1>
accessed 17 December 2018
17. Europäische Union and Europarat (eds), Handbook on European Data Protection Law
(2018 edition, Publications Office of the European Union 2018)
18. Fabiano N, ‘Internet of Things and Blockchain: Legal Issues and Privacy. The Challenge
for a Privacy Standard’, 2017 IEEE International Conference on Internet of Things (iThings)
and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and
Social Computing (CPSCom) and IEEE Smart Data (SmartData) (IEEE 2017)
19. ‘Blockchain and Data Protection: The Value of Personal Data’
<http://www.academia.edu/36405035/Blockchain_and_Data_Protection_the_value_of_perso
nal_data> accessed 16 December 2018
20. Fenwick M, Kaal WA and Vermeulen EPM, ‘Legal Education in the Blockchain
Revolution’ [2017] SSRN Electronic Journal <http://www.ssrn.com/abstract=2939127>
21. Finck M, ‘Blockchains and Data Protection in the European Union’ (2018) 4 European
Data Protection Law Review 17
22. Foundation E, ‘On Public and Private Blockchains’
<https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/> accessed 16
December 2018
23. Ganne E, Can Blockchain Revolutionize International Trade? (1st edn, WTO Publications
2018) <https://www.wto.org/english/res_e/booksp_e/blockchainrev18_e.pdf>
24. ‘General Data Protection Regulation (GDPR) – Final Text Neatly Arranged’ (General Data
Protection Regulation (GDPR)) <https://gdpr-info.eu/> accessed 17 December 2018
25. Herian R, ‘Regulating Disruption: Blockchain, GDPR, and Questions of Data Sovereignty’
(2018) 22 Journal of Internet Law 1 and 8
26. Houben DR and Snyers A, ‘Cryptocurrencies and Blockchain’ 103
27. ‘How Does a Blockchain Work - Simply Explained - YouTube’
<https://www.youtube.com/watch?v=SSo_EIwHSd4> accessed 16 December 2018
28. Ibáñez L-D, O’Hara K and Simperl E, ‘On Blockchains and the General Data Protection
Regulation’ 13
29. ‘Identity & Blockchain: The Road to Self Sovereign Identity’ (BlockchainHub, 17 October
2017) <https://blockchainhub.net/blog/blog/decentralized-identity-blockchain/> accessed 17
December 2018

~ PAGE | vi ~
30. Internet of Things for the Global Community and others, Internet of Things for the Global
Community 2017 Proceedings: July 10-12, 2017, Madeira - Portugal (2017)
<http://ieeexplore.ieee.org/servlet/opac?punumber=8001595> accessed 16 December 2018
31. Jones S, ‘Data Breaches, Bitcoin, and Blockchain Technology: A Modern Approach to the
Data-Security Crisis’ (2017) 50 Texas Tech Law Review 783
32. Kosba A and others, ‘Hawk: The Blockchain Model of Cryptography and Privacy-
Preserving Smart Contracts’, 2016 IEEE Symposium on Security and Privacy (SP) (IEEE 2016)
33. Kuner C and others, ‘Blockchain versus Data Protection’ (2018) 8 International Data
Privacy Law 103
34. Liang X and others, ‘ProvChain: A Blockchain-Based Data Provenance Architecture in
Cloud Environment with Enhanced Privacy and Availability’, 2017 17th IEEE/ACM
International Symposium on Cluster, Cloud and Grid Computing (CCGRID) (IEEE 2017)
35. Lin I-C and Liao T-C, ‘A Survey of Blockchain Security Issues and Challenges’ (2017) 19
International Journal of Network Security 653
36. ‘LIT-FebMar18-Feature-Blockchain.Pdf’
<https://www.steptoe.com/images/content/1/7/v3/171269/LIT-FebMar18-Feature-
Blockchain.pdf> accessed 16 December 2018
37. Mantelero A, ‘AI and Big Data: A Blueprint for a Human Rights, Social and Ethical Impact
Assessment’ (2018) 34 Computer Law & Security Review 754
38. Millard C, ‘Blockchain and Law: Incompatible Codes?’ (2018) 34 Computer Law &
Security Review 843
39. Neisse R, Steri G and Nai-Fovino I, ‘A Blockchain-Based Approach for Data
Accountability and Provenance Tracking’, Proceedings of the 12th International Conference
on Availability, Reliability and Security - ARES ’17 (ACM Press 2017)
<http://dl.acm.org/citation.cfm?doid=3098954.3098958> accessed 16 December 2018
40. Ramsay S, ‘The General Data ProtectionRegulation vs. The Blockchain: A Legal Study on
the Compatibility between Blockchain Technology and the GDPR’ (The Swedish Law and
Informatics Research Institute, Faculty of Law, Stockholm University 2018)
<http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1221579&dswid=-6280>
41. Sandmark J, ‘Will the Blockchain Save Privacy under the Revised Payment Service
Directive?’ (KTH Royal Institute of Technology, School of Industrial Engineering and
Management 2017) <http://www.diva-
portal.org/smash/record.jsf?dswid=874&pid=diva2%3A1234202&c=1&searchType=SIMPL
E&language=en&query=Will+the+blockchain+save+privacy+under+the+Revised+Payment+
Service+Directive%3F&af=%5B%5D&aq=%5B%5B%5D%5D&aq2=%5B%5B%5D%5D&
aqe=%5B%5D&noOfRows=50&sortOrder=author_sort_asc&sortOrder2=title_sort_asc&onl
yFullText=false&sf=all> accessed 16 December 2018

~ PAGE | vii ~
42. Savin A, ‘Blockchain, Digital Transformation and the Law: What Can We Learn from the
Recent Deals?’ [2018] SSRN Electronic Journal <https://www.ssrn.com/abstract=3198666>
43. Schwerin S, ‘Blockchain and Privacy Protection in the Case of the European General Data
Protection Regulation (GDPR): A Delphi Study’ (2018) 1 The Journal of the British
Blockchain Association 1
44. Sullivan C and Burger E, ‘E-Residency and Blockchain’ (2017) 33 Computer Law &
Security Review 470
45. Suzuki B, Taylor T and Marchant G, ‘BLOCKCHAIN’ <http://www.azattorneymag-
digital.com/azattorneymag/201802/MobilePagedArticle.action?articleId=1332400&lm=1517
465450000> accessed 16 December 2018
46. Swan M, Blockchain: Blueprint for a New Economy (First edition, O’Reilly 2015)
47. Tapscott D, ‘BLOCKCHAIN REVOLUTION’ 8
48. ‘Using Blockchain to Strengthen the Rights Granted through the GDPR’ 4
49. Werbach K, ‘Trust, but Verify: Why the Blockchain Needs the Law’ 66
50. Wirth C and Kolain M, ‘Privacy by BlockChain Design: A Blockchain-Enabled GDPR-
Compliant Approach for Handling Personal Data’ 7
51. WTO WTO, ‘World Trade Report 2018’ (World Trade Organisation 2018)
<https://www.wto.org/english/res_e/publications_e/world_trade_report18_e.pdf> accessed 16
December 2018
52. Wüst K and Gervais A, ‘Do You Need a Blockchain?’ (2017) 375
<http://eprint.iacr.org/2017/375> accessed 16 December 2018
53. Zarsky T, ‘Incompatible: The GDPR in the Age of Big Data’ (2017) 47 Seton Hall Law
Review <https://scholarship.shu.edu/shlr/vol47/iss4/2>
54. Zhao Y and Duncan B, ‘The Impact of Crypto-Currency Risks on the Use of Blockchain
for Cloud Security and Privacy’, 2018 International Conference on High Performance
Computing & Simulation (HPCS) (IEEE 2018)
<https://ieeexplore.ieee.org/document/8514416/> accessed 16 December 2018
55. Zyskind G, Nathan O and Pentland A ‘Sandy’, ‘Decentralizing Privacy: Using Blockchain
to Protect Personal Data’, 2015 IEEE Security and Privacy Workshops (IEEE 2015)
<https://ieeexplore.ieee.org/document/7163223/> accessed 16 December 2018

~ PAGE | viii ~
F. ANNEX – 1: SUMMARY OF GDPR AND DLT
GDPR Articles and Recitals Implication on DLT
Blockchain for GDPR compliance Usage of DLT for an audit trail
Freedom to do business vs. Protection of
Personal Data (Recital 4, GDPR)
Concept of propotionality, right to protection of personal data not
absolute; determination based on case by case basis
Data Sovereignty (Recital 6 and 7,
GDPR)
DLT does not provide sovreign right over data, once data added to
the ledger cannot be erased
Material Scope (Art. 2, GDPR) Since, DLT is an automated process, may fall within the ambit
Territorial Scope (Art.3, GDPR) Issues related to identifcation of nodes, processing of EU citizens
data by nodes from around the world
Data Localisation (Art. 44-50, GDPR) Transfer of data to third countries as DLT is transnational and
further no central authority to oversee the movement of data
Personal data and data subject (Art.5(1),
GDPR)
Can PD be stored on the blockchain or must be off-chain? The
connection between pseudonymised and anonymised data and the
data subject.
Controller (Art. 4(7) GDPR) The debate of public versus private DLT and who would become
the (joint) data controller if data is stored on multiple locations in
and outside the EU? Private versus public DLT and the
accountability of a (joint) data controller.
Processor (Art. 4(8) GDPR) Similar to that of Controller
Supervisory authority (Art. 4 (21)
GDPR)
As such no issue, but since no regulations on DLT are there, the
question of jurisdiction of the authority over DLT
Six privacy principles (Art. 5, GDPR) Six reasons can be used to comply with lawful processing, and a
data sharing agreement can be recorded on a DLT, data
minimisation, data storage reduction next to impossible
The right to access (Art. 15, GDPR) No information provided to user on processing of his/her data
The right to be forgotten (Art.17, GDPR) Can data on a blockchain be deleted in accordance to the RTBF
and what would happen if not – could the functioning principle
take over that allows for specific interpretations of the GDPR, as
DLT is at its core designed not to be compliant to the RTBF.
Data Portability (Art. 20, GDPR) The control of data is not with one node but all, therefore the
request for port of data is highly unlikely

~ PAGE | ix ~
Notification of personal data breach (Art.
33(1), GDPR)
Since no controller or processor as well no authority that
determines if there is any breach, no notification will be issued to
the user
General conditions for imposing
administrative fines (Art.83(5), GDPR).
The DLT has no controller or processor but mutiple nodes, thus,
on violation it will be very tough task to fine the individuals or
group behind the nodes as they may be difficult to identify and if
found the determination of fine, etc
Data protection by design and by default
(Recital 78, Art. 25, GDPR)
DLT runs counter to data minimisation, storage limitations and a
clearly determined data controller, raising the question whether it
is in line with ‘Privacy by Design’ (PbD). Privacy risks of entire
IT-architecture, including DLT. Solutions could be Enigma or
differential privacy or future more secure DLTs. Weighing the
objectives of DLT versus privacy concerns. PbD could be achieved
by mitigation measures, lack of data controller could pose the
biggest challenge.
Consent (Recital 51, Art. 6-9 GDPR) The DLT can fall outside scope of GDPR if consent is given,
question is how consent is sought
Certification for blockchain Similar to existing regulations (e.g., information security or
electronic identity) it is suggested to create a certificate for trusted
blockchain users
Private vs public and permissioned vs
non-permissioned DLT
This relates to accountability, material and territorial scope.
Data protection impact assessment
(DPIA)
Through append-only function DLTs often use very sensitive data,
resulting in a high risk to the rights and freedom of the data subject
(DS) – would always make a DPIA mandatory.

~ PAGE | x ~
G. ANNEX – 2: GDPR APPLICABILITY WITH PUBLIC, CONSORTIUM
AND PRIVATE DLT
GDPR Provisions Public DLT Consortium DLT Private DLT
Freedom to do business vs. Protection of Personal
Data (Recital 4, GDPR)
Not Complaint Conditional Compliant
Data Sovereignty (Recital 6 and 7, GDPR) Not Complaint Conditional Conditional
Material Scope (Art. 2, GDPR) Compliant Compliant Compliant
Territorial Scope (Art.3, GDPR) Not Complaint Conditional Conditional
Data Localisation (Art. 44-50, GDPR) Not Complaint Conditional Conditional
Personal data and data subject (Art.5(1), GDPR) Not Complaint Conditional Conditional
Controller (Art. 4(7) GDPR) Not Complaint Conditional Conditional
Processor (Art. 4(8) GDPR) Not Complaint Conditional Conditional
Six privacy principles (Art. 5, GDPR) One Principle Conditional Conditional
The right to access (Art. 15, GDPR) Not Complaint To an extent To an extent
The right to be forgotten (Art.17, GDPR) Not Complaint Not Complaint
Not
Complaint
Data Portability (Art. 20, GDPR) Not Complaint Not Complaint
Not
Complaint
Notification of personal data breach (Art. 33(1),
GDPR)
Not Complaint Conditional Conditional
General conditions for imposing administrative fines
(Art.83(5), GDPR).
Not Complaint To an extent To an extent
Data protection by design and by default (Recital 78,
Art. 25, GDPR)
Not Complaint To an extent To an extent
Consent (Recital 51, Art. 6-9 GDPR) Not Complaint To an extent To an extent

Irony of Trust - Blockchain

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Irony of Trust - Blockchain

Similar to Irony of Trust - Blockchain (20)

Recently uploaded

Recently uploaded (20)

Irony of Trust - Blockchain