OKEX Investment Research: Ethereum 2.0 Upgrade Report

星球君的朋友们

Odaily资深作者

2019-12-06 19:05 (UTC+8)

This article is about 8978 words, reading the full article takes about 13 minutes

How far is Ethereum from Istanbul to 2.0?

AI Summary

Expand

How far is Ethereum from Istanbul to 2.0?

Editor's note: This article is from OKEX Research, and Odaily is authorized to reproduce it.

1. Upgrade Istanbul

On November 21, the official Ethereum blog posted that: The Ethereum network will be upgraded at block height 9,069,000 as planned, and the time is expected to occur on Sunday, December 8, 2019. The specific upgrade date and time may change due to the speed of block generation. Among the features to be implemented in this Istanbul upgrade are the introduction of sharding; measures to reduce gas costs; improved chain interoperability with privacy coin Zcash; and smart contracts that allow for more creative functions.

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.

The Istanbul upgrade is a key milestone in ethereum's scalability roadmap, which seeks to make blockchain applications faster and cheaper without sacrificing the principles of decentralization.

image description

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

Ethereum 2.0 is an established plan to replace the current Ethereum network. With the upcoming Istanbul (Istanbul) upgrade of Ethereum, the plan and process of Ethereum 2.0 has once again become an issue that everyone is eager to pay attention to.

two. Ethereum 2.0

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

(Ethereum 1.0 and Ethereum 2.0 basic information)

secondary title

This picture from top to bottom is:

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

This picture from top to bottom is:

PoW Main Chain is the current Ethereum mainnet. In the Ethereum 2.0 system, it will continue to operate as a shard of the beacon chain.
Beacon Chain is the beacon chain. It is the basic chain of all chains and the central part of the entire Ethereum 2.0 system. It passes the equity proof Casper protocol (Casper is the consensus layer of the entire system, responsible for managing verifiers and implementing rewards and punishments) and Coordinate all independent parallel shard chains, use Crosslink as the anchor point of each shard to realize cross-shard communication, and provide finality guarantee for shards.
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.
The VM layer is the last important component of the Ethereum 2.0 system, which will provide contract and transaction execution.

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.

The beacon chain coordinates all independent parallel shard chains through the Casper consensus, and is responsible for assigning verifiers to shards and tracking the current state of each shard, providing final certainty guarantees for shards, and improving the security of the entire system can also play a vital role. It is the basis for realizing Ethereum 2.0,

secondary title

2.2 Update points of Ethereum 2.0

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

Shards - Improve network performance and capacity

image description

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

(Smart contract operation flow chart)

2.3 Key Solutions

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.

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

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

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.

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.

Understanding Two Time Units

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.

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.

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.

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.

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.

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.

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.

text

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.

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.

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.

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

When a user or contract on shard A wants to interact with shard B, members of the validator committee of shard A need to write verifiable information about the shard on the beacon chain (for example: Merkle root). Shard A will pack all of its receipts into its block header. The beacon chain waits for shard A to reach a consensus on the block containing the receipt, and packs the block header of shard A into the beacon chain. Shard B waits for the beacon chain to complete the block consensus before packing the beacon chain block header containing the block header of shard A into the block of shard B, so as to achieve intra-shard 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 finally takes effect in shard A.

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