What’s on the post merge roadmap for Ethereum?
If you want a long read answer on this then you can check out the piece I wrote a few months ago
However the TL;DR is that Ethereum wants to be able to scale to handle more activity but reduce the resource requirement on validators in order to help optimize for decentralisation.
In line with this is a move away from the old ETH2.0 plans to have 64 data shards for scalability on the layer 1 (beacon chain) and instead to move to a rollup centric roadmap using layer 2s for scalability and the layer 1 for execution settlement.
Some key components within this plan which you will start to hear mentioned more across the ecosystem:
Data availability sampling
The idea here is that as long as you can prove that at some point the data was available, then you don’t need it to be always available. This is because as long as there’s at least one person watching out and doing the validity proofs on the data, then you can be confident that if something was wrong with the data, it would have been spotted.
With data availability sampling the plan is to move away from the layer 1 having a full state of the blockchain and users requiring this to verify new blocks, and instead to being able to do compact verifications using verkle proofs (part of the Verge stage) with lite clients.
Proposer Builder Separation
This is where you can have one entity building the block and another validating it.
The big benefit of this is that it reduces the requirement to be involved in the block building process from the current ‘do it all — validate, build the block, solve the PoW puzzle’ to a more manageable level for low computational -validation- nodes who just check the block is good to go and all data was made available and high resource — builders- who do the hard work of putting the block together (beacon chain block plus shard data and any bundles from MEV searchers).
From a fee perspective, the builders submit the block header (summary of the block) and a bid to the network, which is how much they will pay a proposer to share it out to the network. The proposer (who’s staking their ether) validates the block and proposes it to the network (probably just taking the one with the highest bid) and is ‘paid’ the bid. This means the builder will earn the tx fees plus and MEV from the block, minus the bid they pay to the proposer.
So to compare to today:
- builders are like the mining pools we see today — initially this is going to be run by flashbots but will eventually become more decentralised
- proposers are a brand new role
- searchers are just like the searchers we see today who hunt for MEV strategies and work with the miners/future builders
Protodank sharding (leading onto dank sharding later)
This is the new sharding design made possible by proper builder separation and will include the new blob transaction format (EIP4844) which is only expected to be stored on the beacon chain for a month.
The idea with protodank sharding (and inline with the Purge stage of the roadmap) is that all data older than one year is dropped from the layer 1 network (this is relating to EIP-4444).
Instead all historical data would be maintained by other services e.g IPFS, Storj, Arweave etc and only the most recent data would be available on the layer one. This helps to support the TL;DR ambition above of reducing resource requirements for validation.
These components all interplay with each other and the various stages of the longer term Ethereum roadmap but are terms you’ll start to hear more across the space as we move towards the Merge and developers and ecosystem players start to think about the post-merge world.
For a long read on this topic with amazing detail then you have to read the Vitalik acclaimed piece by Jon Charbonneau.
https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum
Originally published at https://www.linkedin.com.
