Blockchain distributed ledger technologies for biomedical and health care applications

Abstract

Objectives: To introduce blockchain technologies, including their benefits, pitfalls, and the latest applications, to the biomedical and health care domains.

Target audience: Biomedical and health care informatics researchers who would like to learn about blockchain technologies and their applications in the biomedical/health care domains.

Scope: The covered topics include: (1) introduction to the famous Bitcoin crypto-currency and the underlying blockchain technology; (2) features of blockchain; (3) review of alternative blockchain technologies; (4) emerging nonfinancial distributed ledger technologies and applications; (5) benefits of blockchain for biomedical/health care applications when compared to traditional distributed databases; (6) overview of the latest biomedical/health care applications of blockchain technologies; and (7) discussion of the potential challenges and proposed solutions of adopting blockchain technologies in biomedical/health care domains.

Keywords: blockchain; distributed ledger technology; health information exchange; interoperability; security.

Figure 1.

The problem of double-spending without a central intermediary. (A) Valid transaction. (B) Double-spending (invalid) transaction. The problem illustrated in this example is: Suppose Alice has 10 coins and then sends all 10 coins to Bob. How can Bob (and other people using the coin) know that Alice has not sent the same 10 coins to Charlie before, without having a bank to verify transactions?

Figure 2.

Comparison of the distributed network topologies. (A) Centralized network topology, which creates a single-point-of-failure (the central intermediary). If the central intermediary is down or attacked, the entire network stops working. (B) Decentralized network topology, which does not contain single-point-of-failure. If one of the nodes, such as Node 1, is down or attacked, the rest of the network can still operate normally. (C) Blockchain. If “everyone can see everything” and there exists a distributed timestamp mechanism, the double-spending problem can be solved on such a decentralized network. In the example illustrated in Figure 1, if everyone (ie, Alice, Bob, Charlie, and all other people in the same network) knows that Alice (Node 1 in this example) sent 10 coins to Charlie yesterday, the transaction to send the same 10 coins to Bob today can thus be rejected through a verification process without consulting a bank.

Figure 3.

An example of simplified blockchain (hash-chain). Each transaction of coins is enclosed in a block. A block may contain multiple transactions and is a basic unit to be verified. Each block also contains a hash value of the previous block's header, and thus forms a hash-chain or blockchain. As all blocks are chained, the order of the blocks is deterministic; therefore, each block can serve as a timestamp of the enclosed transactions to solve the double-spending problem. Note that each node maintains a copy of the whole blockchain, thus every node can verify every transaction. For example, suppose the transaction from Alice to Charlie is enclosed in block B₁ and the one from Alice to Bob is enclosed in block B₂; everyone in the network can verify that B₁ happened before B₂ by checking the hashed blockchain, and thus the double-spend transaction from Alice to Bob should be rejected.

Figure 4.

An example of the nonce mechanism for the proof-of-work protocol. Each block contains an additional “nonce” (32-bit or 8-hex-digits in this example), which is a counter that serves as one of the inputs of the hashing function. To “proof” the hashing work, the nonce is incremented by one bit each time for the hash computation (ie, the “work”), until the hashed value (256-bit or 64-hex-digits in this example) contains a predefined number of leading zero bits (ie, “proof” of the work, 16-bit or 4-hex-digits in this example). Meanwhile, the newly generated unconfirmed transactions are collected in a memory pool on each node. The first node that successfully completes the proof-of-work (Node 1 at 10:14:30 in this example) has the privilege to create a new block (B₂ in this example), verify the transactions, move the confirmed transactions from the memory pool to a newly created block, and add the block to the end of the longest chain (if there are competing chains). It also gets paid (eg, 12.5 bitcoins) for this work. Also, the remaining nodes (Nodes 2 and 3 in this example) stop the proof-of-work mining for B₂ when Node 1 completes the proof-of-work. This way, the mining process becomes difficult (ie, one needs to compute the difficult hashing problem by trying different “nonce” values), while the checking process remains easy (ie, just one hash to see if the predefined leading bits are all zeroes). In our example, Alice cannot easily create an invalid block for her double-spend transaction, while Bob and Charlie can easily check that the block Alice created is invalid. It should be noted that the system clocks on the nodes may not be synchronized, therefore we use a global time for demonstration purposes in this example. Also note that, if an attacker modifies any of the transactions in block B₁, the value of “hash of block B₁'s header” and thus block B₂ need to be recalculated, and consequently all blocks after B₁ (ie, B₂ B₃, B₄, B₅,…) also need to be recomputed. Therefore, the computational cost of attacking becomes prohibitively high.

Figure 5.

An example of how Bitcoin blockchain deals with branching chains. In this scenario, attackers create malicious blocks (M₁ and M₂) to compete with an honest block (H₂), in an attempt to take over the honest chain (H₁ and all blocks before). Assuming the computational power of honest nodes is larger than that of malicious nodes, an honest block H₃ is created right after H₂, before the attackers create new malicious blocks after M₁ and M₂. Based on the blockchain mechanism, each node first identifies a valid block based on the length of the chain, and creates a new block (N) only at the end of the longest chain (H₁→H₂→H₃ in this example) while ignoring shorter chains (H₁→M₁ and H₁→M₂ in this example). In other words, the blockchain that has been worked on most wins the competition (ie, majority voting of “one CPU, one vote,”[1] since the longest blockchain represents the majority decision of block creators). Given that the mining process is expensive and the honest nodes have higher computational power (ie, have more CPU “voters”) than the malicious nodes, the probability for the attacker to successfully modify a block and all blocks thereafter (ie, create a malicious competing chain) is very small.

Figure 6.

An example of 51% attack. In this scenario, attackers create malicious blocks (M₁ and M₂) to compete with an honest block (H₂), trying to take over the honest chain (H₁ and all blocks before). However, this time the computational power of host nodes is smaller than that of malicious nodes (ie, malicious nodes control more than 51% of the computing power on the network), thus a malicious block M₃ is created right after M₂. Based on the blockchain mechanism, the new block (N) will be created only at the end of the longest chain (H₁→ M₂→M₃ in this example). Therefore, the attacker has successfully modified the blockchain record (from H₂ to M₂) and takes over the chain by winning the majority vote.