Blockchain security and CAP theorem

Bitcoin

Bitcoin reached an All-Time High (ATH) of over $73,000 on March 13. This move further strengthened the credibility of bitcoin and its accessibility to individual investors, as crypto assets became more widely recognized as a legitimate asset type (purchasing Bitcoin is approved or not depends on the countries). Can Bitcoin and other cryptocurrencies be trustworthy assets in the future? This article considers the security of Bitcoin and other crypto-currencies.

Hack-Proof

Among blockchain-based cryptocurrencies, Bitcoin is special. Bitcoin's blockchain has never been hacked, so considered to be hack-proofed, and its currency has never been leaked over a decade (In 2011, a user reports he had 25,000 Bitcoins (BTC) were stolen when his computer was infected, but it is not proved that the cause was Bitcoin's problem). All of the Bitcoin-related incident/leakage have been due to problems of other 3rd party software problems and/or user operations or leaked from exchange site, not because of the Bitcoin itself. In contrast, some other emerging cryptocurrencies have been hacked by utilizing its loophole. The most famous one was the DAO Hack in 2016, which happened because of a vulnerability which makes Reentrancy attack possible. Bitcoin does not have that.

Blockchain Security Overview

So what makes Bitcoin hack-proof? Blockchain security is a big theme which can be discussed entirely, but let me name some of the elements which sustain blockchain security:

• Cryptography: A public key and address can be created from a private key, but the private key cannot be decrypted from the public key or the address. Therefore, signing the transaction proves that a legitimate user did the transaction.
• Hash function: The hash function guarantees the integrity of the data. And, because of its one-way nature, it is impossible to alter past transactions.
• De-centralization mechanism: Each node in the blockchain network has the same transaction data and is synchronized. Thus, even if one node goes down or loses a link to other nodes, the blockchain network will be working.
• Robust and conservative design (Bitcoin): Bitcoin is written in C++ and has been tested many times by skillful contributors.
• Consensus mechanism: A malicious user can create a block containing fraudulent transactions on top of the previous transactions, which requires the same energy and resources as building a legitimate chain (Proof of Work). As a result, all participants have an incentive to maintain a legitimate chain.
• Opensource: The most important difference between blockchain security and TCP/IP network security is that every transaction can be tracked in blockchain. For example, blockstream.info is an opensource tool where anyone can search for any transaction. And Bitcoin is an open source project and the source code is available under an open (MIT) license, thus anyone can verify the source code, and if someone finds a bug or possible vulnerability they can ask to fix it by submitting Bitcoin Improvement Proposal, and then Bitcoin is maintained well by those contributors.

Distributed Database

Bitcoin is a software and a wallet, but it is also a network. It is a peer-to-peer network and consists of nodes that anyone with a computer of a certain specification can join. All the bitcoin nodes must have the same transaction data (if it is a full node). In other words, one could say that a globally distributed database is running and doing real-time syncing.

CAP Theorem

There is a theorem about information replication in distributed computer design, called the CAP theorem (or Brewer’s Theorem), which is based on three characteristics: Consistency (C), Availability (A), and Partition-tolerance(P). Unlike the well-known security CIA triad, the CAP theorem states that all three cannot be satisfied simultaneously.

In a distributed database, a transaction in the database will be split into multiple sub-transactions and executed on multiple nodes. If two of the characteristics, for example C and A, are satisfied and abandon P in the design, on a two-phase commit, it is not clear whether the sub-transaction should be committed or rolled back, so it might need to halt the commit and lock the database. If only two nodes are impacted it is still possible to do risk-control, however, if it is a cloud environment, it is impractical to lock hundreds or tens of thousands of nodes at the same time. Therefore, we consider designing for consistency in a cloud environment at the expense of consistency.

As mentioned before, the Bitcoin is a network which sync its state (transaction) among the nodes.  When a transaction is enrolled, it is copied to all the nodes simultaneously—like a distributed database. We can apply the CAP theorem to this. 

Think about P of CAP theorem. When a link in the network gets split, the transaction data cannot be copied between one node and another. If continuity of the blockchain is the priority, then A and P are satisfied, however, C is not satisfied because the transaction data in blocks in each node differs from one node to another. In a blockchain network, C can not be abandoned since the transaction data are the asset. And the P is important for blockchain because consensus on the chain is an essential part of the blockchain system. So, A will be sacrificed—a hard fork or roll-back might happen to post-processing this (when DAO hack happened, both of them happened). 

Is this theorem related to us? I think a situation which sounds like CAP theorem is BigIP HA. When the config sync is done and "the connection and persistence mirroring features duplicate the connection and persistence information from the active unit to a peer system". 

Suppose, for example, that when the link between BigIP sync-failover pairs is interrupted, and if A is important, the two Nodes should keep running as Active status and then P is also satisfied. However, if consistency is important, the connection and persistence status of the two nodes should not be different. Which will be taken—there is no right answer to this question. However, it is important to know this concept to decide on an operational policy.