CAP theorem

In Chapter 1, Blockchain – An Enterprise and Industry Perspective, we introduced the CAP theorem in the context of general system properties. Formally, the CAP theorem as postulated by Eric Brewer in 2000 at ACM Symposium on Principles of Distributed Computing (PODC) (https://dl.acm.org/citation.cfm?id=343502) states that in a distributed data store it is impossible to guarantee more than any two of the following three properties: consistency (C), availability (A), and partition tolerance (P). A distributed data store thus can be characterized on the two properties it guarantees, namely CA, CP, or AP.

More specifically, the theorem is aimed at distributed systems deployed across unreliable networks (networks with faults and delays, such as the internet), leading to a partitioning of the system components. According to CAP, in these environments, the system design must focus on the balance between availability and consistency. For example, the ACID (atomicity, consistency, isolation, durability) approach, typically provided by relational database management systems (RDBMSes), guarantees consistency on a single node at the expense of availability across multiple nodes (CP systems). However, note that different configurations may yield different combinations, namely CA or AP, as well.

In contrast, Fabric is designed, similarly to many other blockchain platforms, as an AP type of system with eventual consistency, also referred to as BASE (basically available, soft state, eventual consistency).

In the context of blockchain, CAP properties can be defined as follows:

• Consistency: The blockchain network avoids any forks of the ledger
• Availability: Transactions submitted by clients are permanently committed to the ledger and available on all the network peers
• Partition tolerance: The blockchain network continues to operate despite an arbitrary number of transaction proposals or blocks being dropped (or delayed) by the physical network medium between the peers

Fabric achieves the CAP properties as follows:

• Consistency: By a total order of transactions and version control using MVCC
• Availability: By hosting a copy of the ledger on each of the peers
• Partition tolerance: By maintaining operation despite failed nodes (up to a threshold)

As you can see, availability and partition tolerance (the AP properties of the CAP theorem) are guaranteed by default in most blockchain systems. However, consistency is harder to provide.

Fabric achieves consistency by combining the following elements:

• The transaction processing is split into a sequence of steps across multiple components of the network.
• Clients connect to a communication channel and submit transaction proposals to endorsing peers and then to the ordering service.
• The ordering service orders transactions into blocks with a total order, that is, the order of the transactions is guaranteed to be consistent across the whole network. The blocks once created are broadcasted to each member peer of the channel. The broadcasting protocol guarantees reliable delivery of the blocks to the peers in a correct order, namely total-order broadcast.
• As we will explain when looking at multiversion concurrency control (MVCC), upon reception of the block on the peer, the peer uses MVCC to validate each transaction based on the key versions stored in the transaction ReadSet. The MVCC validation guarantees consistency of the resulting ledger and of the world state and prevents attacks such as double spending. However, it can also lead to the elimination of otherwise valid transactions that have been submitted in an order violating the ReadSet version validation check. The transactions are then marked either valid or invalid in the ledger.
• The ledger then contains a sequence of totally ordered blocks, where each block contains a sequence of totally ordered transactions (either valid or invalid), yielding a ledger imposing a total order across all transactions.

To round off the chapter, we'll cover a few new features that have been introduced with the most recent version of Hyperledger Fabric.