ETH2.0 is coming, don't you know Casper yet? (two)
existprevious articleprevious article
In, we introduced Casper FFG in Vitalik's original paper, which uses PoS to confirm the blocks generated by PoW to improve the security of the system, but this is only a transitional solution, and a pure PoS will be used in Ethereum 2.0 The Casper protocol, this article will introduce the Casper protocol that will be used in Ethereum 2.0.
How to become a Validator
First, let’s see what the architecture of Ethereum 2.0 looks like. As shown in Figure 1, there will be a main chain called Beacon chain in Ethereum 2.0, which is generated through PoS Casper. Under the beacon chain, there are 1024 shards, and each shard can process data independently.
image description
Figure 1 Architecture of Ethereum 2.0
In Ethereum 2.0, original users can become Validators by mortgaging ETH in Ethereum 1.0, participate in PoS 2.0, and can redeem tokens in Ethereum 2.0 through the redemption operation. It should be noted here that the tokens in Ethereum 1.0 and 2.0 are not the same. Users mortgage the ETH in 1.0 (burn ETH), and redeem the tokens in 2.0 (mint new tokens).To become a Validator, a user must first send a transaction to a special contract in Ethereum 1.0 to mortgage a certain amount of ETH (currently the minimum value is 32ETH), and then the user will get a proof of the transaction. By showing this proof to Ethereum 2.0, the user becomes a Validator after the verification is passed, as shown in Figure 2:
image descriptionFigure 2 Mortgage of ETH in Ethereum 1.0 to become a Validator process in Ethereum 2.0, the user shows his mortgage transaction to Ethereum 2.0, and the mortgage transaction to
The proof of the complete Merkle tree can verify the legitimacy of the currency transaction. Verified users become Validators in Ethereum 2.0.
secondary title
Capser's block generation process in Ethereum 2.0
In the previous article, we introduced Casper to produce blocks through PoW and use PoS to finalize the blocks. Therefore, a problem that needs to be solved for pure PoS Casper is how to generate blocks. Before formally introducing the protocol process, let us clarify a few definitions:
Validators collection: V = V1 ... Vn, assuming each Validator has the same stake;
slot: the basic time unit, currently set to 6s;
After clarifying the above definition, let's further describe the Capser block generation process in Ethereum 2.0, as shown in Figure 3.
image description
Figure 3 Casper consensus process in Ethereum 2.0
1. At the beginning of each epoch, a random number is generated by a random number generator, and the Validator set V is divided into 64 parts on average to obtain S1, S2, ..., S64.
2. In an epoch, each slot i selects a Validator in Si to submit a candidate block according to the random number generated in step 1, and writes the validator submitting the candidate block in slot i as proposer_i, and the submitted candidate block Write B_i.4. In each slot i, proposer_i is responsible for packing the attestation information in the previous slot into the candidate block of the current slot. Right now
LMD GHOST（Lastest Message Driven GHOST）
5. For each slot i, after receiving the block (B_i) of slot i or waiting for 3s, the remaining Validators in Si except proposer_i publish a head of the current chain in his view.
So far, we have introduced how Casper produces blocks and Validator's voting process for candidate blocks. It should be noted that it is mentioned above that the Validator needs to vote for the head of the chain in its view. Ethereum 2.0 uses a new optimal chain selection algorithm to select the head of the chain.
Before introducing this new optimal chain selection algorithm, let us recall the optimal chain selection algorithm of Ethereum 1.0 - GHOST. The main idea of the GHOST algorithm is that for a blockchain, many forks will be generated due to time delay and the existence of malicious nodes. When a fork is found, the maximum total Difficulty of the subtree is selected as the optimal chain, as shown in Figure 4 :
image description
The chain forks at the red point, assuming that the Difficulty of each block is the same as 1, the total Difficulty of the blue subtree is 8, and the total Difficulty of the purple subtree is 4, so choose blue as the point on the optimal chain .There is no problem with the GHOST protocol in the PoW protocol, but the PoS protocol is naturally affected by the Lang Range attack, that is, the attacker can use a small amount of funds to purchase an account that once had a large amount of stake but is currently empty, go back to the past, and carry out the transaction in the past position. The fork generates a large number of illegal blocks, and the GHOST protocol will not be able to guarantee the security of the system. As shown in Figure 5:
image description
Figure 5: Lang Range
The attacker generates a yellow block in the past position, the total Difficulty of subtree B is 10, and the purple block will become the point on the optimal chain. Although tokens need to be mortgaged before voting, after redeeming their own tokens, attackers can act recklessly in the validator epoch without worrying about token confiscation.
Therefore, in order to solve this problem, Ethereum 2.0 designed a new algorithm - LMD GHOST (Lastest Message Driven GHOST). The main idea of LMD GHOST is, for a chain with a fork, when it encounters a fork point in the process of finding the head of the chain, select the subtree that supports more Validators in the current epoch. The main process of the agreement is:
2、M=[M1,…,For a chain with a fork:
1. H is equal to the creation block;
Mn] is the latest news from Validator;
3. Select the child node with the most support in M, and set it to H;
Although the use of LMD GHOST is to solve the Long Range attack, the author believes that buying the previous account is equivalent to going back in time and forming a new parallel universe. When a new user enters, facing two forked chains without using In the case of additional information (checkpoint), it is difficult to determine which chain is constructed by the attacker, so LMD GHOST cannot completely resist Long Range attacks.
So far we have introduced how Casper in Ethereum 2.0 produces blocks, and the next part is how to finalize the candidate blocks.
secondary title
block confirmation
In the previous article, we explained the justified and finalized checkpoints, and the nodes before the finalized checkpoint are finally confirmed. In a nutshell, Casper in Ethereum 2.0 regards each epoch as a checkpoint, and attestation votes on the checkpoint to determine the justified and finalized status of the checkpoint. The core logic of determining justified and finalized is similar to that described above. Next, let's explain how the block enters the justified and finalized states.How to justify block
Now Casper divides an epoch into 64 slots. The last slot is called epoch_boundary_slot, and its hash is written as epoch_boundary_hash to represent an epoch, and an epoch is regarded as a checkpoint. Let the chain maintain a map, we call it justified_hashes, the storage format is. Add two fields epoch_boundary_hash (the hash of the block with the smallest slot in the previous epoch) and latest_justified_hash (the hash of the latest block in the justified_hash epoch referenced by epoch_boundary_hash) to the attestation of the Validator, only when the latest_justified_hash in the attestation is equal to the slot in justified_hashes Only with the latest hash, this attestation is legal.
The chain keeps track of the latest justified hash, so choosing the same epoch_boundary_hash will vote for the same latest_justified_hash. Now let's see how the state transitions during an epoch boundary. Suppose for a chain, the epoch_boundary_block B1, B2, B3, B4 of the last 4 epochs, where B4 is the latest epoch_boundary_block of the epoch, and their slots are written as B1_slot, B2_slot, B3_slot, B4_slot, B3_slot = B4_slot - 64, etc. If more than 2/3 of the Validators choose B4 as the epoch_boundary_block, then put
Added justified_hashes.
The condition for an epoch_boundary_block to become justified is that more than 2/3 of the Validators point to the block in their attestation epoch_boundary_hash, when a block is included in justified_hashes, the block is justified, and the state that proves that the block is already justified is recorded in the chain superior.
How to finalize a block
After confirming the justified state, the next step is to determine how to make the block enter the finalize state.
If B4 and B3 are in justified_hashes, the attestation that votes for B4 as epoch_boundary_block selects B3 as latest_justified_hash and finalizes B3.
If B4, B3, and B2 are in justified_hashes, vote for B4 as the attestation of epoch_boundary_block, select B2 as latest_justified_hash, and finalize B2.It can be compared to the previous article, the Validator's vote is
, you can regard epoch_boundary_block as h(t) and latest_justified_hash as h(s), which makes it easier to understand the confirmation process of the block.
other little things
penalty condition
For the complete operation of Casper, there are still some small things that need to be resolved. Since the space is relatively short, let's put it together.
penalty condition
In order to defend against noting at stake attacks, users mortgage tokens to become Validators for PoS. When Validators operate illegally, their mortgaged tokens will be confiscated to prevent bad actors from doing evil. Validator's penalty conditions are:
1. The same Validator cannot issue two different attestations in the same epoch. 2. The same Validator cannot issue two attestations, their epoch_boundary_blocks are t1 and t2 respectively, latest_justified_hash is s1 and s2, and s1
This penalty condition is the same as the penalty condition in the previous article.
Validator replacement conditions
dynasty(B) indicates the number of finalized epochs from block B to the genesis block. 1/64 Validator can be replaced between two dynasties.
Fork selection condition
