Ethereum 2.0: The Journey of a Beacon Chain Validator
Editor's Note: This article comes fromBlue Fox Notes (ID: lanhubiji)Editor's Note: This article comes from
, author Alex T, translator SIEN, reprinted with authorization by Odaily.
Preface: The core of Ethereum phase 0 is the beacon chain, which is responsible for coordinating the Ethereum network. As a validator, how does Ta participate in the ETH2.0 network? This article briefly explains the validator's participation process from the perspective of the validator, which is very suitable for readers who want to become a validator of the ETH2.0 network.
image description
(Fork choice, from Oliver Roos)
This article attempts to explain in simple terms how the beacon chain works. In ETH2.0, the beacon chain is the backbone of the entire network, coordinating everything in a very complex way, so the following explanations are intentionally simplified a lot. For the sake of simplicity, I will mainly consider the case where the network and validators are working normally, and ignore most of the malicious behavior that will undoubtedly occur. Things such as fines, reductions, orphaned blocks, and reorganization are not described here for the time being, and will be listed later.
The beacon chain is a blockchain, essentially, a chain of blocks connected together, but with a few surprises.
Our journey begins with an unknown hero who is the Validator. The verifier locks its 32 ETH "small treasury" 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 validators can go, a few prerequisites are required. Ideally, validators have access to ETH1.0 nodes and beacon chain client nodes, both of which are synced.
Once our hero (blue fox notes: here refers to the validator) deposits his ETH into the pledge contract, his journey to ETH2.0 begins. Part of the storage process is that he gets public keys, hot and cold private keys for his beacon chain's ETH. Through a browser, the public key can be used to view validator status and activity. Hot private keys are used for voting and proposals, while cold private keys should be stored offline as it is the golden key which allows you to access your ETH in the future.
One very important thing to note here is that once you send the deposit, you must keep the validator client running until you stop being a validator. In Phase 0, if you exit, you will not be able to rejoin as a validator, nor will you be able to transfer funds. Otherwise, you will lose ETH. (Blue Fox Notes: This tip is very important, you must ensure the normal operation of the verifier client to avoid losses)
The second step for the verifier is to wait about 7.5 hours (currently 1024 ETH1.0 blocks and 1024 ETH2.0 slots) to ensure that the stored transaction 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 up beacon chain client.
Once the wait is over, the stored funds are recognized by the beacon chain, and validators are added to the activation queue. In this queue, it can be assumed 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 at which a block can be produced. Ultimately this is a blockchain, so at some point we have to generate blocks. Empty slots can exist, and they are called skip slots.
To keep things organized, slots are grouped together, 32 slots at a time in an epoch. This decentralizes some of the operations that beacon chain clients need to do, which in turn should reduce the computational burden on the computers running said clients.
After queuing in the queue, the validator is finally activated. Validators get a roster before each epoch begins. In this roster, he will see that each epoch, along with some of his peers, he needs to vote on which blocks to include into a slot. At some epoch, 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 (using a special form of random number generation) elects a validator to propose blocks.
It also takes the entire available pool of validators, divides them into slots per epoch, and then further divides them into the aforementioned groups, aka committees. Committees can pool their votes together. Finally, for each epoch, each validator needs to vote once as directed, and if selected, will need to propose a block.
Returning to our protagonist, the Verifier, we find that his life is rather monotonous. As I mentioned, he spends many epochs asking the beacon chain client what he needs to do each epoch before trying to do it. Then every epoch he needs to vote (also called to prove or to confirm) so that the blocks proposed by others are included. It performs actions in good faith, taking into account all available information. And, generally speaking, just looking at a proposed block with the correct information is an easy task.
Every now and then something exciting happens and our validators are chosen to propose blocks. Once the corresponding slot comes up, it looks from the network to see what it can see, what the last block was (also known as the network header) and can see the validations on the network waiting to be included in the block. It then packs all this information into a new block, which it then sends to the network.
The more information it gathers and sends faster, the more potential rewards it can receive if the block is included in the canonical chain. After committing that block, assuming everything is correct, it will see the block validated by other peers in subsequent blocks through the number of proofs received.
After an epoch ends, the beacon chain also issues ETH to validators who have performed their duties correctly. Some of it goes to people who vote, and a larger part goes to people who propose blocks. However, people can also be fined for failing to complete tasks correctly. Worse, if validators behave maliciously, or because of technical difficulties, such as proposing two blocks in the same slot, they will be slashed, which means more funds will be lost. was kicked out.
The blockchain is built block by block. 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, since things in the real world are not fairy tales, things like network latency can cause a lot of problems because not all validators are the same. The delay means that some validators can see some proposed blocks, while others may not.
To solve this problem, a powerful entity called "fork choice" must be introduced in the validator client. Its purpose is somewhat similar to that of a judge. At each slot, it checks all the available information it has, and if there are multiple options considering the history of the chain, it tries to choose one of them, the one with the most votes going back to the moment of construction. This mechanism ensures that it has only one canonical chain, but it has a side effect called reorganization that may reorganize the chain for a short period of time. When a reorganization occurs, rewards and penalties change to reflect the new chain's history and duties performed.
An epoch is considered a valid part of the chain if at least two-thirds of the total validator pool voted for the same block to represent the beginning of an epoch.
Rationality provides a reasonable certainty that the chain will not change through reorganization. To ensure that the chain does not change, an epoch is considered final when a succession of other epochs has been proven and built on top of it. In other words, a final epoch is a proven epoch, and its child epochs are also proven.
In summary, this is the journey for a Beacon Chain validator:
Sync Beacon Chain Clients
Send 32 ETH deposit to the storage contract
Start the validator client
Wait until the pledge deposit is confirmed and added to the validator activation queue
Run and make sure the validator client keeps running:
-Voting/attesting to blocks for inclusion on-chain
- Propose new blocks when asked
Earn $$$
This article briefly touches on or ignores the following topics, which would require a dedicated article:
*Random number generation—RANDAO
*Fork selection rules—Casper FFG
*finality
* Reward and penalty calculation method
*reduction
* Validator lifecycle, including voluntary and forced exit
