ETH2.0 is coming, don't you know Casper yet?

At the beginning of this year, Ethereum underwent an upgrade to Constantinople. With the upgrade, when Ethereum can switch to PoS has once again become a question that everyone is eager to pay attention to. As we all know, the PoW algorithm has a lot of waste of resources, concentration of computing power and other problems. Ethereum has been trying to switch to the PoS algorithm since 2017. However, due to various objective conditions, there has been no substantive development. After letting the majority of blockchain enthusiasts dove for several years, Ethereum 2.0 is finally going to use the PoS algorithm. In line with the traditional Chinese virtue that being happy alone is worse than being happy with others, Fractal craftsmen decided to share with you our views on the next generation of Ethereum consensus protocol - Casper.

secondary title

Casper FFG ——PoW+PoS

Casper actually has two versions, one is Casper FFG led by Vitalik, and the other is Casper CBC led by Vlad. The difference between them is that FFG is more of a transition protocol, enabling Ethereum to successfully transition from PoW to PoW. PoS; and CBC is a better version after Ethereum switched to PoS, but from the current point of view, there are still many details of CBC that need further research and discussion.

The main idea of ​​FFG is to use PoS to help the final confirmation of blocks generated by PoW, thereby improving the security of the system while reducing miner rewards.

image description

Figure 1 block compressed into checkpoint

image description

Figure 2: Checkpoint height function

First, we describe the Casper consensus process as a whole. Validators participating in the consensus will vote on the checkpoints described above. Each Validator casts a checkpoint, starting from the justified checkpoint to a checkpoint after several checkpoints. We stipulate that the first justified checkpoint is the genesis block. When a checkpoint receives more than 2/3 of the votes from the justified checkpoint to it, then this block becomes justified.

secondary title

Validator vote

in:

vote=

in:

v : Validator's identity information;

s : the hash of any justified checkpoint, which can be understood as the source checkpoint. We will explain in detail the definition of justified later;

t : the hash of any descendant node, which can be understood as the target checkpoint;

h(s) : the height of s;

secondary title

Two relations of checkpoint

After defining the voting rules, define the relationship between any two checkpoints:

supermajority link: For a pair of checkpoints (a, b), write (a→b), if there are more than 2/3 validator votes vote=, it can be called (a→b) is a supermajority link, and h(b) ≥h(a)+1

image description

Figure 3: Schematic diagram of Casper structure

secondary title

Checkpoint two states

After defining the relationship between checkpoints, define the two states of checkpoint—c:

-c is justified:

1) c = root: checkpoint c is the root;

2) or exist (c'→c), that is, the supermajority link from c' to c, and c' is justified;

-c is finalized:

a) c is justified;

b) There is (c'→c), the supermajority link from c' to c;

        c） c , c' not conflicting；

        d） h(c')=h(c)+1；

punishment mechanism

punishment mechanism

In order to prevent the Validator from doing evil during the running process, Casper has formulated a set of punishment mechanisms as follows: For the same Validator, two different votes are issued =and vote=, if the following two situations exist, the stake of the mortgage will be penalized.

1. h(t1)=h(t2): For the same target height, two different votes cannot be initiated.

2. h(s1)

image description

secondary title

Fork selection mechanism

In order to allow PoS to improve the security of the PoW chain, FFG made some modifications to the heaviest chain when choosing a fork: first find the justified checkpoint with the highest height in the view, and block after the checkpoint The heaviest chain selection was performed on . This has two advantages. The first one is that compared with the original ghost algorithm, block confirmation is probabilistic. After waiting for a sufficient height, there is only a very low probability of overturning the previous block, although the probability It is very low, but there is still this possibility; as long as the blocks in FFG are before finalized, they are all confirmed, and there is no possibility of being overturned.

secondary title

Validator replacement

As we said at the beginning, it is assumed that the Validator is fixed, but a real blockchain system must be able to allow participants to enter and exit freely, so FFG has its own set of Validator entry and exit principles. First, define the dynasty of block b as: the number of finalized checkpoints between the founding block and the parent block of b.

mortgage:

A user who wants to become a Validator needs to mortgage a certain amount of stake. When the mortgage transaction of user v is included in a block with dynasty=d, then define a Start Dynasty and write SD(v) = d+2.

redemption:

If Validator v wants to get back the pledged stake, it needs to initiate a redemption transaction. When this transaction information is included in a block with a dynasty, then define an End Dynasty and write ED(v) = +2. In order to avoid dealing with multiple SD and ED, a user cannot stake to become a Validator after redemption. At the same time, in order to prevent the bad guys from redeeming the stake immediately after doing evil, the stake still needs to be locked for a certain period of time after the redemption transaction is executed.

For a block b, assuming its dynasty is d, only validators whose d is between ED and SD can vote.

The introduction of this article ends here. If you have any doubts, you can join the official Fractal group discussion. Fractal technicians will answer your questions online. In the next article, we will introduce the main features of Casper that will be used in Ethereum 2.0. agreement process.