15.1.1 What is Blockchain?

A Blockchain is “in essence an append-only decentralized database that is maintained by a consensus algorithm and stored on multiple nodes (computers)”.Footnote ⁴ This definition includes a number of complex technical elements that are addressed in more detail below. Essentially, Blockchain technology is a special way to store data in a database. As such, any type of data can be stored on a Blockchain, including Personal Data. On a Blockchain, each piece of data is stored one after the other in a chain (which is why it is called “append-only”).Footnote ⁵ This is done by grouping data in blocks and by adding, to each new block, a cryptographic pointer (a reference or link) to the previous block.

The design of Blockchains is guided by a desire to increase security (in the broad sense of the term). In particular, and as mentioned above, Blockchain technology aims to enhance transparency and trust in the integrity of the database. Blockchains are “distributed” and often “decentralized”. While these are two different concepts, they bear a common feature – namely, they indicate that the data being processed are not managed and stored centrally. Here, “distributed” means that there are multiple copies of the database stored on different computers, while “decentralized” means that the power and authority to decide what data are added to the ledger is not held by a single entity or individual, but is instead shared between many entities or individuals that have to work together. In this chapter, these entities or individuals are referred to as “validators” (since they, together, validate the data to be stored on the Blockchain). Usually, the higher the number of validators, the more complex the rules they have to follow to reach an agreement. These rules are reflected in a “consensus protocol” (see Section 15.1.2 – Types of Blockchain, below for further details).

The computers that hold a copy of the Blockchain are called “nodes” (since they represent nodes in a vast network). Nodes can be passive (only storing an up-to-date copy of the Blockchain) or active. Active nodes are also validators, and are said to be “mining” the data (i.e. participating in the consensus protocol to validate new insertions). Sometimes validators are called “miners” by analogy.

“Users” are the parties who wish to add information to the Blockchain (hence creating data that need to be validated and recorded on the Blockchain).

A piece of information will only be inserted into the Blockchain once it has been validated. This makes it extremely difficult for a malicious party to add data to the Blockchain, since any addition has to be accepted by the validators first.

Moreover, the blocks of information on a Blockchain are time-stamped and, as mentioned above, contain a cryptographic link (pointer or reference) to the previous block. This means that, even if a malicious party succeeds in changing data contained in a particular block, it also has to modify the following block (as the cryptographic pointer it contains will have changed), as well as all subsequent blocks through to the end of the chain. These changes would unlikely go unnoticed because of a Blockchain’s decentralized design, which means that every validator would have to agree to them. Since, in practice, it is very difficult (though not totally impossible) to change information on Blockchains, they are often referred to as immutable ledgers.Footnote ⁶

When information is added on the Blockchain, a mechanism involving public and private keys is used to secure the transactions. Blockchain users own one or more such key pairs. The public key, or a value derived from it, serves as the user’s address on the Blockchain. It is publicly known and used to verify the origin and destination of added information.Footnote ⁷ Even though Blockchain addresses do not by themselves reveal the identity of the person they relate to, they are still considered to be pseudonymized Personal Data as they are linked to one specified individual (the user who adds or receives information). They could be traced back to the individual’s IP address, for instance, which could lead to identification.Footnote ⁸ As Blockchains are near-immutable, public keys could potentially remain on the Blockchain for as long as the ledger exists.

Several companies provide Blockchain analytics services that specialize in providing platforms for investigative and compliance needs in Blockchain-based transactions. They offer Blockchain intelligence to gather, analyse and interpret data from various Blockchain networks. Their platforms enable the identification and monitoring of transactions, addresses and entities involved in Blockchain activities. These investigations help businesses and regulatory agencies to comply with Anti-Money Laundering (AML) requirements. Another use case is to support law enforcement agencies in combating illicit activities using cryptocurrencies. These investigations are possible because the Blockchain public addresses can be used to reidentify users. Several new designs have been proposed to guarantee a higher level of anonymity, for instance Monero or the ZCash protocol. They come with their own limitations and Humanitarian Organizations have to balance those limitations carefully. However, Humanitarian Organizations should also be mindful of the need for more privacy when deploying off-the-shelf Blockchain-based solutions.

