Vitalik recently updated the ETH roadmap, and we wanna share our interpretation of some interesting facts and hidden alpha.
There are six sections (black box) in total, and each section has several milestones (blue box). The completion of each milestone requires some technical solutions and proposals (in the green box).
The milestone A of The Merge section, "no more PoW" was successfully completed. The Withdrawal function of the ETH Staking is ~80% completed and we assumed that it will be launched soon, probably in Q1 2023. Looking forward to the "Shanghai upgrade".
The newly added milestone B of The Merge section is "Single Slot Finality (SSF)". What is Single Slot Finality? In the PoW era, it generally took 12 block confirmations for exchanges to process a deposit, but this is only a rough requirement. There is still a possibility of network forks. After switching to PoS, theoretically it takes 32 block confirmations to get finalized, which is absolutely irreversible/unforkable.
Roughly speaking, a slot is ≈ a block. SSF would mean that transactions are deterministically finalized in 1 slot (12 seconds) instead of the 32 slots, or 6.4 minutes.
This is not easy. In traditional BFT consensus, although a single consensus is irreversible every time, it cannot allow many nodes to join the network. Once there are more nodes, the performance requirements for equipment will increase exponentially; while the traditional PoW consensus can allow infinite nodes to join, it takes a longer time to achieve 99.99% irreversibility.
For SSF, it is expected to have more validators with lower threshold for participation and faster block confirmation.
It is dependent on the advancement of signature schemes (such as BLS). Many signatures can be combined together, which can largely improve the efficiency by verifying the combined signature at once. Efficiency gains enabled by signature schemes coupled with the committee mechanism bring in the possibility of single slot finality. Keep building, there is still a long way to go.
The second section, The Surge, is a very interesting one. It has added a very intuitive KPI: 100,000 TPS (However, in the parentheses, it says rollups are also considered lol).
The milestone A of this section is to complete the initial rollup expansion, which refers to the EIP-4844 proposal.
EIP-4844 (also known as proto-danksharding) is also written on the roadmap. It is less difficult to implement. Simply speaking, blobs are added to the ETH mainnet, so that all rollup data is stored in blobs instead of the main chain. It’s like people tend to build warehouses in the countryside with lower costs rather than in the downtown areas. This allows for more rollups while keeping the cost per rollup lower.
In addition, since 4844 is a simplified version, blobs are still going to be managed by the PoS nodes. In this way, the original plan of 16MB per blob has to be reduced to 1MB per blob for the nodes to handle it. Of course, 1MB is not bad, and it can reduce a lot of the rollup fees. The progress bar is about 60%, and seems like it’s being carried out smoothly.
The milestone B of the second phase is the full expansion of rollups. The focus is on the DA layer, which also serves for data storage.
An inappropriate metaphor is that storing these data on Ethereum is a bit like using a sledgehammer to crack a nut, so Ethereum decided to outsource this task. In order to prevent this outsourced data layer (DA) from being malicious, a data sampling survey (DA sampling) is also required, which requires the introduction of many cryptographic algorithms. It's under progress, though probably still in the theoretical demonstration stage lol.
Moreover, from the ETH’s official perspective, the technical maturity of ZK has only reached about 1/3, and the OP technology has reached about 1/2. That is to say, it’s like one of them is in kindergarten and the other is still a toddler, which is far from the ideal level.
It is not hard to guess that several ZK projects which are about to be launched are probably rushed through, and maybe a lot of centralized assumptions and compromises are being made.
The third section, The Scourge, is a new one. Its main target is MEV. We all know that MEV is bad. I have an address that Nansen labeled me as a Heavy Dex Trader plus Sandwich Attack Victim.
Nobody likes MEV, except…
However, MEV is a good business for PoS nodes. Another ruthless way to put it, bringing in MEV under PoS is actually competing for profit against users on chain.
Back to the roadmap, fortunately, ETH still believes that transaction packing needs to be “neutral”. The currently selected option is to use PBS to reduce the effect of MEV.
Proposer/Builder Separation (PBS) divides the roles of block proposers and block builders. Block proposers are only responsible for submitting a block to the ethereum, while block builders only do TX ordering.
It simplifies the process and makes it a little bit harder to bribe, which is somewhat better. But it can't solve the fundamental problems, it’s just a relief. After all, PBS only weakens the power of nodes and makes the bids public.
In addition, there are a few questions left in the roadmap, which may be the next research direction:
-Can DApps directly help you with pre-confirmations?
For example, AAVE helps you make an internal reservation for a successful transaction;
-Can DApps publicly ban sandwiches to protect users (frontrunning-protection)?
Uniswap, for example, bans sandwich robots.
Btw, only 20-40% of the work has been done for PBS. There’s only one part of it has been completed, the external MEV market. This probably refers to flashbot.
The fourth section, The Verge (which was the third section of the old roadmap), has remained almost the same. The main milestone is to build the Verkel tree. If it comes out, validating blocks will be way faster and smoother. This work is still in progress, even faster than the PBS in the previous section.
Another change is that it was considered an interesting top for Ethereum to become fully ZK (fully SNARKEed ETH), but now L1 ZK is explicitly added to The Verge section of the updated roadmap. Note that it is not L2. It’s L1 that needs to be ZK. Of course, related work on it has not yet begun.
Additionally, all of the first four sections mentioned quantum-resistance, which is an important but not so urgent issue to be addressed bcuz quantum computing still has a long way to go.
The Purge, the fifth section, represented by a broom emoji. The most important thing in this section is to complete some of the "technical debt" owed in the early years.
In the early stage, Ethereum wasn’t too clear about many structures, such as the preservation of history & state, and now it’s time to improve all of those at once.
Compared to the old version, EIP-4444 has been explicitly written on the new roadmap now.
The core essence of EIP-4444 is the requirement that long-dated historical data (>1 year) must be trimmed by the client, and the P2P network will no longer transmit them.
Note that this does not mean those data are going to be completely deleted. They are still accessible from archived nodes. The blockchain ledger is the foundation and always remains trimmed.
Fun fact: EIP-4444 officially requires that it has to be pronounced as "four fours".
The same goes for the expired states. In fact, theoretically as long as there is a ledger, all transactions in each account can be deduced. But in practice, it would be too slow to conduct this every time. Therefore, Ethereum also maintains a state tree. It could show how many tokens are in account A or in account B at any certain moment, which will be much faster for everyone to check.
But the cost of being "fast" is that too much state data could take several GBs to store, which is too difficult for many nodes to handle.
Allowing more home-level nodes to store the ledgers is always the biggest pursuit of ETH (and BTC). So in order to accomplish this goal, the state thing should be cut. State expiry is designed to do this, but I understand that the current plan... In fact, it is not very clear, and it has not started yet.
In addition, some EVM optimization work, such as ban SELF-DESTRUCT (a mechanism for gas refunds), simplify gas mechanics, etc., should also be done in the fifth section.
The final section, The Splurge, has a special meaning: fix everything else.
-For EVM, many things need to be optimized;
-For VDF, to generate real random numbers on chain.
In fact, there are also previous roadmaps for VDF, but it seems that the realization of VDF requires hardware cooperation (focus).
EIP-4337 is also a new proposal. Account abstraction has been introduced lots of times, and here is a brief description: In the past, smart contracts could only be used for on-chain transactions and now they can be applied directly for your wallet.
For example:
-
Wallet recovery via social media
-
Protocols will pay the gas fees for you in advance
-
USDT could be used as gas etc.
A new transaction mempool is required to achieve this. Those transactions that are prepaid by others will all get processed here.
Did you realize it? This does not require any modification of ETH. There were actually quite a few alternatives to the 4337 proposal, but the reason why it ultimately stands out from all the other proposals is that it does not require modification to the consensus layer. Everyone prefers the patches to the hard forks, which may jeopardize the blockchain.
Account abstraction is actually a good thing, although the name is too abstract to understand, Lol. This is the key to mass adoption. Without this, ETH would never be able to break through the bottleneck of tens of millions of users. However, in fact, it should be placed at an earlier section. Although they are all developed in parallel, the priorities are obviously different.
Endgame! What would the Ethereum's Endgame be like? $ETH will be a chain with high-performance, strong security, large number of nodes, and censorship-resistance. At the same time, it has a very easy-to-use front-end and back-end, which may lead us away from this trust-dependent world that is full of black boxes at the moment. Looking forward to that day!
Author:
@0xTodd | Nothing Research Partner
Nancy Lin | Nothing Research Analyst
Email: