Sharding Reimagined

^“The Ethereum ecosystem is likely to be all-in on rollups…as a scaling strategy for the near and midterm future.” Taken from Vitalik Buterin’s A rollup-centric ethereum roadmap, this quote is based on the observation that sharding as initially imagined is a long way off and that a part of the initial roadmap – making Ethereum more rollup-friendly – is relatively closer. Vitalik goes on: “It seems very plausible to me that when phase 2 finally comes, essentially no one will care about it,”; here ‘phase 2’ refers to sharding as initially imagined. Implicitly, if Ethereum effectively accommodates rollups, they may develop, and be adopted, to a point where the initial sharding plan is irrelevant.

The idea behind the last phase of the initial roadmap was to divide up the network into pieces, or shards, and in so doing the network moves from serial processing to parallel processing – multiple blocks are created and then woven together by the Beacon Chain. The rollup-centric roadmap recognizes that this last phase of sharding, i.e., dividing validators into 64 groups, may not be necessary.

Danksharding – Where We Want to Go:

From a high level, Danksharding is about more blockspace and encouraging rollups to use this space by lowering the cost. When comparing Danksharding to the earlier sharding roadmap (i.e., 64 separate shards building blocks) it is likely helpful to forget about sharding altogether. What Danksharding ultimately looks like is more blockspace per block and the capability of Ethereum to act as a data availability layer for rollups. These changes should be viewed as additive – today’s Ethereum is not replaced, but has this data availability aspect added to it.

Proposer-Builder Separation (PBS) is an important piece allowing for Danksharding. PBS is likely to be built into Ethereum in the future and has been suggested as a way to remedy the centralizing tendency of Maximal Extractible Value (MEV).

The idea with PBS is to create a new group – builders – who are responsible for block construction, while a separate group – validators (or proposers) – are responsible for proposing these blocks. Under this setup, proposers wouldn’t be able to view the contents of the blocks until after they have been proposed. This would eliminate the risk that proposers would be able to “steal opportunities” from searchers/builders. In fact, PBS already exists for validators running MEV-boost – validators are connected to relays, which are connected to builders; the builders supply blocks to the validators to propose (see here for more).

Adding to PBS the assumption that builders will become specialized, i.e., they will have higher computational resources, Danksharding will be able to rely on builders to manage the greater computational demands of block building. This is important because Danksharding is likely to have a 16MB target block size (max 32 MB) compared to an average block size of about 85 kB (and max of 1.8 MB) today.

One element of Danksharding that still resembles sharding is data availability sampling (DAS). DAS solves the problem of confirming availability of the entire block without requiring each validator download the whole block. This is especially important for ‘home validators’ that may not have high computational resources.

‍

Proto-Danksharding

Proto-Danksharding (EIP-4844) is best thought of as a step along the way to Danksharding. Importantly, it sets up blob transactions, which carry data used by rollups. This new transaction type has the ability to make blockspace cheaper for rollups and move Ethereum closer to Danksharding. In fact, it is these blob transactions that add the ‘data availability layer’ functionality to Ethereum mentioned above. However, there will not be a significant increase in blockspace (that will come later with Danksharding):

‍

This means that the computational resources currently in use will be sufficient to manage this change (i.e., no need to rely on builders with advanced hardware).

To get to Danksharding from Proto-Danksharding a few more changes are required. Due to the jump in blockspace from a target of 1 to 16 MB, data availability sampling (DAS) is required to allow validators to easily verify availability without downloading the full data blob. Additionally, the likely specialization of builders due to PBS, will mean that they have the computational resources to handle the increased load of building 16MB blocks.

‍

Going Deeper

It is important to bear in mind that none of this has yet been implemented and much can change. That said, EIP-4844 is relatively well-developed and much work has been done.

Beyond the high level description above, there is much more going on under the hood. For instance, there is some moderately complex math (see Erasure Coding and Reed-Solomon Code) that goes into DAS. Furthermore, KZG commitments are required as a kind of check on the DAS process, ensuring that the process allowing for the sampling was done correctly; in other words, the pieces being sampled accurately reflect the larger whole from which they were taken.

Additionally, there is another entire process dealing with censorship resistance. The worry is that builders could choose to only allow certain transactions to be included in a block. There is a potential trustless solution involving communication between the proposers (i.e., validators) and builders (crList = Censorship Resistance List):

For a much more in depth look at Danksharding and Proto-Danksharing see The Hitchhiker’s Guide to Ethereum and watch Dude, what’s the Danksharding situation?.

‍

One More Time From the Top

There is a lot to grapple with to fully understand Danksharding, but the big picture is that Ethereum could lean more heavily on rollups given the clear success they have had in scaling. To encourage this along, a new data blob carrying transaction is envisioned (i.e., EIP-4844) and the cost of this kind of data is likely to be a lot lower than regular calldata (data currently in use). With PBS and the specialization of builders, more blockspace can be made available.

It is worth emphasizing that Danksharding does not preclude the initial roadmap – sharding Ethereum into 64 (or some other number) shards – it just implies this last step may not be needed in the end.

‍

What Does This Mean for Stakers?

Danksharding deals with the scalability of Ethereum, so it most directly affects users. That said, there is the potential to see lower fee transactions, that is, transactions in which users are more sensitive to fees, move to rollups, freeing up blockspace for higher fee transactions, such as MEV extracting transactions. Additionally, PBS, which Danksharding leans on heavily, could have a meaningful impact on MEV fee sharing. The idea is that increased competition among builders could result in a higher proportion of MEV fees being shared with validators and stakers(2). In a more general way, making Ethereum more scalable helps to foster wider adoption and ensure the long term success of Ethereum.

‍

(1) – This pertains to the Flashbots market only.

(2) – Figment recently published its policy on MEV (see here for more).