书名：Hands-On Blockchain with Hyperledger
作者名：Salman Baset Luc Desrosiers Nitin Gaur Petr Novotny Anthony O’Dowd Venkatraman Ramakrishna
本章字数：572字
更新时间：2021-06-25 21:01:22

CAP Theorem

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 RDBMS (Relational Database Management Systems) guarantees consistency on a single node on the expense of availability across multiple nodes (CP type of systems). However, note that, different configurations may yield different combinations namely CA or AP as well.

In contrast, Fabric is designed similarly as many other Blockchain platforms as AP type of system with Eventual Consistency also referred to as BASE (Basically Available, Soft state, Eventual consistency).

In context of blockchain CAP properties can be defined as following:

Consistency: The blockchain network avoids any forks of the ledger
Availability: Transactions submitted by clients are permanently committed into 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 are 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 (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 i.e. 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 in Multiversion concurrency control, 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 Worldstate and prevents attacks such as double spending. However, it can also lead to elimination of otherwise valid transactions, which 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.