Some of the above characteristics of Blockchain technology can be advantageous for Humanitarian Organizations. For example, the decentralized architecture can potentially increase security, since there is no single point of failure or compromise in such systems. This means that potential attackers need to compromise several links in order to compromise the Blockchain as a whole. This set-up increases system integrity because it is claimed to almost always guarantee data immutability.

In light of the fact that information is time-stamped and close to immutable, and the fact that responsibility is shared, it has been arguedFootnote ⁹ that Blockchains can be most valuable when:

• they are used to track ownership of complex things over time;

• there are multiple groups or parties involved;

• there is no well-established or effective central authority (also known as a trusted Third Party) in place;

• groups or parties involved need to work collaboratively;

• a record or proof of transactions is required.

These examples show that the one of the main benefits of Blockchain technology is its resistance to a single point of failure or compromise. This is due to the ledger’s distributed design, which ensures that multiple nodes have to work together to add new data to the Blockchain. Moreover, because the whole ledger is copied to multiple nodes, it becomes difficult to change information on the ledger and data remain available even if one node is compromised, thereby increasing their integrity.

It is important to note that Blockchain technology will most likely not be needed when there is no issue with the level of integrity (i.e. there is enough trust between the parties involved in a specific programme and there are sufficient levels of auditability), or simply if other current technology offers a sufficient degree of integrity and availability. In such cases, a more traditional solution with a central database, for instance, may prove more efficient, faster, and cheaper to implement, and, overall more proportionate from a data protection perspective.

Another element to take into account is the exit criteria. Humanitarian Actions are often designed to be temporary. If a Blockchain is used in a CVA program, for example, the process to shut down the program, discard Personal Data and close the beneficiary’s account may be complicated by the distributed and immutable nature of the Blockchain.

15.1.2 Types of Blockchain

Blockchains can be built in different ways, according to system design choices. One key decision, for instance, is whether or not the Blockchain will be public. Although there is no universally agreed definition of each type of Blockchain, the following definitions are more commonly used:

Table 15.1

Besides choosing who can “read” or “write” on the Blockchain, system designers must also decide how validation will take place. Blockchain validation processes are regulated by consensus mechanisms (or consensus protocols), which consist of a set of predefined rules that divides trust among the parties. These rules allow them to store data immutably without a central authority (or trusted Third Party), thereby preserving the integrity of the ledger.Footnote ¹⁰ In other words, consensus mechanisms define how new information is validated by the parties in the Blockchain and, if deemed valid, added to the ledger.

There are different types of consensus protocol. For example, in Blockchains that use proof-of-work protocols, validators need to earn the right to validate a transaction by solving complex mathematical problems using brute computational force, which requires considerable processing power and electricity.Footnote ¹¹ In proof-of-stake protocols, meanwhile, the parties have simple voting rights, and the weight of their vote may vary according to their stake in the Blockchain.

To illustrate some of the different choices that have to be made when developing a Blockchain, it is useful to think of the system like a corporation. Corporations typically hold board meetings. There need to be rules governing how board members are chosen and who has the right to vote and make decisions. One option is to have a closed group decide who joins and leaves the board (akin to a permissioned Blockchain). Another possibility is to allow anyone to sit on the board as long as they buy enough “stock” in the company to give them voting shares (a proof-of-stake Blockchain). A third option is to decide that anyone can sit on the board as long as they can prove they devoted enough energy to a task in the past 10 minutes – an artificial barrier to entry (a proof-of-work Blockchain).

15.1.3 Blockchain in practice

Scholars and practitioners propose the following advantages and challenges of using Blockchain technology:Footnote ¹²

