Research Report | Ethereum 2.0 Upgrade Report

Source: OKEx

I. Istanbul upgrade

A post on the official Ethereum blog on November 21 stated that the Ethereum network will be upgraded at a block height of 9,069,000 as planned, which is expected to happen on Sunday, December 8, 2019. The specific upgrade date and time may change due to the block production speed. Features to be implemented in this Istanbul upgrade include the introduction of sharding; measures to reduce GAS costs; improved chain interoperability with privacy coin Zcash; and smart contracts that allow more creative features.

The Istanbul upgrade will be implemented in two phases, including 14 EIPs (Ethereum Improvement Proposal). Six of these proposals will be implemented in the first stage (V1), and the remaining eight will still need to be discussed and reviewed by core developers, and will be reserved for the subsequent second stage (V2) upgrade implementation.

Among these proposals in the V1 phase, EIP-1884 is quite controversial-in order to protect the blockchain from potential spam trading attacks, it will increase the computational cost of application developers to retrieve data from the network, and recalculate the gas consumption of opcodes Gas cost for some operations has 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 interference caused by changes in Gas costs. For example, it is estimated that in a transaction The total storage space accessed in the + contract + contract code and ensure that it will not be overloaded. EIP-1108 is also very popular-it involves repricing the pre-compiled elliptic curve algorithm on Ethereum. Designed to improve the scalability and privacy protocols of Ethereum 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 and includes an algorithm improvement called "ProgPoW", which will enhance Ethereum's ability to resist ASICs by replacing the proof-of-work function Ethash algorithm.

The Istanbul upgrade is a key milestone on Ethereum's scalable blueprint and strives to make the application of blockchain faster and cheaper without sacrificing the principle of decentralization.

Since its establishment, Ethereum has firmly occupied the second place in the market value of crypto assets, and has a large global developer community. It has also left other public chains behind in the number of DAPPs. But even this status of "below one person over ten thousand people" does not mean that Ethereum can sit back and relax. Positioned as a "world computer", Ethereum currently can only process about 15 transactions per second, while private companies like Visa can process 45,000 transactions per second. The extra costs and waiting time caused by frequent congestion events make the user experience worse, which greatly limits the development of Ethereum. For Ethereum to be widely adopted, it is necessary to greatly improve the scalability and performance on the Ethereum network, so as to better carry decentralized applications and promote the explosion of industry applications.

(The mainstream public chain DAPP data chart,, November 29)

Ethereum 2.0 is an established plan to replace the current Ethereum network. With the forthcoming Istanbul upgrade of Ethereum, the plan and process of Ethereum 2.0 has once again become an issue that everyone is paying close attention to.

Second, Ethereum 2.0

Ethereum's goal is to become a distributed financial and smart contract execution platform, and to become "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 the value of numbers, runs completely programmatically, and is accessible anywhere in the world. In this decentralized world, Ethereum seems to position itself as the builder of the decentralized network and the provider of decentralized network infrastructure and technology.

In order to achieve the goal of the world's computer, Ethereum set four development stages when it was born in 2014: Frontier, Frontier, Metropolis, Serenity. The first three stages all use the POW model, and the fourth stage "quietness" is POS-the final form of Ethereum, which is what we call Ethereum 2.0.

Phase 2.0 will complete the conversion from PoW to PoS, as well as some other important upgrades.

(Ethereum 1.0 and Ethereum 2.0 basic information)

After the 2.0 upgrade is completed, the speed of Ethereum is expected to be greatly accelerated. Unlike the previous POW, it will rely on the consensus algorithm of PoS proof of stake to verify transactions.

2.1 Ethereum 2.0 architecture

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

