Ethereum 2.0 is about to show its sword, what are the highlights of the design plan?

特邀专栏作者

2019-12-27 16:52 (UTC+8)

This article is about 9162 words, reading the full article takes about 14 minutes

On Sunday, December 8, 2019, the Ethereum network was upgraded to Istanbul at block height 9,069,000 as planned. According to the ethernodes.org website, more than 90% of the nodes have been synchronized.

AI Summary

Expand

Table of contents:

one. istanbul upgrade

two. Ethereum 2.0

2.1 Architecture

2.2 Major update points

2.3 Key Solutions

first level title

one. istanbul upgrade

image description

(Node synchronization diagram, the picture comes from ethernodes.org)

image description

(Mainstream public chain DAPP data map,https://www.stateofthedapps.com/, November 29)

The Istanbul upgrade is a key milestone in the scalable blueprint of Ethereum 2.0, trying to make the application of blockchain faster and cheaper without sacrificing the principle of decentralization. Among the features to be implemented in this Istanbul upgrade are measures to reduce gas costs; improved chain interoperability with privacy coin Zcash; and smart contracts that allow for more creative functions.

A total of 14 EIPs (Ethereum Improvement Proposals) will be implemented in two phases. Among them, 6 proposals will be implemented and applied in the first phase (V1), and the remaining 8 proposals still need to be discussed and deliberated by core developers, and will be reserved for the subsequent second phase (V2) upgrade implementation.

Among these proposals in the V1 phase, EIP-1884 is quite controversial - in order to protect the blockchain from potential spam transactions, it will increase the computing cost for application developers to retrieve data from the network, reset the Gas consumption for the operation code, The Gas consumption of some operations has been increased. This makes the cost of calling data on Ethereum higher than before. For developers, it is necessary to avoid writing applications that take up a lot of storage space to eliminate the biggest disturbance caused by changes in Gas costs. For example, it is estimated that in a transaction The total storage space + contract + contract code accessed in , and ensure that it will not be overloaded. Another big hit is EIP-1108 — it involves repricing precompiled elliptic curve algorithms on Ethereum. Aims to improve Ethereum's scalability and privacy protocols by optimizing GAS payments, and will make ZK-SNARKs and other privacy applications such as Zether and AZTEC less expensive to use on Ethereum.

The second phase (V2) will be implemented on the upgraded mainnet, including an algorithm improvement called "ProgPoW", which will enhance Ethereum's ability to resist ASICs by replacing the workload proof function Ethash algorithm.

first level title

two. Ethereum 2.0

The goal of Ethereum is to become a distributed financial and smart contract execution platform, becoming "a real world computer". Ethereum's official website shows this: Ethereum is a global, open-source platform for decentralized applications. On Ethereum, you can write code that controls digital value, runs exactly as programmed, and is accessible from anywhere in the world. In this decentralized world, Ethereum seems to position itself as a builder of a decentralized network and a provider of decentralized network infrastructure and technology.

In order to achieve the goal of the world's computer, Ethereum set four development stages at the beginning of its birth in 2014: Frontier (frontier), Homestead (homeland), Metropolis (metropolis), Serenity (tranquility). The first three stages all adopt the POW model, and the fourth stage "Serenity" is POS—the final form of Ethereum, which is what we call Ethereum 2.0.

image description

secondary title

image description

(The overall architecture of Ethereum 2.0, from Hsiao-Wei Wang)

This picture from top to bottom is:

1. PoW Main Chain is the current Ethereum main network. In the Ethereum 2.0 system, it will continue to operate as a shard of the beacon chain.

2. Beacon Chain is the beacon chain, which is the basic chain of all chains and the central part of the entire Ethereum 2.0 system, through the proof of rights and interests of the Casper protocol (Casper is the consensus layer of the entire system, responsible for managing verifiers, implementing rewards and punishments ) and coordinate all independent parallel shard chains, and use Crosslink as the anchor point of each shard to realize cross-shard communication and provide finality guarantee for shards.

3. Shard Chains are shard chains, which are the source of scalability. Each shard has a validator committee to package and verify the shard, and regularly record the state of the shard on the beacon chain through cross-linking. Once a block is finalized on the Beacon Chain, the shard blocks referenced by the cross-links in the block are considered immutable.

4. The VM layer is the last important component of the Ethereum 2.0 system, which will provide contract and transaction execution.

The architecture of Ethereum 2.0 is shown in Figure 1. In Ethereum 2.0, there will be a main chain called the beacon chain. Under the beacon chain, there are 64 shards, and each shard can process data independently. . The beacon chain is the core of the architecture, responsible for connecting the main chain and managing each shard.

Casper is its corresponding consensus. It has two versions. One is Casper FFG led by Vitalik. FFG uses a hybrid consensus of POW+pos as a transition protocol for Ethereum to successfully transform from PoW to PoS. Its main idea is to use PoS to help the final confirmation of blocks generated by PoW, thereby improving the security of the system while reducing miner rewards; the other is Casper CBC led by Vlad, and CBC is a pure PoS consensus. From the current point of view There are still many details of CBC that need to be further studied and explored.

secondary title

2.2 Update points of Ethereum 2.0

According to the development roadmap of Ethereum, Ethereum will enter the 2.0 stage in 2020. The technical upgrade of Ethereum 2.0 mainly has three major innovations: the consensus mechanism is changed from POW to POS, shards (Shards) and eWASM virtual machine.

Consensus mechanism POW to POS - improve efficiency and solve energy consumption problems

In Ethereum 1.0, Proof of Work (PoW) is used as the consensus mechanism to generate new blocks. Based on the consensus of POW computing power, all nodes can only do one thing at the same time, and the amount of tasks that the entire network can handle is very limited, which is severely restricted by the upper limit of tasks that a single node in the network can handle. Even if the block size is expanded, due to the consensus of the whole network, the effect of improving efficiency is limited. Therefore, in order to reduce the long time it takes to generate new blocks and the waste of resources caused by the need for a large amount of computing power, Ethereum 2.0 will change to Proof of Stake (PoS) as the consensus mechanism for generating new blocks .

Shards - Improve network performance and capacity

image description

(Sharding physical space diagram, picture from tokeninsight "Sharding Technology Research Report")

Replacing EVM with eWASM - Improving the compatibility and execution efficiency of smart contracts

image description

(Smart contract operation flow chart)

Ethereum 2.0 will support multiple programming languages, and eWASM will replace EVM. The EVM virtual machine is the core engine in the Ethereum network, driving the operation of the entire Ethereum, and carrying all the tokens, DAPPs, DAO organizations and games on the Ethereum. However, due to the bloated and complicated compilation work of EVM, a large amount of gas will be consumed, and with the improvement of Ethereum 2.0 PoS and sharding, virtual machines need to process transactions in parallel, and EVM is not suitable for such operations because it processes transactions sequentially. Therefore, the Ethereum team proposed to use eWASM instead of EVM. eWASM is the Ethereum version of WASM (WebAssembly) code. Compared with EVM, eWASM has better performance and better scalability, and can support Solidity, C++, Rust, AssemblyScript, etc. With a programming language, it will be easier to develop contracts, and it will also be possible to support smart contracts, accounts, status, etc. on ETH2.0. In addition, eWASM is backward compatible with EVM, so Ethereum's smart contracts can theoretically still run on Ethereum 2.0 at this stage.

2.3 Key Solutions

At the same time, due to the introduction of sharding and pos consensus mechanism, Ethereum 2.0 is facing new challenges. So there are Casper FFG, beacon chain, and bridging solutions to bridge these risks and help Ethereum 2.0 continue to improve.

2.3.1 .Casper FFG

After the implementation of Casper FFG, Ethereum will first enter a stage of POW+POS hybrid mining. At this stage, most of the blocks are still produced through POW, and some blocks will start to be handed over to POS nodes, so that the entire network Make the transition to POS in a more gradual manner.

Casper FFG assigns a validator committee to the system on a regular basis, selects block proposers and block validators for each shard, and implements rewards and penalties for validators.

(1) Manage validator status

There are four states of the validator: inactive (has not started to perform the role of the validator), activated (validating), waiting (is about to become a validator but still waiting in the queue) and exiting the validator (hoping to deactivate validator responsibilities but still stuck in the exit queue).

On Casper FFG, a full validator cycle is:

1 Mortgage deposit: 32 ETH need to be mortgaged into Capser's smart contract

2Waiting for the selection notification: wait for 1 day

3 Vote: After 2 is confirmed, vote at the checkpoint to confirm the block

4 Withdrawal: After issuing the withdrawal agreement, it needs to continue to verify for 7 days

5 Withdrawing the deposit: After submitting the application, you need to wait for about 4 months before you can withdraw it.

There must be a waiting period for entry and exit because the system must arrange verifiers to form a committee, and it is a point-to-point connection. This process must be as smooth as possible, so that the number of verifiers will not fluctuate greatly.

Understanding Two Time Units

Slot (time slot): The time for the block proposer to propose a block and use it for verification, currently 12 seconds. If a consensus can be reached within the validator committee, the slot can successfully generate a block, otherwise the slot is empty.

Epoch (period): The time period combined by multiple time slots (currently 32), 6.4 minutes. The last slot in epoch is called Checkpoint (checkpoint).

Become Validators:

Due to the problem of "no-interest attack" in POS, that is, under the POS mechanism, malicious node verifiers can bet their coins on the forked chain to promote hard forks without any loss. Therefore, in Ethereum 2.0, the verification node needs to mortgage a certain amount of ETH (currently 32ETH) to the beacon chain to apply for joining. When it is marked as "active"After that, the Ethereum 2.0 protocol can be run, and the beacon chain will also track and manage the verification nodes. The threshold of 32 ETH is low. PoS based on PoW exists in the form of smart contracts. The node program may be a little simpler. Users only need to run the wallet on the computer, and the configuration requirements are not very high. . The most important thing for validators to do is to vote in step 3. Prepare and vote in time so that validators can get rewards and avoid token confiscation.

Exit Validation: Validators can also signal that they want to exit the system and stop participating in the protocol. In order to prevent long-range attacks, there is a longer withdrawal delay period in Ethereum ETH2.0, and their pledged TOKEN plus rewards minus fines will be returned to a shard chain.

(2) Randomly assign verifiers to the system

Committees are a group (at least 128) of verification nodes randomly selected by the beacon chain, responsible for witnessing the blocks generated by the beacon chain and each shard. The beacon chain has its own committee, and each shard also has a validator committee that validates blocks. The committee is responsible for ensuring the security, liveness, and integrity of the shards they are in, and for attesting to the state of the shards on the beacon chain.

In each slot, the beacon chain will randomly select a validator for the chain in each committee to be responsible for producing a block, and a certain number of other validators will check the block and verify its correctness. When the next block is generated, a verification node is randomly selected to propose a block, and another group of different verification nodes is used to verify the correctness.

After the assigned committee completes the block generation and verification tasks of an Epoch, the system will reshuffle all the verification nodes and randomly select a new validator committee for the next Epoch for each shard. With the help of the random number generation algorithm, the election process of verification nodes fundamentally avoids collusion among verification nodes and improves the security of the protocol.

(3) Ensure the finality of the chain and avoid POS long-range attacks

Bitcoin's PoW consensus adopts the longest chain principle. In order to prevent double payment, it generally needs to wait for the confirmation of 6 blocks before the transaction can be truly confirmed as valid. In fact, the reason why the confirmation of 6 blocks is considered to be a sign of valid confirmation is that after that, under the current Bitcoin computing power conditions, the possibility of the transaction being tampered with is already negligible, but theoretically In other words, even after a transaction has been confirmed by hundreds of blocks, according to the longest chain principle, the transaction still has the possibility of being tampered with data through a 51% attack. Therefore, under the PoW consensus, the certainty of the chain is only implicit finality, and this feature will make the already complex state sharding more uncertain.

In Ethereum 2.0, the verification node voting for each block will increase the network propagation overhead. In order to reduce the number of votes in Casper, the block on the last slot in each epoch is set as a checkpoint, and the verification nodes participating in the consensus Will vote on checkpoints. Each verifier casts a checkpoint, which can be from the deterministic checkpoint to a checkpoint after several checkpoints. Starting from the genesis block (the genesis block is the first deterministic checkpoint), when the next checkpoint receives more than 2/3 of the votes, then this block becomes deterministic and unchangeable, and this checkpoint That is, a deterministic checkpoint, and so on. When a deterministic checkpoint has received more than 2/3 of the votes from it to a sub-checkpoint behind it, then all the checkpoints between this deterministic checkpoint and the latter checkpoint have been confirmed.

If the previous checkpoint of the deterministic checkpoint on the same branch is also a deterministic checkpoint, and more than 2/3 of the validators voted for this segment, then this deterministic checkpoint is final. If a checkpoint state is final, then it and all blocks before it are finalized. Therefore, another major improvement in the Casper consensus is the introduction of explicit finality, that is, the block information several blocks before the latest block can no longer be tampered with, which will facilitate the realization of stateless clients.

In the meantime, in order to prevent the verifier from doing evil during the operation, Casper has formulated a set of punishment mechanisms as follows: the verifier cannot initiate two different votes for the same block height, and the voting range of the two votes cannot contain one One, otherwise the pledged token will be confiscated.

In addition, in order to allow PoS to improve the security of the PoW chain, FFG made some modifications to the heaviest chain when selecting a fork: first find the highest deterministic checkpoint in the view, and Select the heaviest chain on the block after the point.

There are two advantages to doing this. The first is that as long as the blocks in FFG are before the finality checkpoint, they are confirmed and there is no possibility of being subverted. The second point is that the security of a confirmed block requires miners to continuously provide their workload to the block, so in order to motivate miners, more mining rewards are needed; in FFG, as long as it is a final block All have been confirmed, and there is no need for subsequent miners to use the workload to increase the security of the confirmed blocks, so mining rewards can be reduced and inflation rates can be reduced.

(4) Regulate node behavior through reward and punishment mechanism

In addition to the role of generating blocks, POS verification nodes also undertake the role of verifying blocks, and they also need to be online all the time to complete the tasks assigned to them.

The weight of validator votes depends on the size of their staked tokens. Every time a validator successfully packs a block, they will receive an Ethereum 2.0 system reward proportional to the TOKEN they hold. If a majority of validators reject the blocks they built, then validators risk losing their staked tokens. At the same time, if the validators fail to fulfill their responsibilities for voting on the block, their pledged Ethereum will be cut. If the balance of the validator node decreases below the verification threshold, they will be kicked out of the validator node pool and cannot continue to participate in the verification work . Therefore, CASPER forces validators to act honestly and abide by consensus rules through a system of rewards and punishments.

2.3.2 Beacon chain

Cross-shard communication needs to be completed with the help of the beacon chain, because a shard has no direct information about other shards, and can only get information about other shards by cross-linking to the beacon chain. In Ethereum 2.0, each shard has a validator committee that verifies the block, and members of the committee must write verifiable information about the shard (for example: Merkle root) on the beacon chain, which is crosslinking. When a beacon chain block is finalized, the corresponding shard block is considered finalized, and the remaining shards can be confident that they can rely on it for cross-shard transactions. If the members of the validator committee cannot reach a consensus on the validity of the crosslink, then the erroneous validator will be slashed.

(1) Guarantee the randomness of shard verifiers

It is difficult to generate good randomness in a blockchain system, and the key requirement of a proof-of-stake protocol is the source of randomness, which must be distributed, verifiable, unpredictable, and inalienable. Fragments are more easily controlled by malicious miners, because attackers only need 1/N hash power to fully control a shard. Therefore, for a sharding system, good randomness is required to prevent specific shards from being attacked individually. The beacon chain is responsible for providing this randomness to the rest of the system. In Ethereum sharding, the current random number generation is done by the beacon chain through the RANDAO structure.

The verifier provides a "hash onion". The RANDAO structure is a way to synthesize a single random array provided by many participants into a single output number. To prevent any one actor from significantly manipulating the randomness, the developers used a commit–reveal scheme. When a validator registers, it provides a commitment value that is the result of multiple hashes of the original number it chose. Every time a block producer is selected in committee, it peels off one or more layers of the "onion" by providing a preimage of the last revealing number. Everyone else can check that this was done correctly, so the proposer cannot cheat the system by changing its single nonce. Block producers therefore randomly select block proposers based on the randomness within the protocol described above.

In the casper protocol function, each fragment of the beacon chain selects the verifier committee and selects the block verifier, etc., all rely on the randomness brought by the RANDAO structure.

(2) Become the anchor point of each shard through crosslink to realize cross-shard communication

image description

(The picture comes from Ethereum 2.0 is coming, don't you know Casper yet?)

The number of shards in the new proposal of Ethereum 2.0 has been reduced from 1024 to 64, which reduces the complexity of calculations, and the consensus cycle for cross-linking is reduced from one epoch to one slot to reduce the delay time of cross-shard transactions.

In two-way communication, when the contract on shard B is in the best case of not needing to send a reply message, it also takes 4 consensus cycles to complete, as shown in the process in Figures 1 to 4 below. The user can only confirm that the communication process has been completed after the end of the 3 periods, because the user can see that shard B has completed the consensus on the verifiable information before shard A receives shard B's verifiable information and its evidence. Since the consensus period of ETH 2.0 is 12 seconds, users of shard A must wait 12 *3=36 seconds to see the result, and if they want to query the result on shard A, they need to wait 12*4=48 seconds.

2.3.3 Bridging

The bridge is to migrate ETH on Ethereum 1.0 to Ethereum 2.0.

Existing Ethereum 1.0 ETH holders in the one-way bridge scheme can burn their holdings in exchange for an equivalent amount of ETH 2.0 ETH, which will be generated and locked in the Beacon Chain deposit contract, but cannot be returned. This bridging method will cause validator liquidity problems, and more importantly, it may cause substitutability problems between Ethereum 1.0 and Ethereum 2.0. Before the two-way bridge occurs, exchanges are likely to have both There are two coins. Two-way bridging will not have this problem, but two-way bridging is a tightly coupled consensus mechanism. Attacks and problems on both chains will affect the other chain. The development of the agreement is bound to be very cumbersome.

Below are some notable pros and cons of one-way and two-way bridges listed on EthHub. It is worth noting that the advantages of one-way bridging are mostly technical, while the disadvantages are mainly economical. In other words, the choice between one-way bridges and two-way bridges is essentially a trade-off between technical and economic challenges.

There are currently two possible routes for two-way bridging. One is to build a light node of Ethereum 2.0 on top of Ethereum 1.0; the other is to operate a full node of Ethereum 2.0 on top of Ethereum 1.0.

first level title