While Blockchain technology can help improve transparency in many situations, it does not solve the underlying problems that create so-called bad data. In other words, if someone stores unreliable records on a Blockchain, they will remain unreliable and the system will not achieve its potential benefits.Footnote ¹⁶

These advantages and challenges of Blockchain have significantly influenced their use. Blockchains are frequently used to manage transaction histories recording the ownership or custody of, or responsibility for, assets such as cryptocurrencies. They are also used to notarize or assign time-stamps to supply-chain, digital-credential and other documents, as well as to enforce the terms of a contract (through the use of smart contracts).Footnote ¹⁷

15.1.4 Humanitarian use cases

Humanitarian Organizations have begun exploring possible applications of Blockchain and have launched pilot projects using the technology.Footnote ¹⁸ While there is little information available about the benefits and risks that Blockchain technologies bring in such cases, some of the following uses among Humanitarian Organizations have been proposed:Footnote ¹⁹

Cash and Voucher Assistance (CVA).Footnote ²⁰ Blockchain could improve the efficiency of CVA through a secure and well-structured transaction record-keeping system, which in turn increases transparency and provides added assurance that data stored in the system have not been tampered with. The application of Blockchain technology to CVA could allow Humanitarian Organizations to make digital cash payments cheaper, more efficient and traceable, as well as interoperable across multiple organizations. In addition, because Blockchain technology is said to provide operational resilience and to entail no single point of failure or compromise, it could make transactions more secure (See Section 15.5.4 – Data security, below for more information on Blockchain and security).

Optimizing and tracking logistics. Humanitarian supply chains are extremely complex and dynamic, which makes it difficult to monitor them properly. Blockchain technology may offer a way to introduce transparency into these operations. In the case of provision of medical supplies, for instance, a Blockchain may contain a near-immutable, time-stamped record of when the supplies left the warehouse, when they were transported out of the country of origin, when they arrived at the country of destination, when they were received by the local branch of the Humanitarian Organization and when they reached the destination hospital. Because a public Blockchain provides a publicly visible ledger, it can serve as a transparent data platform that traces the origins, use and destination of humanitarian supplies.

Tracking donor financing. Peer-to-peer tracking and monitoring of donations may make it possible to scale up finance models that cut out the traditional “middleman”Footnote ²¹ (or trusted Third Party).Footnote ²² Such models could reduce transaction costs associated with international humanitarian financing and improve the tracking of donations, including from the general public. However, Blockchain technology could be used to make anonymous donations. This could pose a challenge for Humanitarian Organizations with stricter funding policies that require the donating party to be identified.

Enhancing shared situational awareness in conflicts. The Whiteflag ProtocolFootnote ²³ (in which the ICRC is collaborating) aims to provide a neutral means of communication for all parties involved in a conflict. Whiteflag is designed to deliver a messaging system in which real-time information on emergencies, local dangers, landmines, population displacement and other issues can be shared in the knowledge that it has not been altered by a malicious party. In this arrangement, none of the participants need to trust one other. Although having this information publicly available could help to locate civilians and assess distinction and proportionality in attacks, it could also be used to target identified groups.

15.5.1 Data minimization

By their very nature, distributed ledgers would appear to run counter to the principle of data minimization, which states that the minimum amount of Personal Data should be processed in order to attain the objective and purposes of the Processing.Footnote ³⁷ This is mainly because data in Blockchains can potentially be stored perpetually, and because a copy of the full ledger is stored in multiple nodes on numerous devices. However, there may be workaround solutions. Personal Data could be stored off the Blockchain while the ledger only keeps a cryptographic pointer to the data that are stored in a different location. In this case, the data will not be stored perpetually on the ledger or shared with all the nodes. The individual or organization that stores the data will retain full control over them and, therefore, will be able to apply the data minimization principle to the off-chain Processing of data without altering the ledger itself. Whether cryptographic pointers also qualify as Personal Data remains a matter of debate.Footnote ³⁸

15.5.2 Data retention