The figure 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 run as a shard of the beacon chain.
  2. Beacon Chain is the beacon chain, which is the basic chain of all chains, and is the central part of the entire Ethereum 2.0 system. Through the Casper protocol (the consensus layer of the entire system, Casper is responsible for managing the verifiers, implementing rewards and punishments) and Coordinate all independent and parallel shard chains, use Crosslink as the anchor point of each shard to achieve cross-shard communication, and provide final deterministic guarantee for shards
  3. Shard Chains are shard chains and are a source of scalability. Each shard has a validator committee to pack and verify the shards, and regularly record the status of the shards 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 to be unchangeable.
  4. The VM layer is the last important part of the Ethereum 2.0 system, which will provide the execution of contracts and transactions.

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 fragments, each of which can process data independently. . The beacon chain is the core of the architecture and is 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 the blocks generated by PoW, thereby improving the security of the system while reducing the rewards of miners; the other is Casper CBC led by Vlad, and CBC is a pure PoS consensus. CBC still has many details that need further research and discussion.

The beacon chain coordinates all independent and parallel shard chains through the Casper consensus. It is responsible for assigning validators to the shards and tracking the current status of each shard, providing the final deterministic guarantee for the shards, and improving the security of the entire system Can also play a vital role. It is the foundation for implementing Ethereum 2.0,

In Ethereum 2.0, the original chain of 1.0 still maintains the original state to run the PoW consensus. After the shard chain can achieve complete functions, 1.0 will hand over the actual operation rights of Ethereum to the beacon chain, which exists as a shard or a main storage contract of the beacon chain, and the two communicate with each other through bridging.

2.2 Ethereum 2.0 update points

According to the development roadmap of Ethereum, Ethereum will enter the 2.0 stage in 2020. There are three major innovations in this technology upgrade of Ethereum 2.0: the consensus mechanism (PoS mechanism) for proof of stake, sharding, and the eWASM virtual machine.

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

In Ethereum 1.0, Proof of Work (PoW) was used as the consensus mechanism, and new blocks were generated from it. Based on the consensus of the POW computing power, all nodes can only do one thing at a time. The amount of tasks that the entire network can handle is very limited, which is severely limited by the upper limit of the tasks that a single node in the network can handle. Even if the block size is expanded, the efficiency improvement is limited due to the consensus of the entire network. Therefore, in order to reduce the long time it takes to generate a new block of proof of work and the waste of resources required by a large amount of computing power, Ethereum 2.0 will be changed to Proof of Stake (PoS) as a consensus mechanism for generating new blocks. .

Shards -improve network performance and capacity

In physical space, sharding divides all nodes in the public chain network into different groups, and each group is called a shard. The tasks performed by all nodes in the public chain were exactly the same. Now the tasks are grouped and assigned to different shards, and each shard handles different tasks. The original performance bottleneck of the public chain network depends on the performance of the nodes in the network. After sharding, the nodes in a single shard only need to undertake part of the work of the entire network, and each shard works in parallel, thereby improving the carrying capacity of the entire network. Assuming that the number of shards is n, the workload of each node is 1 / n of the workload of the entire network. In the same way, the capacity of the entire network will also become 100 times the original. Sharding is the best solution for blockchain expansion. It can achieve a significant increase in network performance and capacity without increasing the node hardware requirements and reducing the degree of decentralization.

(Slicing physical space map, picture from "Sharding Technology Research Report")

Replace EVM by eWASM-improve the compatibility and execution efficiency of smart contracts

A virtual machine is a small program similar to an operating system. It is the place to handle smart contract deployment and execution. All nodes on the Ethereum system need to run smart contracts to execute the final transactions on the blockchain. Each complete node will run a virtual machine. All nodes will perform the same calculations. All nodes then compare this result and Write to block data.

(Smart contract operation flowchart)

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 and drives the operation of the entire Ethereum. It carries all the tokens, DAPPs, DAO organizations, and games on the Ethereum. However, due to the bloated and complicated compilation work of EVM, it will consume a lot of gas fuel costs, and with the improvement of Ethereum 2.0PoS and sharding, virtual machines need to process transactions in parallel, and EVM processes transactions sequentially and is not suitable for such operations. Therefore, the Ethereum team proposed to use eWASM instead of EVM. EWASM is the Ethereum version of WASM (WebAssembly) code. Compared to EVM, eWASM has better performance and better scalability. It can support Solidity, C ++, Rust, AssemblyScript, etc This kind of programming language will make it easier to develop contracts. It will also be possible to support smart contracts, accounts, status, etc. on ETH2.0. In addition, eWASM is backward compatible with EVM, so at this stage Ethereum's smart contract can theoretically still run in Ethereum 2.0.

