Diagram of the development route of Ethereum
Source | barnabe.substack.com
Author | Barnabé Monnot
The following is adapted from a presentation on Friday, April 9
This article is about the road to the future of Ethereum. The Eth2 developer team refers to the current Ethereum as "eth1", which is now known as the PoW chain. And the future Ethereum is neither eth1 nor eth2, but...Ethereum:
image description
text
image description
Figure: PoS mechanism replaces PoW mechanism
PoW isn't all bad, but I need a catchy title
PoW requires a lot of hardware to run intensive calculations, resulting in excessive energy consumption. We don't talk about resource waste like most cryptocurrency critics (their usual rhetoric is "why should we use a payment system that consumes national resources?"), what we advocate is that since we can pay relatively Small consumption to do the same thing, then we should do so.
image description
Figure: If they do not do the verification work in the second step, they will lose assets
image description
text
The consensus layer ensures that everyone agrees on a certain piece of correct data. And the execution layer actually interprets this data to make sense. "Data" is any form of interaction with the blockchain, such as deploying a contract, making a transaction on an exchange, sending a payment transaction, etc...
At its core, a blockchain is about adding 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 aggregates all data from blocks 0 to N.
image description
The first step is to decouple the consensus layer from the execution layer; the second step is to transfer from PoW to PoS
image description
Figure: The first step has been completed
Since December 2020, we have two chains running at the same time:
➤ The first one is the PoS-consensus chain (also known as the beacon chain)
➤ The second is our reliable PoW-consensus + execution chain (aka, eth1)
image description
Figure: How to become a validator
image description
Figure: Merge
Hopefully, this inability to communicate won't last too long. "Merge" permanently bridges the PoS-consensus chain and the PoW-consensus+execution chain, which means that validators can produce blocks for the execution layer. After the merger, we have two kinds of chains:
➤ PoS-consensus chain
➤ A PoS-based execution chain (i.e. "eth1" chain)
After the merger, validators of the PoS-consensus chain will be able to redeem and withdraw their staked deposits and rewards and send them back to the PoS-based execution chain. [2]
image description
image description
(Color summary: consensus=purple, execution=green, data=yellow)
Speaking of rollups, this is one of many scaling solutions available, but from a protocol design point of view, this solution may provide the optimal compromise. The idea of this scheme is simple: handle state transitions synthetically by storing data on-chain (which is used to reconstruct the execution of state transitions), and put the execution of the state off-chain. If someone disagrees with the outcome of the execution, or if someone forgets to execute it in the first place, the data is on-chain and available to everyone (and can be recalculated), completely permissionless!
image description
Figure: Several rollups solutions have been deployed, and more are under development
The user needs to go to the execution chain ("eth1"The rollup contract on ) pledges an asset to be able to enter the rollup, where users can trade. Once complete, users can transfer assets from the rollup back into the execution chain.
What are the alternatives to Rollups? Take a look at the above picture, let's imagine, what if we replace those vertical yellow chains with a series of parallel red chains? For example, what if we replicated several eth1 chains and ran them side-by-side?
The problem here is how to handle multiple execution chains running in parallel. What if something happens on one chain and others need to know? This is a very difficult problem for sharding, or a problem that needs to be overcome for schemes executed in multiple chains.
"There is no difference between Rollups", the reader may think so, there is nothing inherently wrong with this. But when you want to transfer from one rollup to another rollup, the same tricky problem arises again. The point, however, is that several rollup designs already exist, and the exploreable space for these solutions is still very wide. That being the case, why not let rollups be experimented with first, and then introduce a protocol-level approach?
image description
Figure: Use shards to store data published by rollup
Readers should have heard of insufficient block space, right? Rollups do need to publish their data, but eth1 block space is scarce! Also, as we've discussed, cross-sharding is very hard. In order to solve this problem, we can use fragmentation to save the data that rollup needs to publish. At that point there will likely be 64 shards, or 64 times the bandwidth available today. And a shard block may hold more data than the eth1 chain block currently can hold.
image description
Figure: Each rollup has its own execution environment
There is still a lot of work to be done in this area! First of all, let's not forget that both "merging" and "data sharding" are very complex tasks that require 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 list some of them:
➤ Enabling mass migration between users and rollups is a cool concept. If users have enough public transportation to get them back and forth between Layer1 (eth1) and Layer2 (rollups), why should they drive themselves back and forth? This is very uneconomical.
➤ If the user thinks that he can do some cool things on another rollup (the rollup he is in does not exist), does he have to withdraw to L1 first, and then deposit into this rollup from L1? This is too wasteful.
➤ There is no doubt that rollups greatly increase network bandwidth for current on-chain operations. But rollups still aren't the infinite highways users expect. There are still many people who want to do many things on rollups, sometimes at the same time! Therefore, rollups will inevitably face congestion problems, but unlike L1, which is a particularly congested market (1559 will be launched soon), the exploreable space of rollups is wider.
➤ Speaking of congestion, while this is more specific to the protocol level, we'll also see EIP-1559 acting as a traffic policeman to dictate how much data is published on each shard, ensuring validators can handle that amount. If you think running EIP-1559 on eth1 is cool, look forward to running 1559 on all 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 it can benefit from the planned "shard staggering" scheme? This solution was proposed by Vitalik, that is, shards take turns to produce blocks, so that when publishing data, the time from the generation of new blocks is within a few hundred milliseconds, which is ideal for applications that require "quick finalization".
Special thanks to Danny Ryan and Sacha Saint-Leger for their suggestions.
[1] I've heard that PoW is not a consensus algorithm, but I think it's fine to describe it as a consensus mechanism if it overloads its definition.
[2] PhiGo wrote on Twitter that after the merger (PoW exits Ethereum), it is not necessarily possible to withdraw pledged deposits. It is true that currently the merger program is more focused on the merger part, while the "withdrawal" issue is a separate but related research effort.
