Translator’s Preface: Upgrade path on the etheric fang, password money a lot of knowledge of the participants in the community may be out of date, such as the etheric fang and Casper protocol mechanism will not replace existing Ethernet fang PoW, but were transferred to the etheric lane 2.0 system Beacon chain, chain, and the existing Ethernet fang PoW will continue to run according to the original rules, In this article, Ben Edgington, blockchain protocol engineer at Ethereum developer ConsenSys, will talk about Ethereum 2.0 and the Beacon chain.
Ethereum 2.0 is not a new idea. Vitalik mentioned the concept of Ethereum 2.0 back in 2014, saying, “Either we solve scalability and consensus issues or we die trying,” well, we’re alive and well, and his latest point, posted a few weeks ago: “Theoretically, there are no obvious unresolved issues for Ethereum 2.0.”
Now is the time to implement these theories, and the Beacon chain is the first component of the Ethereum 2.0 delivery plan. In this article, we’ll discuss what it does, why it does it, and how developers have developed it.
Introduction to Beacon chain
In a previous post, the author introduced the concept of Ethereum 2.0, which is shown here with hsiao-Wei Wang’s Ethereum 2.0 system architecture diagram:
This diagram can also serve as a step-by-step roadmap for developing and delivering Ethereum 2.0, from top to bottom:
· The PoW main chain is the part of Ethereum that exists today: the current Ethereum main network. In an Ethereum 2.0 system, it will continue to operate as it does today. And everything down here is new.
· Beacon chain is currently under development and will be the first component to be delivered;
· Shard chain will be the next delivery component and a source of extensibility. Initially, shard chains will simply aggregate transactions and agree on their ordering, without executing them. This will be a good test of system infrastructure and security;
· The VM layer is the last major component of the Ethereum 2.0 system and will provide for the execution of contracts and transactions;
Why do we need a “Beacon” chain?
Beacon chain is a new PoS blockchain. It is the backbone of the entire new Ethereum 2.0 system. It’s there to keep the whole system alive, and it’s responsible for directing all the components of the Ethereum 2.0 system.
(Beacon chain directs the entire Ethereum 2.0 system)
The key function of Beacon chain is to manage PoS protocol (Casper) and all shard chains. It has a lot of work to do: manage verifiers and their stakes; Specify the selected block proposer for each shard at each step; Organize verifiers to sit on committees to vote on proposed blocks; Applying consensus rules; Rewards and penalties shall be given to the applicants; And, as an anchor, shards register their status to facilitate cross-shard transactions;
Before we delve more deeply into these features, take a look at the terminology. The Beacon chain’s name derives from the concept of “random beacons”, which provide random sources for the rest of the system, and which the Dfinity project has adopted in its blockchain environment. Each participating node maintains its own local Beacon chain and tries to keep in sync with other nodes. Perhaps the image above with the conductor is misleading, and while the Beacon chain does direct the rest of the system, the conductor is decentralized, just as each musician has his own sense of rhythm.
Some functions about Beacon chain
Let’s take a look at some of the features of the Beacon chain.
Management verifier
One of the main jobs of the Beacon chain is to maintain a collection of verifiers, nodes that are required to join by mortgagingEthereum. They will be responsible for running the Ethereum 2.0 system. Validators can have multiple states, but only those nodes marked as “active” can participate in running the Ethereum 2.0 protocol.
Participants who want to join the validator set can send 32 Ether tokens through the current Ethereum PoW main chain to a Beacon chain contract which, after some validation checks, will be locked and the contract will issue log entries (” events “in Solidity) which can be received by the Beacon Chain client. The selected node can then be imported into the validator set of the Beacon chain.
Once activated, the verifier can propose blocks and participate in the Ethereum 2.0 protocol, and when these blocks are selected, they appear on both the Beacon chain and the shard chain (once they are implemented). As described below, these verifiers also join committees that vote on blocks.
Verifiers can also signal that they wish to quit the system and stop participating in the protocol. After a period of time (currently 97 days, but more flexibility is possible), their deposit (32 Ether) plus the reward minus the penalty will be returned to a shard chain. Unlocking the initial rights on PoW’s main network is unlikely unless the whole system fails and the community agrees to refund those who opt out.
All the above work is managed by Beacon chain.
Provide randomness
Good randomness is hard to generate in blockchain systems, and the key requirement for a proof-of-stake protocol is that the source of randomness be distributed, verifiable, unpredictable, and inalienable. The Beacon chain is responsible for providing this randomness to the rest of the system: several of the protocol functions described below depend on this randomness.
The current generation of random numbers is done through the RANDAO structure, where the verifier provides a “hash onion”. The RANDAO structure is just one way to combine contributions from many actors (a single random number) into a single output number. To prevent any participant from explicitly manipulating randomness, the developers used a commit — reveal scheme. When a verifier registers, it provides a promise value that has been hashed several times over the raw number it selects. Each time a verifier is selected as a proposer, it strips off one or more layers of the onion by providing a primal image of the last revealed number. Anyone else can check that this is done correctly, so the proposer cannot cheat the system by changing his contribution.
While this scheme is not irreplaceable and the author can choose to skip it if he doesn’t like the random number, it is robust enough for the current protocol design.
Block proposer
The Beacon chain manages its PoS protocol and each shard chain. In a proof-of-work system, the miner node is responsible for selecting the next block. In the PoS system, there is no mining process, so the block producer randomly selects the block proposer based on the randomness of the above protocol.
Another feature of the PoW system is that block times are irregular, although ethereum’s block generation time averages about 15 seconds. In contrast, we describe the block generation of the Beacon chain as a heartbeat. Ethereum 2.0 blocks are generated regularly every 16 seconds (possibly reduced to 8 seconds if testing works). This 16-second period is called “sLOT”;
At each slot, the presenter selected by the Beacon chain will collect all protocol votes (proofs) from the Beacon chain verifier set of the previous block and incorporate them into its published block.
Once the shard chain is ready, each shard has presenters of its own choice in each slot that collect transactions for that shard and place them in a block voted on by the shard committee;
The committee
An important source of security for proof-of-stake blockchains are committees, which vote on the blocks that make up the true history of the blockchain. Beacon Chain relies on counting votes from its committee, which we call “certifications,” in order to agree and ultimately determine its history. In an ideal world, the members of the committee would be effective validators in the system if they could collect proofs quickly.
In addition, the Beacon chain will randomly assign smaller sub-committees to each shard, which will be responsible for verifying that the shard originators acted correctly when appropriate.
Rewards and punishments
Another administrative role of the Beacon chain is to track and update validator deposits.
If the validator performs well and performs their role, they are rewarded: this is the motivation for the validator to participate in the Ethereum 2.0 system. However, if the verifier violates the rules. Then their 32 Ether deposits will be reduced (slashed), and at some point the verifiers will be removed from the system. The system also has a small penalty if the verifier is absent (not voting on the block), which we call a “quadratic leak.” The reason for this is subtle, as the system can continue to process blocks even when a large number of validators are offline, such as in the event of a disaster.
If the validator’s deposit is less than 16 Ether, the Beacon chain removes the validator from the set.
Crosslinks
Finally, the Beacon chain performs cross-linking. Crosslinking is responsible for connecting the entire shard system together, and it is responsible for anchoring each shard to the spine of the Beacon chain.
Periodically, the current status of each shard (the “combined data root”) is recorded in the Beacon chain and crosslinked. When the Beacon chain block is completed, the corresponding shard block is considered final, and other shards can be assured that they can rely on it for cross-shard transactions.
Visual Beacon chain (blue) with 8 shard chains (emerald green) and associated crosslinks (light blue line). All completed blocks on the chain are yellow and the time increases from left to right. (Image by Casey Detrio)
Build Beacon chain
Soon, we will end our Beacon chain lightning tour! On its own, the Beacon chain may not seem particularly useful. It can’t handle arbitrary transactions: it doesn’t have smart contracts, it doesn’t have EVM virtual machines. You can’t do anything with it. However, as the first component of Ethereum 2.0, it is the foundation of the entire system. The entire spectacular Ethereum 2.0 building will be based on this. So, it has to be solid.
If you want to get into the details, there is a Beacon chain specification currently in the works. All creation and maintenance of this specification is public: anyone interested is welcome to join.
In order to run the Beacon chain, you need a Beacon chain client. Many of the most familiar Ethereum clients (GETH, Parity, Pantheon, etc.) are under development. You can check out the list I know of here, which includes links to its GitHub codebase. Prysmatic and Lighthouse are regularly updating their client development progress, and several teams are offering rewards to contributors.
About the progress… At the time of this writing, the Beacon chain is nearing 60% specification completion. Nonetheless, developers expect to have the specification reasonably completed by the end of this year and may be running a multi-client Beacon chain test network by the end of the first quarter of 2019. Development has been rapid in recent weeks, and real discussions about Ethereum 2.0 are beginning to unfold!