2.3 key solutions

At the same time, due to the introduction of sharding and the pos consensus mechanism, Ethereum 2.0 faces 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 mixed mining of POW + POS. At this stage, most of the blocks are still produced through POW, and some blocks will be handed over to the POS node to allow the entire network. Transition to POS in a more gradual manner.

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

Manage certifier status

There are four states of the validator: inactive (not yet fulfilling the responsibilities of the validator), active (verifying), waiting (being a validating node but still waiting in the queue), and exiting the validating node (hope to dismiss Validator responsibility but still stuck in the exit queue).

On Casper FFG, a complete validator cycle is:

1. Payment of collateral: 32 ETH needs to be collateralized in Capser's smart contract

2. Waiting for selection notice: wait 1 day

3. Vote: Wait for 2 to confirm, then vote at the checkpoint to confirm the block

4. Exit: After issuing the exit agreement, you need to continue verification for 7 days

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

There is a waiting period for entering and exiting for the system to arrange a validator to form a committee, and it is a point-to-point connection. The process should be as smooth as possible so that the number of validators does not fluctuate significantly.

Understanding the two time units

Slot (time slot): The time the block proposer proposed the block and used for verification, currently 12 seconds. If a consensus can be reached within the validator committee, a block can be successfully generated for this time slot, otherwise the slot will be empty.

Epoch (period): A time period composed of multiple time slots (currently 32), which is 6.4 minutes. The last slot in epoch is called Checkpoint.

Become a Validators:

Due to the "no-interest attack" problem of POS, that is, under the POS mechanism, malicious node verifiers can stake their coins on the fork chain without any loss to promote a hard fork. 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. After being marked as "active", the Ethereum 2.0 protocol can be run, and the beacon chain will also track and manage Verify the node. The threshold for 32 ETH is low. PoS architecture on PoW exists in the form of smart contracts. Node procedures may be slightly simpler. Users only need to run a wallet on a computer, and the configuration requirements are not very high. . The most important thing for a validator to do is to vote in step 3, prepare, and vote in time so that the validator can get a reward and avoid being confiscated.

Exit verification: Verifiers can also signal that they want to exit the system and stop participating in the protocol. In order to prevent long-range attacks, Ethereum ETH 2.0 has a long withdrawal delay period. Their mortgage token plus rewards minus fines will be returned to a shard chain.

2. Randomly assign validators to the system

Committees (validator committees) are a set of (at least 128) verification nodes randomly selected by the beacon chain, which are responsible for witnessing the blocks generated by the beacon chain and each shard. The beacon chain has its corresponding committee, and each shard also has a verifier committee to verify the block. The committee is responsible for ensuring the safety, liveness, and integrity of the shards where they are located, and is responsible for proving the status of the shards on the beacon chain.

In each slot, the beacon chain will randomly select a validator for the block in each committee to produce a block, and a certain number of other validators check the block and verify the correctness. At the next block generation, a verification node is randomly selected to propose a block, and another set 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 verification node's election process fundamentally avoids collusion and collusion between the verification nodes and improves the security of the protocol.

3. Ensure the final certainty of the chain and avoid long-range POS attacks

Bitcoin's PoW consensus uses the longest chain principle. In order to prevent double payments, generally 6 blocks need to be confirmed before the transaction can be truly confirmed as valid. In fact, the reason why the 6 block confirmation is considered to be a valid sign is that after that, under the current condition of Bitcoin's computing power, the possibility of the transaction being tampered with can be ignored, but theoretically In other words, even after hundreds of blocks of confirmation after a transaction, according to the longest chain principle, the transaction still has the possibility of being tampered with by 51% attacks. Therefore, under the PoW consensus, the certainty of the chain is only the implicit final certainty, and this feature will make the already complex state sharding more uncertain.