The fact that Blockchains are claimed to be immutable distributed ledgers also poses a challenge for the data retention principle.Footnote ³⁹ Data stored on a Blockchain will be retained indeterminately on multiple computers. The best solution, therefore, would be not to store Personal Data on Blockchains. Personal Data should not, for instance, be stored in public ledgers, since this type of Blockchain can be accessed (or read) by anyone. In particular, Personal Data that are particularly sensitive – such as ethnicity and health records – should never be stored on Blockchains.

15.5.3 Proportionality

Proportionality is a core principle of data protection. It generally requires consideration of whether a particular action or measure related to the Processing of Personal Data is appropriate to its pursued aim. Proportionality involves setting out the options and choosing the one that is the least intrusive with regard to the rights of Data Subjects. The complexity of Blockchains can make it difficult to determine whether a particular implementation is proportionate.

As with the data minimization and data retention principles, one way to address proportionality concerns in a public permissionless Blockchain could be to store Personal Data off-chain. Yet adding an off-chain database can mean reintroducing a trusted Third Party, such as a Cloud Service provider with whom the data will be stored. This, in turn, may negate the supposed benefits of using Blockchain in the first place. The proportionality requirement could, however, be satisfied if the characteristics of Blockchain are essential to achieve the envisaged objective (such as when there is an important need to improve the integrity, transparency and availability of an existing solution), and if that objective could not be achieved with a centralized database model (for instance, because the parties do not trust one another). The risks to Data Subjects, however, cannot be disproportionately high in comparison to the aim pursued.

15.5.4 Data security

Data security is a key aspect of an effective data protection system.Footnote ⁴⁰ Security is often related to three key principles:

• confidentiality: the data must only be accessible to authorized parties;

• integrity: unauthorized parties must not be able to modify the data, and the data must not be lost, destroyed or damaged;

• availability: the data must be available (to authorized parties) when needed.

Blockchains present both strengths and weaknesses when it comes to security across these three aspects. These are detailed, in turn, below.

On the issue of confidentiality, the distributed nature of Blockchains means that the same data are potentially replicated and distributed widely. This leads to increased access points and vulnerabilities. Moreover, even if a Blockchain system uses complex encryption and hashing techniques, advances in quantum computing mean that information could even be decrypted without the decryption key. If, in the future, encryption no longer guarantees the safety and anonymity of the data, all Personal Data stored on a public Blockchain could be exposed. And because, in most situations, data stored on a Blockchain cannot be deleted, the damage can be irreversible. This is yet another reason why it is not recommended to store Personal Data on the Blockchain itself.

With regard to integrity, the immutable character of Blockchain technology and the use of consensus protocols provide a security benefit over centralized databases, not least because “storing sensitive data on centralized servers creates a ‘honeypot’ for would-be hackers and a single point of failure”.Footnote ⁴¹ In Blockchains, however, there is no single point of failure or compromise and, unless an attacker is able to gain control of enough nodes to control the consensus protocol, the system would most likely not be compromised.

On the question of availability, Blockchain is again beneficial because it consists of a distributed ledger stored simultaneously in multiple computers.

Resistance to a single point of failure or compromise is frequently said to be Blockchain’s main added value in relation to security. If that is not an imperative for the organization, then traditional, non-Blockchain technology may be more efficient, faster and cheaper. Secret sharing techniques that are said to enhance the protection of encrypted data in distributed ledgers, for example, can also be used in traditional databases, i.e. they are not exclusive to Blockchain. The technology adds value when integrity and availability are important and when participants do not trust one another.

15.6.1 Right of access

Individuals have a right to know whether their Personal Data are being processed by the Data Controller, and to obtain a copy of the Personal Data in question.Footnote ⁴² In the humanitarian sector, therefore, when Personal Data are stored on the Blockchain, Humanitarian Organizations should always participate as nodes that hold a full copy of the ledger. That way, they can ensure that the entire database is available at all times, and can inform beneficiaries which data are stored on the Blockchain.

