Post-merge, redundancies and network inefficiencies will remain, which will eventually need to be addressed. A "clean up" period will be required, but it will also enable highly-anticipated functionalities like the ability for withdrawals and transfers of staked ETH from the Beacon Chain.

In this part 2, we cover the years ahead, looking well into Ethereum’s (ever-changing) roadmap. Let’s dig in.

Roadmap

There is no official roadmap for Ethereum, as it is predicated more on rough community consensus. However, a high-level, noncontroversial plan stretching into 2023-24 is generally regarded as the agreed-upon path for the project. A more technical roadmap with the progress of each step filled in was updated by Vitalik Buterin in December 2021. Specific developments are tied to future upgrades and are always subject to change. A high-level diagram of the roadmap can be seen below.

Unofficial Ethereum roadmap (with progress bars) spanning into 2023. Source

The roadmap can be broken up into the following informal stages:

The Merge: Merging consensus and execution layers, removes PoW.
The Surge: introducing sharding, ~2023.
The Verge: Optimise for storage and state size.
The Purge: Reduce congestion and improve storage.
The Splurge: Miscellaneous optimizations.

Ethereum’s roadmap is constantly evolving; however, the flagship upgrades post-merge are the introduction of shard chains to help the network increase transaction throughput, improvements to rollups, and improving Ethereum’s ability to manage data storage. Utilization of Zero-Knowledge (ZK) snarks is also very possible in the future as a means of reducing the storage requirements on-chain while ensuring relatively easy validation.

These stages on the roadmap are not sequential and are being worked on concurrently.

The Surge

The Surge itself then is focused on improving scalability at its data availability layer through data sharding. Sharding is the partitioning of a database (or blockchain) into subsections. Rather than building layers atop one another (e.g., L2s or Bitcoin’s Lightning Network), sharding scales out or horizontally without a hierarchy or layered structure. Doing so does not create more burden for the average user.

In this sharding model, validators are assigned to specific shards and only process and validate transactions in that shard. In Ethereum's planned sharding model, validators are randomly selected. Every shard has a (pseudo) randomly-chosen committee of validators that ensures it is (nearly) impossible for an attacker controlling less than ⅓ of all validators to attack a single shard. This also means they are only responsible for processing and validating transactions in those specific shards, not the entirety of the network. The randomness of the validator selection process ensures it’s (nearly) impossible for a nefarious actor to successfully attack the network.

eth sharding — Original diagram by Hsiao-wei Wang, design by Quantstamp

Shards will be divided among nodes so that every individual node is doing less work. But collectively, all of the necessary work is getting done—and more quickly. More than one node will process each individual data unit, but no single node has to process all of the data anymore.

Initially, prior to the breakthrough in rollups, Ethereum’s plan was to do sharded computation. However, now with rollups providing the much-needed network scalability, sharding will focus on data availability to provide throughput for the rollups. Ethereum developers are looking to implement Danksharding (named after Ethereum researcher Dankrad Feist), which aims to improve the efficiency and cost of L2 rollups. This is because the bottleneck for rollup scalability is data availability capacity rather than execution capacity. This will give L2s more space to store the chain’s data and offer additional data capacity for rollups.

In a sense, shards will serve as data storage “buckets” for new network data storage demands from rollups. This enables tremendous scalability gains on the rollup execution layer. Just as significant, shards will also help avoid putting overly-onerous demand on full nodes, allowing the network to maintain decentralization.

Sharding will be released in a multi-step process to provide immediate data availability for rollups before releasing the ultimate but more complex vision. A small subset of data shards (four) will initially be released to keep complexity low, i.e., a slow, controlled rollout.

Earlier, we outlined one reason why Ethereum transaction fees were so high was due to all nodes in the network having to process all transactions and reach consensus. Sharding is the answer to the question, “What if each node did not have to process every operation at the same time?” What if, instead, the network was divided into subsections (shards) that operated semi-independently until finally reaching consensus through a central hub (Beacon Chain)?

Shard 1 could process one batch of transactions while Shard B processes another batch. This would effectively double the transaction throughput of a blockchain since our limit is now what can be processed by two nodes at the same time. If we can split a blockchain into many different sections, then we can increase the throughput of a blockchain by many multiples.

Ethereum will be split into different shards, each one independently processing transactions. Sharding is often referred to as a Layer 1 scaling solution because it’s implemented at the base-level protocol of Ethereum itself.

EIP-4488

Rolling out a 100% complete version of danksharding is incredibly complex and will likely take 1,2,3+ years. Because of this, there are intermediary options being discussed, including EIP-4488 and EIP-4844 (proto-danksharding).

EIP-4488 is the simplest and quickest way to improve rollups and drive down costs. However, it also has the least amount of attention currently. So, what is it?

EIP-4488 attempts to reduce rollup costs (while mitigating storage bloat) through two primary factors:

Reduce calldata cost from 16 gas per byte to 3 gas per byte
A limit of 1 MB per block plus an extra 300 bytes per transaction (theoretical max: ~1.4 MB)

This change could be implemented in terms of months, not years, and could reduce rollup costs by ~80%!

EIP-4844 (Proto-danksharding or PDS)

Proto-danksharding (PDS) is an alternative to EIP-4488 but is still a temporary stepping stone to the ultimate goal of “full” danksharding. However, even PDS is quite complex. Rather than rollups using "calldata" storage (permanently on-chain), under PDS, rollups could post bundles under a new “blob” transaction type which is much cheaper.

Rollup transactions would have their own “channel,” operating through a novel data blob market that uses its own fee structure and floating gas limits. This means that even with heightened demand and activity from DeFi or NFTs, data costs won’t go up for rollups. This creates two different gas markets - one for general computation and one specifically for data availability (DA), making the overall economic model more efficient than it was previously.

Data blobs are an entirely new transaction format, and only the blob’s hash can be accessed via a new opcode. This guarantees the data content will never be accessed by the EVM, reducing the gas cost of posting the data compared to with calldata. Blob transactions can enable up to ~1MB average per block for data storage as opposed to the 10KB currently with calldata. It also has been proposed that they could be pruned (removed) from the L1 after a ~month to reduce storage overhead requirements.

The Verge

In Vitalik's revised Ethereum roadmap, the Verge era will represent a new technique for verifying blocks at the protocol level. The Verge and its changes would create a fully SNARK-enabled Ethereum. The Verge will work to enhance Ethereum's scalability and optimize storage utilizing Verkle Trees, a type of mathematical proof improving upon the currently used Merkle proofs. By decreasing the amount of data that validators must store on their computers in order to execute operations, node sizes will decrease, and more users will be able to serve as validators. This will boost network decentralization and security.

The Purge

The Purge aims to reduce blockchain "bloat" and make it easier for anyone to run a full node. By pruning past data, the Purge will reduce hardware needs and streamline storage for PoS validators. It will reduce the amount of historical data validators must retain, making it simpler to operate a node. Together with The Verge, we strive to reduce the quantity of historical data required for validators. The ultimate objective is to develop a "stateless Ethereum" in which validators can verify blocks without having to store the whole Ethereum chain.

The Splurge

The Splurge looks to implement all the additional ancillary improvements that have been proposed over the years. This has been referred to as the "fine-tuning" stage.

There is also the possible implementation of Proposal–Builder Separation (PBS) sometime around this stage, which aims to limit the impact of detrimental MEV. After The Merge, validators maintain the ability to construct and propose blocks; in the future, however, these responsibilities may be split in order to distribute MEV incentives more equitably to all validators, including solo-stakers.

Proposer-Builder Separation (PBS)

MEV refers to the maximum amount of value that can be extracted by deciding the transaction order of any given block. As discussed previously, a block proposer (or miner) in a traditional blockchain can choose which transactions to include from the memepool into the next block based on the highest transaction fees. This essentially opens up the possibility of coordinated censoring of transactions and promotes an increasing degree of centralization within the Ethereum ecosystem.

This also negatively impacts users in some pretty damaging ways. For instance, MEV instigates the concept of gas bidding wars as users attempt to outduel one another to get transactions confirmed on the blockchain. This can create significant spikes in gas costs for users and price out everyday users from accessing the Ethereum network.

To circumvent this problem, DS relies on a concept called Proposer-Builder Separation (PBS).

There are three entities in the new PBS Ethereum:

1. Builders - highly sophisticated actors that physically build the blocks maximizing for MEV and then bid them out to validators

2. Relayers- known middle-men with reputational risk to receive blocks from Builders, hash it, and relay on to the validators

3. Validators -simply accept the block with the highest bid and block rewards (without knowing the contents)

In part 3, we will go into detail about the roles, responsibilities, and natural checks and balances that each role carries. Stay tuned!

Loading...