Graphical Ethereum development route

The following content is adapted from a speech on April 9th ​​(Friday)

This article is about the road to the future of Ethereum. The Eth2 developer team refers to the current Ethereum as “eth1”, which is what we now knowPoWchain. And the future of Ethereum is neither eth1 nor eth2, but…Ethereum:

Let’s sort out the current Ethereum:


Figure: The current operation of Ethereum (eth1 chain)

Users want to do something (“make a transaction”), so they send their transactions to miners, who pack them into blocks and add them to a growing chain. Miners run the PoW consensus mechanism [1] to decide who will add the next block and execute the transactions in the block to ensure that the transaction is valid.


Picture:PoS Mechanism instead of PoW mechanism

PoW is not all bad, but I need an attractive topic

PoW requires a lot of hardware to run intensive calculations, resulting in excessive energy consumption. We do not like most encryption currency as critics talk about a waste of resources (their usual rhetoric is “Why do we use a wasting national resources payment system”?), We are advocating is that since we can in a relatively Do the same thing with little consumption, then we should do it.

So we choose to PoS transition, with only a small server instead of a large number of mining equipment, instead of miners verifier.


Figure: If they do not do the second step of verification, they will lose assets

How does the second step work? What exactly is the verifier verifying?


Figure: Divide the activities of Ethereum into two parts (consensus layer and execution layer)

The consensus layer ensures that everyone agrees on the correct data. The execution layer actually interprets these data to make it meaningful. “Data” refers to any form of interaction with the blockchain, such as deploying a contract, conducting transactions on exchanges , sending payment transactions, etc…

The core of the blockchain is to add new blocks to the chain. When a new block is added, the state before the block will migrate to the state after the block. This state summarizes all the data from block 0 to N.

For example, if the state holds a ledger that records the balances of Alice and Bob, and the new block contains a record of Bob paying 10 tokens to Alice, then after this new block is added to the blockchain, the state will record the new balance information . “State after block N+1” (the state after block N+1) The dotted dot on the right side of the figure represents the change after the new block is added. At this time, the existing state may be modified (for example, Alice and Bob Balance), or create a new state (deploy a new contract, or add Carol to the ledger…)


The first step is to decouple the consensus layer from the execution layer; the second step is to move from PoW to PoS

Rollups and eth2 are mainly to solve the first point in the plan above: removing the correlation between the consensus layer and the execution layer. So how is the progress of this work?


Picture: The first step has been completed

Since December 2020, we have two chains in progress at the same time:

➤ The first is PoS-consensus chain (also known as beacon chain)

➤  The second is our reliable PoW- consensus + chain execution (aka, eth1)

They run at the same time, but they can also communicate with each other. However, this function has not yet been implemented…


Figure: How to become a validator

To become a validator of PoS-consensus, users on the PoW-consensus + execution chain need to lock 32 in the deposit contract ETH, This will be automatically transferred to the PoS-consensus chain. Once the verifier is activated, they can start verification work and get rewards.


Figure: Merge

It is hoped that this inability to communicate will not last long. “Merge” permanently bridges the PoS-consensus chain and the PoW-consensus + execution chain, which means that the verifier can produce blocks for the execution layer. After the merger, we have two kinds of chains:

  PoS-consensus chain

➤  a chain PoS performed based on (i.e., “eth1” chain)

After the merger, validators of the PoS-consensus chain will be able to redeem and withdraw their pledge deposits and rewards, and send them back to the PoS-based execution chain. [2]

Therefore, we need to move from a PoW environment to a fully mature PoS environment. Please note, however, that this shift does not improve the bandwidth of the blockchain (how many transactions are executed in one block). This is the problem to be solved by sharding. Before that, let us discuss what methods can improve the scalability of execution when we only have one execution chain.


Figure: Put execution under the chain; put data on the chain

(Color summary: consensus=purple, execution=green, data=yellow)

Speaking of rollups, this is one of many available expansion solutions, but from the point of view of protocol design, this solution may provide the best compromise. The idea of ​​this scheme is simple: by storing data on the chain (the data is used to reconstruct the execution of the state transition) to comprehensively handle the state transition, and put the execution of the state off the chain. If someone disagrees with the result of the execution, or someone forgets to execute it in the first place, the data is on the chain for everyone to use (recalculation is possible), which is completely permissionless!

More precisely, the data required for execution (transaction input) is separated from its carrier (transaction) and “bundled” in a space-saving manner. At the same time, rollups run outside the execution chain (eth1), submit and execute data.


Figure: Several rollups have been deployed, and more are under development

