IOSG Research: Will Danksharding, the Scalability Killer, Be the Future of Ethereum Sharding?

Author: Gokhan Er, IOSG Ventures

Vitalik's recent proposal for the blockchain architecture "Finality" has sparked widespread discussion, and we have roughly distilled this grand roadmap into the following three points:

• Centralized block producers
• Trustless and decentralized block validation
• Anti-censorship mechanisms that remove the incentive for these block producers to censor transactions.

With the rise of MEV and cross-domain MEV, it is evident that block production is destined to become increasingly centralized—due to the benefits and economies of scale brought about by producing blocks simultaneously in many areas (such as rollups). In such a mechanism, a single block producer can seize arbitrage opportunities across different rollups and layer 1s.

(Image source: https://vitalik.ca/)

Vitalik even goes further to assert that today's "large block" type blockchains (like Solana, BCH, etc.) need to follow a similar architecture if they want to achieve decentralization, avoid censorship, and scale simultaneously. Given the network effects that rollups or cross-domain MEV can bring, the centralization of block producers is largely unavoidable, so accepting this fact and making adjustments at the protocol level to ensure that block producers do not interfere with the security and anti-censorship of layer 1 should be our best option. Consequently, the recently controversial buzzword "Danksharding" in the Ethereum community naturally draws our attention. Before deconstructing this technology, we will first introduce the important design of PBS to help us better understand Danksharding.

PBS: Separation of Block Proposers and Builders

If centralized block production has become an unavoidable reality, then the most feasible solution to prevent further centralization is to separate block production from block validation (proposing).

We know that in the current architecture, generally only one party is responsible for block production (miners), and they directly select which transactions to undertake from the memory pool (Mempool) to create blocks. Moreover, the more complex the tasks of these miners, the more value they can extract, leading to miner centralization.

In the design of PBS, the role of builders is distinctly separated. They select transactions from the mempool and sort them with the goal of maximizing profit. Once they create the list of transactions they wish to undertake, they submit their bids to the validators (block proposers). In this case, the task of the validators (block proposers) is to select the highest bidder to create the block. Block proposers simply collect transactions from the mempool and create a crList, which is essentially a list containing block transaction information. The block proposer passes this crList to the block builders. The block builders then reorder the transactions in the crList according to their own preferences to maximize their MEV extraction. Therefore, when it comes to how transactions are sorted, block proposers have no say, but by providing builders with a list of block transaction information (crList), they ensure that all transactions from the mempool can enter the block without censorship.

Thus, the design of PBS essentially establishes a firewall and market between proposers and builders. While the work of block producers will become complex and centralized, it is crucial to ensure that the requirements for running validation nodes can be met so that they can be operated by general servers at a very low cost (as opposed to the sophisticated servers run by block producers). This realization is thanks to the PBS scheme.

Having understood the above, we return to Danksharding.

What is Danksharding? Why is the whole world talking about it? First, let’s explain the origin of the name Danksharding. Danksharding is named after the Ethereum developer Dankrad Feist, who replaced the previous parallel data sharding model and redesigned the system around cross-domain MEV resistance (thus maximizing the chain's security and decentralization). The previous sharding design did not have PBS, and each shard and the beacon chain had independent validators. This design was based on the past belief that having as many shard validators as possible could maximize censorship resistance.

(Image source: Dude, What's the Danksharding situation?)

However, as the MEV issue becomes increasingly thorny, separating block builders from their proposers has become a significant demand. This independent structure of block creators and block proposers (PBS) is the only solution to democratize the MEV issue and prevent it from further jeopardizing the security of the protocol.

Returning to Danksharding, Dankrad's basic conceptual design is that in any sharding design, there are MEV opportunities under a multi-shard architecture, leading to the problem of centralized multi-shard builders. The only way to solve this problem is to implement this PBS architecture. The existence of block proposers identifies and addresses the centralization problem of block creation, fundamentally preventing any actions that could harm the security of the chain.

(Image source: Dude, What's the Danksharding situation?)

In this new design, beacon blocks will contain all shard blocks, and all beacon blocks and shard data will be uniformly certified by a committee composed of validators. This way, transactions from the same beacon block can access shard data and even achieve synchronized transactions between rollups and layer 1, greatly simplifying the structure of rollups, and issues like confirmation delays will no longer exist. So what about the anti-censorship situation of Danksharding? Can centralized block creators still censor specific transaction records by participating in the same block? The innovation of crLists can address the aforementioned issues. The responsibility of block proposers is to list all the transaction records they see in the mempool. Then, block builders will refine a hash value based on this list and prove that all data in the list has been included. However, recent discussions indicate that the design of proposers and validators, as well as the tools for crLists, still need final confirmation. An upgraded version of data sampling is also another important design of Danksharding, which ensures that when beacon nodes provide data, there is no need to store all the data, and we will not elaborate further on this here.

Overall, Danksharding has several noteworthy advantages:

• An increasingly simple sharding design; the new model will reduce the original workload by a hundredfold.
• Based on the PBS model, whether complex or advanced block creators will not pose a problem for the security of Ethereum. It can ensure that Ethereum increases block size without worrying about centralization issues.
• The merging of shard data and beacon chain data will accelerate the synchronization speed between layer 1 and zk rollups, thereby simplifying the structure of rollups.
• crLists can ensure immediate transaction validation on L1 (similar to the same concept on layer 2).
• Cross-shard MEV will be democratized (just like what Flashbots does), and potential validator centralization issues can be prevented.

As a new model proposed by Ethereum core researchers a month ago, Danksharding is still in its infancy, and more innovations and optimizations will come in the future. However, it is evident that Ethereum's sharding plan will progress steadily, step by step. Let us stay tuned!