In the previous article, 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 just a transitional scheme. In Ethereum 2.0, a pure POS Casper protocol will be used. In this chapter, we will introduce the Casper protocol to be used in Ethereum 2.0.
How to be a validator
First, let’s look at the architecture of Ethereum 2. As shown in Figure 1, there will be a main chain called Beacon chain in Ethereum 2, which is generated through the Casper of PoS. In the beacon chain, there are 1024 segments, each of which can process data independently.
Figure 1 Ethereum 2.0 architecture
As can be seen from Figure 1, Ethereum 2.0 and Ethereum 1.0 will be two chains. After the 2.0 sharding implementation, 1.0 will continue to operate as a shard of Ethereum 2.0. In the previous article, we introduced that we can participate in the POS consensus by pledging to become a validator. In order to make Ethereum smoothly transition to 2.0, how to become a validator in Ethereum 2.0 by pledging to be a stay in Ethereum 1.0 is an important problem that Casper needs to solve.
In Ethereum 2.0, the original user can become a validator by pledging eth in Ethereum 1.0, participate in POS of 2.0, and retrieve tokens in Ethereum 2.0 through redemption operation. It should be noted that the tokens in Ethereum 1.0 and 2.0 are not the same. Users mortgage eth in 1.0 (burn ETH), and redeem tokens in 2.0 (cast new token).
To become a validator, users need to send a transaction to a special contract in Ethereum 1.0 to pledge a certain number of eth (currently the minimum value is 32eth), and then users will get a proof of the transaction. By showing this proof to Ethereum 2.0, the user becomes a validator after the validation, as shown in Figure 2:
Figure 2 the process of pledging eth in Ethereum 1.0 to be a validator in Ethereum 2.0
In order to verify the correctness of the user’s mortgage transaction, the block information in the current Ethereum 1.0 and the root hash of Merkle formed by all transactions in the mortgage contract need to be saved in Ethereum 2.0. The user can verify the validity of the transaction by showing the mortgage transaction to Ethereum 2.0 and the proof of the mortgage transaction to the complete Merkle tree. Authenticated users become validators in Ethereum 2.0.
The blocking process of capser in Ethereum 2.0
In the previous article, we introduced Casper to generate blocks through POW and use POS to determine the blocks finally. Therefore, a problem that needs to be solved for pure POS Casper is how to generate blocks. Before we formally introduce the agreement process, we will clarify several definitions:
Validators set: v = V1 VN, assuming that each validator has the same stack;
Slot: basic time unit, currently set as 6S;
Epoch: 64 slots make up an epoch;
Random number generator: generate a random number as required;
After defining the above definition, we will further describe the process of capper block generation in Ethereum 2.0, as shown in Figure 3.
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. The set V of validator is divided into 64 parts on average, and 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 submits the validator of the candidate block in slot I to write a proposer_ i. Submitted candidate block writing B_ i。
3. For each slot I, divide the proposer in Si_ The remaining validators outside I are for B_ I vote, which is written as attachment.
4. In each slot I, the proposer_ I is responsible for packing the attachment information in the previous slot into the candidate blocks of the current slot. Namely
5. For each slot I, divide the proposer in Si_ The remaining validators outside of I receive the block (b) of slot i_ i) Or after waiting for 3S, it publishes the head of a current chain in his view.
LMD GHOST（Lastest Message Driven GHOST）
At this point, we have introduced how Casper produces blocks and validator’s voting process for candidate blocks. It should be noted that as mentioned above, 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’s recall the optimal chain selection algorithm of Ethereum 1.0 – Ghost. The main idea of ghost algorithm is that for a blockchain, there will be many bifurcations due to time delay and the existence of malicious nodes. When the bifurcations are found, the total difficultly maximum of the subtree is selected as the optimal chain, as shown in Figure 4:
Figure 4 ghost protocol
The chain branches 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 blue is selected as the point on the optimal chain.
Ghost protocol has no problem in POW protocol, but it is naturally affected by Lang range attack. That is to say, an attacker can purchase a large number of accounts that once owned a large number of sticks but are currently empty through a small amount of money. Back in the past, a large number of illegal blocks will be generated by branching in the past location, and ghost protocol will not guarantee the security of the system. As shown in Figure 5:
Figure 5: Lang range attack
The attacker generates yellow blocks in the past position, the total diffficulty of subtree B is 10, and the purple block will be the point on the optimal chain. Although the token needs to be mortgaged before voting, after redeeming his own token, the attacker can act recklessly in his epoch, which is still the validator, without fear that the token will be confiscated.
Therefore, in order to solve this problem, Ethereum 2.0 has designed a new algorithm, LMD ghost (last message driven ghost). The main idea of LMD ghost is to select the subtree that the validator supports in the current epoch when it meets the bifurcation point in the process of finding the head of a chain with bifurcation. The main process of the agreement is:
For a chain with branches:
1. H is equal to the genesis block; 2、M=[M1,… , Mn] is the latest news of validator; 3. Select the child node with the most support rate in M and set it to h; 4. Repeat steps (2-3) until there is no child node;
Although LMD ghost is used to solve the long range attack, the author believes that buying a former account is equivalent to time reversal, forming a new parallel universe. When a new user enters, it is difficult to determine which chain is constructed by the attacker in the face of two branching chains without using extra information (checkpoint), so LMD ghost cannot completely resist long Range attack.
So far, we have introduced how Casper in chain Ethereum 2.0 can generate blocks. Next, we will see the final part, how to confirm the candidate blocks.
In the previous article, we explained the adjusted and finalized checkpoint, and the nodes before the finalized checkpoint were finally confirmed. Generally speaking, Casper in Ethereum 2.0 regards each epoch as a checkpoint, and the attachment votes on the checkpoint to determine the adjusted and finalized state of the checkpoint. The core logic of the adjusted and finalized is similar to that described above. Next, let’s show how the block enters the adjusted and finalized states.
How to justify block
Now Casper divides an epoch into 64 slots. The last slot is called epoch_ boundary_ Slot, write epoch with its hash_ boundary_ Hash represents an epoch, and treats an epoch as a checkpoint. Let the chain maintain a map. We call it justified_ Hashes, the storage format is < slot, hash >. Add two fields epoch to the attachment of validator_ boundary_ Hash (hash of the block with the smallest slot in the previous epoch) and latest_ justified_ hash（epoch_ boundary_ Adjusted in hash reference block_ Hash epoch the hash of the latest block), only when the latest in the attachment_ justified_ Hash equals justified_ The latest hash of slot in hashes. This attachment is legal.
The chain will track the latest adjusted hash, so choose the same epoch_ boundary_ Hash will vote for the same latest_ justified_ hash。 Now let’s see how the state changes in an epoch boundary. Suppose for a chain, the epochs of the last four epochs_ boundary_ Block B1, B2, B3, B4 where B4 is the latest epoch_ boundary_ Block, their slot writing B1_ slot, B2_ slot, B3_ slot, B4_ slot, B3_ slot = B4_ slot – 64, etc。 If more than 2 / 3 of validators choose B4 as the epoch_ boundary_ Block, put < B4_ Slot, hash (B4) > Add justified_ hashes。
An epoch_ boundary_ The condition for block to be justified is that more than 2 / 3 of validators in its attachment epoch_ boundary_ Hash points to the block, when a block is included in justified_ Hashes indicates that the block is justified, and the state of proving that the block has been justified is recorded on the chain.
How to finalize block
After confirming the status of justified, the next step is to determine how to put the block into the finalize state.
If B4 and B3 are in justified_ In hashes, vote for B4 as epoch_ boundary_ Select B3 as the latest for the attachment of block_ justified_ hash，finalize B3。
If B4, B3, B2 are in justified_ In hashes, vote for B4 as epoch_ boundary_ Block’s attachment selects B2 as the latest_ justified_ hash，finalize B2。
If B3, B2, B1 are in justified_ In hashes, vote B3 as epoch_ boundary_ Select b1 as the latest for the attachment of block_ justified_ hash，finalize B1。
It can be compared with the previous article that the validator’s vote is < V, s, t, H (s), H (T) > and the epoch_ boundary_ Block as H (T), latest_ justified_ Hash is regarded as H (s), which makes it easier to understand the confirmation process of block.
Other little things
For Casper’s complete operation, there are still some small things to be solved. Because of the short space, let’s put them together.
In order to resist the noting at stake attack, users use the mortgaged token to become validator for pos. when validator operates illegally, the mortgaged token will be confiscated to prevent villains from doing evil. Validator’s penalty conditions are:
1. The same validator cannot issue two different attachments in the same epoch.
2. The same validator cannot issue two attachments, their epoch_ boundary_ Block T1 and T2, latest_ justified_ The hash is S1 and S2, and S1 < S2 < T2 < T1.
This penalty condition is the same as that in the previous article.
Validator replacement conditions
Dynasty (b) indicates the number of finalized epoch from block B to the genesis block. A 1 / 64 validator can be replaced between two Dynasts.
Bifurcation selection conditions
Start with the latest finalized block and run LMD ghost.
This series of articles about Casper in “truth seeking blockchain” is over. If you feel confused, you can scan the QR code below to join the community discussion, and fractal’s technicians can solve the problem online.