In Ethereum 2.0, the verification node votes 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 node participating in the consensus Will vote for checkpoints. Each validator casts a checkpoint, which can be from a 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 two-thirds of the votes, then this block becomes deterministic and cannot be changed. This checkpoint It's a deterministic checkpoint, and so on. When a deterministic checkpoint receives more than two-thirds of the votes from it to a sub-checkpoint behind it, then all checkpoints between this deterministic checkpoint and the following checkpoint have been confirmed.

If the last checkpoint of a deterministic checkpoint on the same branch is also a deterministic checkpoint, and more than 2/3 of the validators voted for this segment, then the deterministic checkpoint is final. If the status of a checkpoint is final, then it and all blocks before it will be confirmed. Therefore, another major improvement in the Casper consensus is the introduction of explicit final certainty, that is, the block information before a few blocks before the latest block can no longer be tampered with, which will help achieve stateless clients.

In the meantime, in order to prevent the verifier from doing evil during the operation, Casper 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 mortgage token will be forfeited.

In addition, in order to allow PoS to improve the security of the PoW chain, FFG made a few modifications to the heaviest chain when it made a fork selection: First, find the highest deterministic checkpoint in the view, and check in The heaviest chain selection is performed on the block after the point.

This has two benefits. The first is that as long as the blocks in the FFG are confirmed before the final checkpoint, there is no possibility of subversion. The second point is that the safety of a confirmed block requires miners to continuously provide their own workload to the block, so more mining rewards are needed to motivate miners; in FFG, as long as it is a final block They are all confirmed, and there is no need for subsequent miners to increase the security of the confirmed blocks, so the mining rewards can be reduced and the inflation rate can be reduced.

4. Regulate node behavior through reward and punishment mechanism

In addition to the role of the POS verification node, it also assumes the role of verifying the block. It also needs to be online to complete the tasks assigned to them.

The weight of validators' votes depends on the size of their mortgage tokens. Every time the verifier successfully packs a block, they will get an Ethereum 2.0 system reward that is proportional to the TOKEN they hold. If most validators reject the blocks they build, then the validators will be at risk of losing their mortgage token. At the same time, if the verifier fails to fulfill his responsibility for block voting, the pledged ether will be reduced. If the balance of the verification node decreases below the verification threshold, he will be kicked out of the verification node pool and cannot continue to participate in verification work. . As a result, CASPER forces validators to act honestly and adhere to consensus rules through a reward and punishment system.

2.3.2 Beacon chain

Cross-slice communication needs to be completed with the help of a beacon chain, because a shard does not have direct information of other shards, and can only obtain information about other shards by cross-linking to the beacon chain. In Ethereum 2.0, each shard has a verifier committee to verify the block, and the members of the committee must write verifiable information about the shard on the beacon chain (for example: Merkel root), this is Cross-linking. When the beacon chain block is completed, the corresponding shard blocks are considered finalized, and the remaining shards can be confident that they can rely on them for cross-shard transactions. If members of the certifier committee cannot reach a consensus on the effectiveness of the cross-linking, faulty certifiers will be confiscated.

Guarantee the randomness of the fragment verifier

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. Shards are more easily controlled by malicious miners, because attackers only need 1 / N hash power to fully control a shard. So for a sharding system, it needs good randomness 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 validator will provide a "hash onion". The RANDAO structure is a way to combine a single random array provided by many participants into a single output number. To prevent any participant from significantly manipulating randomness, developers use a commit-reveal scheme. When a validator signs up, it provides a promised value, which is generated after the original number of its choice has been hashed multiple times. Each time a block producer is selected on the committee, it strips off one or more layers of the "onion" by providing a pre-image of the last revealed number. Everyone else can check if this was done correctly, so the proposer cannot trick the system by changing its single random number. Therefore, the block producer randomly selects the block proposer based on the randomness in the above protocol.

