Popular Science: How to Participate in ETH2 Staking
First of all thanks to Danny and Joe for their assistance.
With the release of the beacon chain approaching, eth2 is getting closer and closer to a foregone conclusion. Now is the time to quickly synchronize with the community the latest eth2 inner workings and the specific requirements, incentives, and experience of becoming a validator. This article will give an overview of eth2 from a high level, and a series of articles related to various aspects of eth2 validators will be released in the future. This article is only a basic beginning.
While preparations for eth2 have been underway for a long time thus far, tremendous progress has also been made over the years. Originally, the sharding technology and Proof-of-Stake (PoS) mechanism governed by smart contracts were independently designed, but now they are highly interconnected and have achieved significant improvements in efficiency, scalability, and security.
Various stages of eth2
As the components of eth2 become more closely connected, other parts are divided into phases to better tease out the content of the different parts of eth2. At the time of writing, Phase 0 is about to start as the client software development is coming into its final stages. At the same time, the specification of phase 1 has been formulated, and the specification of phase 2 is under active research and development.
The content of phase 0 is the beacon chain, and the beacon chain is the core of eth2, which can manage verifiers and coordinate shard chains. The beacon chain serves as the practical foundation that guides the development of all other aspects of eth2.
The implementation of phase 1 is based on phase 0, and the main content is to write data into the shard chain. Since Phase 0 lays most of the groundwork for the shard chain, Phase 1 is implemented with much less complexity than the other components.
Phase 2 is the implementation phase of eth2, basically upgrading eth2 from a powerful database to a fully decentralized computing platform.
What exactly is Phase 0?
As mentioned earlier, the beacon chain is able to track the validator set and the state of the shard chain. In practice, this means that users will have enough information to verify anything happening in eth2 if they (regularly) track activity on the beacon chain. Further verification based on trust.
In order for a PoS system to function properly, it needs to reach a consensus on who the validators are and how much each validator stakes, so that they can know how much their voting weight is, and reward and punish them appropriately according to their behavior. The beacon chain also manages eth2's shard chains by assigning validator responsibilities among shards and tracking the current state of each shard.
Part of the difference between Eth2 and other PoS systems is the sheer number of validators participating in the protocol. The number of validators in other PoS systems may be tens, hundreds, or thousands, while the number of validators in eth2 will be hundreds of thousands or even millions. This level of decentralization is made possible by the intermediate consensus achieved by groups of validators, or committees. The beacon chain assigns verifiers to committees based on a certain degree of randomness, and the committee is responsible for evaluating whether certain parts belong to the beacon chain and shard chain. The votes of each committee are then cryptographically aggregated into one proof, which means that verifying all votes of an entire committee is no more troublesome than validating a single vote. Therefore, to check the validity of the beacon chain, only a fraction of the aggregated signatures are needed to evaluate the majority of validator votes.
The beacon chain also keeps track of the eth1 chain and its deposit, so that new validators can join the eth2 system by sending 32 ETH to the deposit contract deployed on the eth1 chain. By enabling the beacon chain to vote and verify the eth1 chain, eth2 can provide economic guarantees for the blocks on the eth1 canonical chain (the longest chain) in the future, thereby enhancing the security of the eth1 chain.
node and client
eth2 distinguishes between beacon nodes and validator clients, both of which are required by validators to perform their duties. Beacon nodes (i.e. nodes) are responsible for maintaining the entire beacon chain and any shards that users or validators may need to use.
As the name implies, validator clients (i.e. clients) handle the logic of a single validator. The specific implementation is reflected in communicating with the beacon node to understand the current state of the beacon chain, timely proving and proposing blocks, and finally requesting the beacon node to send the block information to other nodes.
Note: If no validator client is running, the beacon node contains all the information needed to interact trustlessly with eth2, similar to a full node in eth1.
Here are some excerpts of the reasons for distinguishing beacon nodes from validator clients:
To become a validator, you first need to stake 32 ETH, so users who want to stake a larger amount of ETH need to run multiple validator instances. Separating nodes and clients allows these users to connect to multiple validator clients while only running a single beacon node, reducing computation, memory, and storage requirements.
Independently differentiated validator nodes are able to more easily write, reason about, and audit smaller blocks of code, and thus potentially be more secure.
For users concerned about redundancy, running multiple nodes in parallel reduces the chance of validators going offline.
Since the verifier client can only interact with other parts of the eth2 network through the beacon node, it will even need to pass alimited API, which greatly reduces the attack surface of the verifier node.
Users who wish to interact with eth2 but do not want to become validators can simply run a beacon node, which will grant them access to the beacon chain and shards.
design concept
The design philosophy of eth2 provides a useful frame of reference for all decisions within eth2, and in many instances encapsulates the differences between eth2 and other protocols.
Protocols are fundamental: Recognizing that everything has trade-offs, protocol safety and liveness take precedence over other design requirements.
Hope for the best, plan for the worst: eth2 assumes that validators are lazy, take bribes, and attack the system unless steps are taken to incentivize validators. Furthermore, it is assumed that the network is not completely reliable, and that a catastrophic event could force a large number of validators offline. Based on these assumptions, eth2 should be prepared and capable of surviving World War III.
Usability difficulty minimized: eth2 has been simplified as much as possible to make it easier to understand, propagate, audit, develop bug-free clients and generally avoid corner cases.
Maximum decentralization: PoS protocols are generally easy to compromise on the number of validators, and the design concept of eth2 is to expand the scale of validators to millions, while encouraging these validators to perform their duties independently of each other.
Anticipate the unexpected: All components on eth2 are quantum computer resistant, or capable of being replaced with quantum computer resistant components in the event of a quantum catastrophe.
epilogue
epilogue
Public account: ETH Chinese website
Original link:https://blog.ethereum.org/
For more Ethereum information, please pay attention to:
Public account: ETH Chinese website
Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact ethereumcn@gmail.com Authorize.
Disclaimer: ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author. Reprints must indicate the source of the original text and ethereum.cn. For long-term reprints, please contact ethereumcn@gmail.com Authorize.
