Ethereum 2.0: The journey of beacon chain verifiers

Foreword: The core of Ethereum phase 0 is the beacon chain, which is responsible for coordinating the Ethereum network. As a verifier, how does Ta participate in the ETH2.0 network? This article succinctly explains the participation process of the verifier from the perspective of the verifier, which is very suitable for readers who want to become an ETH2.0 network verifier. The author is Alex T, translated by “SIEN” of “Blue Fox Notes”.

This article attempts to explain in simple language how the beacon chain works. In ETH2.0, the beacon chain is the backbone of the entire network, coordinating everything in a very complicated way. Therefore, the following explanation is intentionally simplified. For the sake of simplicity, I will mainly consider how the network and validators work, and ignore most of the malicious behavior that undoubtedly occurs. Things such as fines, reductions, orphans, reorganizations, etc. are not described here, and will be shown later.

The beacon chain is a blockchain, in essence, a chain of connected blocks, but there are some surprises.

Our journey begins with an unknown hero, Ta is the verifier. The validator locks his 32 ETH “small vaults” into the pledge contract on the current ETH1.0 network in order to actively participate in the ETH2.0 network by running the verifier node.

Before the verifier can set off, some prerequisites are required. Ideally, the validator has access to the ETH1.0 node and the beacon chain client node, both of which have been synchronized.

Once our hero (Blue Fox Note: here the verifier) ​​deposited his ETH into the pledge contract, his ETH2.0 journey began. Part of the stored process is that he obtained the public key, hot and cold private key for the ETH of his beacon chain. Through a browser, the public key can be used to view certifier status and activity. The hot private key is used for voting and proposals, and the cold private key should be stored offline because it is a golden key, which allows you to access your ETH in the future.

It should be noted that there is a very important thing here. Once you send the deposit, you must ensure that the validator client is running until you stop becoming a validator. In Phase 0, if you quit, you will not be able to rejoin as a validator and you will not be able to transfer funds. Otherwise, you will lose ETH. (Blue Fox Note: This tip is very important, be sure to ensure the normal operation of the validator client to avoid losses)

The second step for the validator is to wait about 7.5 hours (currently 1024 ETH1.0 blocks and 1024 ETH2.0 slots) to ensure that the stored transactions cannot be reversed. The validator uses this time to set up an available validator client, add the hot private key and connect it to the previously set beacon chain client.

Once the wait is over, the stored funds are identified by the beacon chain and validators are added to the activation queue. In this queue, you can guess that we will continue to wait, depending on how many other validators are in the queue. There are now 327,680 active validators, and only 4 validators can be active per epoch.

To understand epoch, you need to understand what a slot is. A slot is a 12-second interval and can produce one block. Ultimately this is a blockchain, so we have to generate a block at some point in time. Empty slots can exist, and they are called skip slots.

In order to ensure that things are in order, the slots are grouped together, 32 slots at a time in one epoch. This decentralizes some operations that the beacon chain client needs to do, which in turn should reduce the computational burden of the computer running the client.

After queuing in the queue, the validator is finally activated. Before each epoch begins, the validator gets a roster. In this roster, he will see each epoch, along with some of his peers, he needs to vote on which blocks to include in a slot. At some epochs, he sees that he is also responsible for proposing blocks for slots, while others can vote.

Before each epoch, each slot of the beacon chain (generated using a special form of random number) selects a validator to propose a block.

It also takes the entire pool of available validators, divides them into the number of slots per epoch, and then further divides them into the aforementioned group, which is the committee. The committee can put together its votes. Finally, for each epoch, each validator needs to vote once as directed, and if selected, will need to propose a block.

Going back to our protagonist, the Validator, we find that his life is quite monotonous. As I mentioned, he spent a lot of epochs asking the beacon chain client what he needs to do before each epoch, and then try to execute it. Then for each epoch he needs to vote (also known as proof or confirmation) so that the blocks proposed by others are included. With all the information available, it will act in good faith. And, in general, looking at only one proposed block with the right information is a simple task.

Something exciting happens from time to time, and our validators are chosen to propose blocks. Once the corresponding slot appears, it will check what can be seen from the network, what the previous block was (also known as the network header), and can see on the network waiting to be included in the block for verification. It then packs all this information into a new block and sends it to the network.

The more information it collects and the faster it sends, the more potential rewards it can receive if the block is included in the canonical chain. After submitting the block, assuming everything is correct, with the number of proofs received, it will see that the block is verified by other peers in subsequent blocks.

After the end of an epoch, the beacon chain also issues ETH to validators who perform their duties correctly. Some of them are sent to people who voted, and much more to people who propose blocks. However, people can also be fined if they fail to complete their tasks properly. To make matters worse, if validators, because of malicious behavior or technical difficulties, cause things such as proposing two blocks in the same slot, they will be reduced, which means that more funds will be lost and the chain will lose Was kicked out.

The block chain is constructed one by one. By using the last available block as the parent block, each block looks at the block in the previous slot and anchors itself to the chain. However, because things in the real world are not fairy tales, things such as network latency can cause many problems because not all validators have the same situation. Delay means that some validators can see some proposed blocks, while others may not.

To solve this problem, a powerful entity called “forked selection” must be introduced in the validator client. Its purpose is somewhat similar to that of a judge. In each slot, it checks all the available information it has, and if there are multiple options for the history of the chain, it will try to choose one of them, choosing the one that has the most votes back to the time of construction. This mechanism can ensure that it has only one canonical chain, but it has a side effect called reorganization, which may reorganize the chain in the short term. When the reorganization occurs, the rewards and punishments will also change to reflect the history of the new chain and the duties performed.

If at least two-thirds of the votes in the total validator pool agree that the same block represents the beginning of an epoch, then that epoch is considered a valid part of the chain.

Rationality provides a reasonable certainty, that is, the chain will not change through reorganization. In order to make sure that the chain will not change, when a continuous other epoch has been proven and established on it, the epoch will be considered final. In other words, a final epoch is a proven epoch, and its son epoch is also proven.

Overall, this is the journey of the beacon chain verifier:

* Sync beacon chain client

* Send a 32 ETH deposit to the storage contract

* Launch Validator Client

* Wait until the pledged deposit is confirmed and added to the validator activation queue

* Run and ensure that the validator client is running continuously:

-Vote / proof the block to include it on the chain

-Propose new blocks when requested

* Get income

This article briefly mentions or ignores the following topics, all of which need to be addressed in specialized articles:

* Generation of Random Numbers—RANDAO

* Fork Selection Rules—Casper FFG

* Finality

* Reward and penalty calculation method

* Subtraction

* Verifier life cycle, including voluntary and forced withdrawal

* Anything related to Phase 1+

* Any technical content, such as BLS signature, SSZ code or data structure ——

Source: BlueFoxNote

Risk Warning: All articles you read here cannot be used as investment advice or recommendation. Investment is risky. Investment should consider personal risk tolerance. Make in-depth inspections of the project and make your investment decisions carefully.


Please enter your comment!
Please enter your name here