In the casper protocol function, letting each segment of the beacon chain select a verifier committee and a block verifier depends on the randomness brought by the RANDAO structure.


2. Become an anchor point for each shard through crosslink to achieve cross-shard communication

When the user or contract on shard A wants to interact with shard B, the shard A verifier committee member needs to write verifiable information about the shard on the beacon chain (for example: Merkel root). Shard A will pack all its receipts into its block header. The beacon chain waits for fragment A to reach a consensus on the block containing the receipt, and then packs the block header of fragment A into the beacon chain. Segment B waits for the beacon chain to complete the block consensus before packing the beacon chain block header containing the block header of segment A into the block of segment B to reach the on-chip consensus. If the contract on shard B wants to send a reply message (perhaps returning a value or an error), the whole process needs to be reversed: shard B generates a receipt, which eventually takes effect in shard A.

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

In two-way communication, when the contract on shard B is the best case that does not need to send a reply message, it takes 4 consensus cycles to complete, as shown in the process of Figures 1 to 4 below. The user can confirm that the communication process has been completed after the end of the three periods, because the user can see that Segment B has completed consensus on the verifiable information before it receives the verifiable information of Segment B 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

Bridging is the migration of ETH on Ethereum 1.0 to Ethereum 2.0.

Existing Ethereum 1.0 Ethereum holders in the one-way bridging scheme can burn the currency they hold in exchange for an equivalent amount of Ethereum 2.0 Ethereum, which will be generated and locked in the beacon chain's margin In the contract, but cannot be returned. This bridging method will cause liquidity problems for validators, and more importantly, it may cause replaceability problems between Ethereum 1.0 and Ethereum 2.0. It occurs before bidirectional bridging, and it is likely that the exchange will be simultaneously There are two coins. Two-way bridging does not have this problem, but two-way bridging is a tightly coupled consensus mechanism. Attacks on both sides of the chain and the problems they generate will affect the other side of the chain, and the development of the agreement will be very cumbersome.

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

There are currently two possible routes for bidirectional 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 Ethereum 1.0.

Bridging needs to take into account the security of each agreement, because there are many concerns in the actual user base, and a lot of coordination is needed to get a hard fork on our production network. The team hopes to be validated in a production environment before impacting the security and risk profile of Ethereum 1.0. The development team should enable bridging before joining the verifier liquidity, but will wait until the first stage of the product is stable before opening it; there are many related studies being conducted at the same time, which may affect when this operation is completed.

Risks of Ethereum 2.0

3.1 Landing risk

Ethereum 2.0 is more difficult and longer to develop. It can be seen from the architecture diagram that the completion of Ethereum 2.0 requires several major technological innovations. The realization of smart contract sharding and state sharding itself is extremely difficult to design and develop. In addition, it needs to consider the original chain. The transition and compatibility further increase the difficulty of implementation. As a platform that has been developed for several years, the code structure has become very complicated, and the bottom layer is difficult to modify. The modification of the original architecture affects the whole body, and many factors need to be considered. We see that although the framework of Ethereum has been finalized, many details are still under discussion and modification.

3.2 Competition risk

Many public chains are dedicated to solving the current expansion and performance problems of Ethereum. Most of them are compatible with Ethereum code at the smart contract layer, which can provide the fastest and most convenient way for developers to transfer to their own public chain. Therefore, Ethereum The competitive pressure is very large. If Ethereum cannot improve its own instance, it will definitely give other public chains the opportunity to surpass it. In the high-performance public chain circuit, Tezos in 2014 has been launched on the mainnet in 2018, and the test versions of Cosmos and Cardano in 2016 have also been launched in 2019. The time for Ethereum 2.0 is urgent.


Sharding Technology Research Report | TokenInsight

Ethereum 2.0: the future of Ethereum

Future roadmap and challenges for Ethereum 2.0

What is Ethereum 2.0? Into several stages