When Personal Data are stored off-chain, meanwhile, the ledger only contains a pointer to the off-chain data. In such cases, the most likely scenario is that Humanitarian Organizations will store the data themselves and should be able to reply to Data Subjects’ requests in line with the legal requirements.

15.6.2 Right to rectification

Data Subjects have a right to have incorrect data about them rectified.Footnote ⁴³ In a Blockchain, however, this can be problematic as it is technically very difficult, albeit not impossible, to change data once they are added to the ledgerFootnote ⁴⁴ (hence the term “immutable”).

If Personal Data are stored on-chain, one way to uphold this right is to add the new, rectified data to the chain – by way of a supplementary statement – while making the previous data inaccessible (for instance by deleting the decryption key needed to access the incorrect data). However, there is no consensus over this solution among practitioners and academics. In some cases, it is also possible to insert a new transaction indicating that the old data need to be corrected. The problem with these options, however, is that instead of correcting the original data, they merely add more data to the chain. It is unclear whether this would be accepted as rectification.

In view of these limitations, the best way to deal with these challenges is to store Personal Data off-chain, where it can be rectified without altering the ledger itself. Note that this option would to a large extent reduce the integrity and availability advantages of the Blockchain described above. In other words, if integrity and availability are also important for Personal Data, then a Blockchain-based solution is not recommended.

15.6.3 Right to erasure

The nearly immutable nature of Blockchain stands conceptually in conflict with the right to erasure.Footnote ⁴⁵ Various options have been suggested to address this issue. One option, as mentioned above, is to make the data on the chain inaccessible, albeit still present on the chain. This can be achieved, for example, by deleting the decryption key needed to decipher encrypted data. Yet some scholars and practitioners argue that this approach is unsatisfactory because the Personal Data in question, although encrypted, are not deleted (as the right to erasure implies) but merely made inaccessible. This could prove problematic in light of advances in decryption technology (see Section 15.5.4 – Data security, above).

Since Personal Data stored off-chain can be rectified and deleted in line with data protection requirements without altering the distributed ledger itself, this is again the preferred option.

15.6.4 Restrictions of Data Subjects’ rights

The above discussion on access, erasure and rectification shows how difficult it can be to exercise data protection rights when using Blockchain technology. Since public permissionless Blockchains are mostly incompatible with Data Subjects’ rights, it would seem that the only solution is to store Personal Data off-chain. Yet these rights are not absolute and can, therefore, be restricted. The Data Controller is allowed to take into account available technology and the cost of implementation when Data Subjects request to exercise their rights. Importantly, however, these restrictions may be acceptable only in exceptional cases.Footnote ⁴⁶ Chapter 2: Basic principles of data protection, explains and exemplifies the situations in which Data Subjects’ rights can be restricted. Questions remain as to whether it is possible to have a “data-protection-compliant” Blockchain in specific use cases where the Processing legitimately involves derogation from Data Subjects’ rights. Even if it is judged legitimate to restrict certain rights, all other data protection principles (data minimization, necessity, proportionality, security, etc.) still apply.

Step 1:

This step is common to the deployment of any new technology and does not apply exclusively to Blockchain. It consists of an initial information-gathering and scoping exercise that should answer the following questions:

• What problem might a Blockchain solution address?

• To which programme will it apply, and what are the programme’s needs?

• Is a Blockchain system the least invasive, most risk-averse and most controllable technology available to address the problem at hand?

• In what context will the Blockchain function?

• Where will it function (in one country or region, worldwide)?

• Who are the stakeholders (beneficiaries, local authorities, financial partners, mobile operators, other Humanitarian Organizations, etc.)?

• What are the objectives of the technology (increase internal efficiency, improve positioning, expand existing programmes, meet donor requirements, manage risks, etc.)?

• What are your existing governance arrangements and IT capacity? Can the technology be implemented, and can the associated risks be managed, under current arrangements and capacity?

• Is it clear how the technology will contribute to the local information ecosystem?

Step 2:

