Verified: Staking on eth2 #0

adminJanuary 12, 2024

Thanks to Danny and Joe for the review.

As the launch of the beacon chain gets closer and eth2 becomes more finalized, the time has come to quickly synchronize the community with up-to-date information about the inner workings of eth2 and the specific requirements, incentives, and experience of being a validator. This article provides a high-level overview of eth2 that will form the basis of a series on all aspects of eth2 related to validators. eth2 has been in the works for a long time and has improved dramatically over the years. Initially separate sharding and proof-of-stake (PoS) efforts managed through smart contracts, they have transformed into a highly interconnected design that delivers dramatic improvements in efficiency, scalability, and security.

step

As parts of eth2 became more interconnected, other parts became separated: step Allows better pipeline for various aspects of eth2. As of this writing, Phase 0 release is approaching as developers finalize the client software. Meanwhile, the specifications for the first phase have been completed, and active research and development is in progress for the second phase.

Step 0 have an interest in beacon chain, the core of eth2 that manages validators and shard coordination. The beacon chain is the source of ground truth from which all other aspects of eth2 are bootstrapped.
Level 1 It builds on this by allowing data to be put into shards. Because most of the groundwork for the shards is done in phase 0, the implementation complexity of this component is much less than that of the other components.
Step 2 It adds execution to eth2, essentially upgrading eth2 from a powerful database to a fully distributed computing platform.

What exactly is stage 0?

As previously mentioned, the beacon chain tracks the state of both the validator set and the shards. In practice, this means that if you (periodically) track what’s happening on the beacon chain, you’ll know enough to verify everything that’s known to be happening within eth2. Trust, but verify.

For a PoS system to work, there needs to be agreement on who the validators are and what each stake is. This allows us to determine the value of a vote and reward and/or punish it appropriately. action. The beacon chain also manages the sharding aspect of eth2 by assigning validator duties to shards and tracking the current state of each shard.

One of the ways that eth2 differs from other PoS systems is the number of validators that can participate in the protocol. Unlike the 10s, 100s, or 1000s of participants possible in other systems, eth2 scales to hundreds of thousands or even millions of validators. This level of decentralization is possible due to the intermediate level of consensus achieved by the group of validators. Committee. The beacon chain uses an eponymous random beacon at its core to assign validators to a committee whose job it is to evaluate whether a beacon is part of a shard chain or not. The committee’s votes are cryptographically tabulated. proof This means that verifying the vote of the entire committee requires slightly more effort than verifying a single vote. Therefore, to verify the validity of a beacon chain, you only need to evaluate the votes of many validators, considering only a small number of aggregated signatures.

The beacon chain also tracks the eth1 chain and its accompanying deposits, so a new validator can join eth2 by sending 32 Ether to eth1’s deposit contract. As a result of the beacon chain voting on the eth1 chain, eth2 will strengthen the security of eth1 by providing economic guarantees for blocks that are part of the standard eth1 chain at some point in the future.

Node to Client

eth2 distinguishes between beacon nodes and validator clients, and validators need both to perform their duties. all beacon node (or just word) is interested in maintaining a view of the beacon chain and the shards that users or validators may need.

As their name suggests, Validator Client (or just Client) handles the logic of a single validator. This is achieved by communicating with the beacon node to understand the current state of the chain, proving and proposing blocks when appropriate, and finally asking the beacon node to send this information to its peers.

If you are not running a validator, the beacon node contains all the information needed for trustless interaction with eth2, just like a full node on eth1.

Kalymg 1

Here are some of the many arguments for this separation:

Each validator must start with a deposit of exactly 32 Ether, so those looking to stake more ETH will need to run multiple validator instances. Node-client separation allows these users to run only a single beacon node with multiple validators connected, reducing computation, memory, and storage requirements.
Having the validator nodes as separate modules is likely to be more secure because smaller code modules are easier to write, reason about, and audit.
Especially for users concerned about redundancy, the ability to run multiple nodes in parallel reduces the chance of a validator going offline.
Since validator clients can only interact with the rest of the eth2 network through beacon nodes, even Limited APIThe attack surface of validator nodes is greatly reduced.
For users who want to interact with eth2 but do not want to be a validator, they only need to run a beacon node, which gives them access to the beacon chain and all the necessary shards.

design philosophy

The design philosophy of eth2 provides useful context for all decisions made within eth2 and, in many cases, summarizes the differences between eth2 and other protocols.

Protocol for everything: Recognizing that it’s all a trade-off ensures that the safety and liveness of the protocol take precedence over other design requirements.
Hope for the best but expect the worst: eth2 assumes that validators are lazy, take bribes, and will attempt to attack the system unless otherwise incentivized. Furthermore, we assume that the network is not fully trustworthy and that a catastrophic event could cause a large number of validators to go offline. For this reason, eth2 should be able to survive World War III.
Minimum viable complexity: eth2 has been simplified where possible. This allows you to reason, explain things to others, audit them, write bug-free clients, and generally avoid edge cases.
Maximally decentralized: Proof-of-stake protocols typically compromise on the number of validators that can participate. eth2 is designed to scale to millions of validators while encouraging validators to work independently of each other.
Expect the unexpected: All components of eth2 are resistant to quantum computers or can be replaced by other components in the event of a quantum apocalypse.
By people for people: eth2 should be able to run on consumer laptops. The lower the barrier to entry, the more people can participate, which translates into a higher level of decentralization.