The user needs to pledge an asset to the rollup contract on the execution chain (“eth1”) to be able to enter the rollup, where the user can conduct transactions. After completion, the user can transfer the asset from the rollup back to the execution chain.

What is the alternative to Rollups? Let’s take a look at the picture above, let’s suppose, what if we replace the vertical yellow chains with a series of parallel red chains? For example, what if we copy several eth1 chains and run them side by side?

The question here is how to deal with multiple execution chains running in parallel. What if something happens on a certain chain, and other people need to know what to do? This is a very difficult problem faced by sharding, or a problem that needs to be overcome for schemes executed in multiple chains.

“There is no difference between Rollups”, readers may think so, there is nothing wrong with it in essence. But when you want to trade from one rollup to another, the same thorny problem reappears. However, the key point is that there are already several rollup designs, and the space for exploration of these solutions is still very wide. That being the case, why not let rollups experiment first and then introduce a protocol-level approach?

This brings us to…


Figure: Use shards to store data released by rollup

Readers should have heard of the lack of block space, right? Rollups do need to publish their data, but the eth1 block space is very scarce! And, as we discussed, cross-sharding is very difficult. In order to solve this problem, we can use sharding to save the data that the rollup needs to publish. There will likely be 64 fragments by then, which is 64 times the current available bandwidth. And a shard block may hold more data than the eth1 chain block currently can.

I need to emphasize that this does not mean that we will always exclude the implementation of fragmentation. The Ethereum roadmap centered on rollup is our short- and medium-term development goal, until we find a better encryption primitive to ensure that we can implement sharding across multiple chains. This scheme is very attractive and requires a lot of people in the team to spend a long time studying it. At the same time, we can use rollups.


Figure: Each rollup has its own execution environment

There is still a lot of work to be done in this regard! First of all, let us not forget that “merging” and “data sharding” are both very complex tasks, requiring multiple teams to work on one or both of them at the same time. But in terms of rollup, there are still some interesting issues to be explored, I only listed a few:

➤ Realizing large-scale migration between users and rollups is a cool concept. If the user has enough public transportation to get him back and forth between Layer1 (eth1) and Layer2 (rollups), then why bother to drive back and forth by himself? This is very uneconomical.

➤If the  user thinks that they can do something cooler on another rollup (the rollup where ta is in is not available), does ta have to first withdraw cash to L1, and then deposit from L1 into this rollup? This is too wasteful.

  For the current chain Operationally, rollups greatly improved network bandwidth, which is not in doubt. But rollups are still not the infinite highway that users expect. There are still many people who want to do many things on rollups, sometimes even at the same time! Therefore, rollups will inevitably face congestion problems, but unlike L1, which is a particularly congested market (it will be online soon in 1559), rollups have a wider range of exploration.

➤ Speaking of congestion, although this is more specific to the protocol level, we will also see EIP-1559 playing the role of a traffic policeman to specify how much data is published on each data shard to ensure that the verifier can handle this amount of data. If readers think it is cool to run EIP-1559 on eth1, then please look forward to running 1559 on 64 shard chains at the same time. So, where should rollups publish their data? Is it only published on a single shard so that the data is only available on that shard? Or is it published on multiple shards, so that you can benefit from the planned “shard staggering” solution? This plan is made up ofVitalik It is proposed that the fragments flow out of the block, so that when the data is released, the time to generate the new block is within a few hundred milliseconds. This is an ideal choice for applications that require “quick finalization”.

Thanks to Danny Ryan and Sacha Saint-Leger for their suggestions.

[1] I heard that PoW is not a consensus algorithm, but I think that if it overloads its definition, it is no problem to describe it as a consensus mechanism.

[2] PhiGo tweeted that after the merger (PoW withdraws from Ethereum), it may not necessarily be possible to withdraw pledge deposits. Indeed, the current merger plan is more focused on the merger part, and the “withdrawal” issue is an independent but related research work.

Leave a Reply
Related Posts

Win Free Tickets to Europe’s Largest Bitcoin Event

On October 12th, 13th and 14th, Europe’s largest Bitcoin (BTC) event will take place at the Westergasfabriek in Amsterdam. The smartest people in the Bitcoin world will be talking about all things Bitcoin at any time. Are you interested in participating in…
Read More

What are the Ethereum smart contracts and the ERC standard

 01Smart  Contract Before I talk about ERC, let’s talk to you about smart contracts. The concept of smart contracts was first proposed by Nick Sabo in 1994. He defined: A smart contract is a computerized transaction agreement that enforces the terms of a contract. The…
Read More