Determine if a Blockchain-based system is necessary to attain the objective(s) of a humanitarian programme or other initiative, taking into consideration the advantages and challenges related to the technology, as identified above, in the particular context in which it will be implemented. Your organization should seek to understand what its needs are, whether or not Blockchain will fulfil those needs, how Data Subjects will experience the system, how their rights will be respected, and whether the same needs could be fulfilled by another system that better protects Data Subjects and their rights. You should ask the following questions:

• Does the order of (trans)actions matter?

• Is there a central authority you can trust?

• Do you need to store data?

• Is there buy-in from your governance/IT support team?

• Do you understand how your system will contribute to the local information ecosystem?

Step 3:

If your organization decides that its objective can only be achieved with a Blockchain solution, you need to determine what type of Blockchain is most appropriate or necessary. Ask the following questions:

• Do you need to store state? This means whether or not your system needs to store the status and conditions of the system and not only to perform the action.

• Are there multiple contributors? This means contributors that can directly write data to the system. In a classical ecommerce use case where all users access the database through the merchant’s website, the merchant is the single contributor as users cannot access the database without the merchant’s control. Note that in the case of Blockchain, there are several roles to take into account.

• Can you use an “always-online” trusted Third Party (TTP)? A TTP is the entity that executes certain functions centrally, typically to validate the transactions.

• Are all contributors known?

• Are all contributors trusted?

• Is public verifiability required? It is important not to conflate public verifiability with the publication of audit or transparency report. It is meant here to have a provable verifiablity (in the mathematical sense) of the data.Footnote ⁴⁸

Figure 15.1

Decision tree.

Adapted from Wüst and Gervais, “Do you need a Blockchain?”, IEEE, 2018.

Step 4:

Consult your DPO, IT support and peers:

• Ask for guidance.

• Make use of the experience of others. For example, consult peers that have developed a similar system or used the off-the-shelf solution you intend to use, and seek advice from Blockchain experts.

Step 5:

Conduct a DPIA to identify and assess Personal Data Processing impacts. A DPIA should include questions such as the following:

• What is the applicable law? Is it applicable to all stakeholders?

• What types of Personal Data are processed? Which of these are necessary for the transaction that will be stored on the Blockchain?

• Is the Processing fair, lawful and transparent?

• What are the alternatives to storing Personal Data on the Blockchain itself? Is off-chain storage possible?

• Are the Data Subjects able to fully exercise their rights? If not, are the restrictions lawful and proportionate?

• Who has the power to determine the governance of the Blockchain?

• How does the platform operate?

• Who can alter the platform and under what circumstances could entries on the ledger be updated?

• What are the risks posed by the chosen technology? How will each risk be treated and mitigated?

• How can individuals exercise their rights?

Step 6:

Implement the principles of data protection by design and by default:

• Both principles require continuous monitoring and revision of technical and organizational measures, taking into account the following: available technology; the cost of implementation; the nature, scope and context of the Processing; the purposes of the Processing; and the risks (of varying likelihood and severity) to the rights and freedoms of natural persons posed by the Processing. A new DPIA should be conducted whenever there is a relevant change in the technology used or the type of data collected.

• Data protection by design involves considering factors such as:

  • compliance with data protection principles (lawfulness, fairness and transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, and confidentiality);

  • the rights of the Data Subject (e.g. notification, access, erasure, rectification);

  • other data protection obligations (e.g. accountability and security).

• Data protection by default involves considering factors such as:

  • what types and categories of Personal Data are processed;

  • the amount of Personal Data processed;

  • the purpose for which they are processed;

  • the storage period;

  • accessibility.

The above framework is summarized in the chart below. If, at the information-gathering stage, your organization concludes that other systems may be more appropriate than Blockchain, then you should not proceed past step 1.

Figure 15.2

A Blockchain-based solution for humanitarian assistance.

Adapted from Wüst and Gervais, “Do you need a Blockchain?”, IEEE, 2018.