上QQ阅读APP看书，第一时间看更新

The CAP theorem

The CAP theorem, introduced originally by Eric Brewer in 1998, states that any distributed system cannot have all three of these properties simultaneously:

Consistency: This is a capability of the network of nodes to keep a consistent copy of the blockchain data in their computers at the same time.
Availability: This means that the system of connected nodes is online and available at all times while being accessible by all users to respond to requests without failure when required to do so.
Partition tolerance: If a group of nodes of the entire network stops working or loses connection for any reason, the system should not be affected, and it should continue working properly as if nothing happened.

It has been proven that a distributed or decentralized system cannot have all three of these properties at the same time, which is interesting because Ethereum, just like Bitcoin, achieves all of them at what appears to be the same time. The truth is that consistency is not achieved at the same time as partition tolerance and availability, but at a later time. You see, in order to have order in such a diverse variety of computers, we can only hope to achieve the same level of data over time whenever the blockchain grows at an established pace. It lags behind the others. This is called eventual consistency, where the goal is achieved as a result of validating multiple nodes over time. For this reason, the concept of mining was introduced in Bitcoin and Ethereum to agree on a consensus with the PoW protocol.

Eventually, Ethereum plans to move to PoS, which consists of the idea that a node or user maintains a stake, a certain number of Ether or any type of valuable investment in the system, so that the negative consequences of any malicious activity would outweigh the benefits of attacking the network.

For instance, if I want to become a miner to earn some Ether in exchange for my time and resources, I have to lock 100 Ether in a smart contract that runs the PoS protocol. If I decide to validate invalid blocks or transactions, and someone notices my malicious behavior via several security mechanisms, I would lose all those 100 Ether and wouldn't be able to attack again. The reward for processing a block successfully would be a percentage of the resources invested, for example, 0.1 ETH. This forces nodes to cooperate and act responsibly to avoid losing a big stake, even if they agree to attack the system.

Alternatively, delegated proof-of-stake (DPoS) could be used in later versions of Ethereum. It consists of delegating the validation of a transaction to other nodes by voting. It is used in the BitShares blockchain.