A new sharding design called proto-danksharding has been introduced as part of the roadmap to full blockchain sharding.  Because it is so new, many people do not yet understand it. 

This overview will give a thorough, easy-to-understand analysis of everything you need to know about proto-danksharding and how it would help Layer 2s scale. Let’s dive in.

What is sharding?

Sharding refers to splitting a blockchain into smaller portions to enhance overall efficiency. 

For example: Instead of processing a transaction worth $100,000 on the Ethereum Mainnet, the transaction can be broken into ten shards, each bearing the data of $10,000 worth of transactions. This is intended to reduce network congestion. 

Apart from speed, shard chains provide greater storage and reduce fees. 

It’s important to note that sharding is an implementation that will go through various phases before arriving at the final stage.

What is danksharding?

Danksharding is a sharding design that implements the concept of a merged market fee; unlike regular sharding, in which shards have both different block and block proposers, only one proposer exists in danksharding. 

The block builders have the duty of choosing the data and transactions that go into each slot of a block. 

Danksharding and sharding are interrelated, but they are different. While sharding is the overall design for the splitting of networks in an effort to scale Ethereum, danksharding is a step towards the actualization of this goal. 

Tim Beiko—one of the foremost Ethereum researchers—explained on the Bankless podcast the origin of the name Danksharding, which was named after another veteran Ethereum researcher, Dankrad Feist. 

How does danksharding work?

Block builders push a request to determine what goes into each slot that will later form a block, and then, it is left to the proposer to select the highest bidder. Once a builder has been chosen to oversee a slot, they have the onus of processing the entire block.

In some cases, it is possible that oracles can carry out the role of a block builder. According to the Ethereum team, the main reason behind this design is to curb the two unfair controls that the miners currently have – Maximum Extractable Value, or MEV. 

First, miners can show unfair preference by choosing their transactions or the ones of those they know. Secondly, miners can hand-pick transactions with the highest bidder, thereby leaving millions of other transactions in the mempool for hours or days. 

With danksharding, however, no one knows the contents of the ordered list of transactions that a builder submits. Therefore, the power of the proposers is curtailed. 

What is the difference between block builders and proposers?

Block builders carry out the role of block construction, while block proposers select transaction headers that should be added to the block and broadcast them accordingly. These two work hand-in-hand. 

Block builders bundle up transactions into slots or chunks so they can be added to a block, and then builders submit them to the proposers for selection. After the proposer successfully selects a block, the block builders will process the block. 

Data Availability Sampling in Danksharding

A basic tenet of blockchain is transparency. If a mischievous or invalid block is added to a chain, it can be bad for the entire network. 

Usually, in the Ethereum ecosystem, full nodes can present fraud proofs to light clients—and the entire network at large—as evidence that a transaction is not valid. But this only works well with roll-ups and may not quite work for danksharding. 

Miners can verify danksharded blocks when they sample the available data. First of all, data availability connotes that the underlying data behind a particular hash has been published on-chain. At this year’s ETH Dubai, Protolambda explained data availability to mean the permissionless ability to reconstruct the state. 

In practice, this data availability sampling is implemented with the erasure codes. The erasure codes can be sampled to get the actual data that was added to the slot or block. 

After the transactions have been processed, there may be ongoing arguments concerning when the data should be deleted from the Ethereum blockchain to avoid bottlenecking the throughput. 

Presently, there are plans that the data will be deleted after a month. Nevertheless, even after the expiry date, the data will still be accessible via various means such as Graph Protocol and block explorers. 

What is proto-danksharding (EIP-4844)?

As it stands, there are still a lot of things to be settled in the bid to actualize full danksharding. This led to the creation of the EIP-4844 proposal, which is a format that implements proto-danksharding.  

This proposal aims to implement core changes—particularly transaction format—that would be needed for full sharding. The name proto-danksharding was also coined from the name of another Ethereum researcher - Proto Lambda.

The actual change that Proto Lambda introduced to danksharding is called Binary Large Objects, often called “blobs” for short. Indeed, blobs aren’t new concepts in programming, as they exist in JavaScript and Python. What is new, however, is the possibility that blobs can be relevant in smart contracts. To understand that better, we need to ask the question, “What are blobs?”

What are blobs (Binary Large Objects)?

Blobs are proposed by the block proposers. They are likened to big wraps or large portable bundles that can contain cheaper data. Each block can hold a limited size of these big wraps. In terms of structure, a typical blob has a body and a header. 

The body of a blob always stores the relevant pieces of data that relate directly to transactions. A header, on the other hand, contains lesser pieces of information, such as the signature of the proposer. 

In proto-danksharding, each transaction always has a blob twin, and the end goal of this is to make transactions cheaper.  To enhance scalability, each slot in proto-danksharding would mostly have 1 MB data bandwidth. 

Note: the Ethereum Virtual Machine can only access the cheaper data that is wrapped in a blob, and not the blobs themselves because transactions in danksharding will not be in the usual mempool, but instead a different one. 

What is the difference between EIP-4844 and EIP-4488?

This is the difference: EIP-4844 is providing solutions that align with—and even fast-track—the entire sharding roadmap, while EIP-4488 only attempts to solve problems for the time being. 

At its core, EIP-4488 attempts to drastically reduce the gas cost of call data. Although that can help for now, it would be irrelevant if there were full sharding, as shards would use blobs. On the other hand, EIP-4844 plans to use blobs in its transactional format. 

Nonetheless, we must also bear in mind that these two proposals do not need to be perceived as competitive or as trade-offs. While proto-danksharding might take time due to a couple of engineering technicalities, EIP-4488 can be implemented to solve interim cost problems using roll-ups. 

Will proto-danksharding reduce gas fees

The answer to this is a clear “No.” Proto-danksharding won't reduce Ethereum gas fees, but it will reduce the transaction costs of Layer 2 protocols. 

Indeed, this question comes up a lot in conversations about proto-danksharding. This misconception is bound to happen because proto-danksharding will introduce blobs. 

Even then, blobs will only replace call data that roll-ups usually use. Therefore, the gas fees on the Ethereum protocol will still be the same. 

Indeed, developers who have been following the updates of the Ethereum ecosystem for years now will agree that most of the proposals out right now will not directly affect or significantly reduce the gas fees of the main Ethereum protocol, not even The Merge. 

The Current State of Proto-danksharding

Ever since the proto-danksharding improvement proposal was created earlier in February, there have been expectations concerning whether or not any progress is being made.

While the Ethereum research team is still figuring out a couple of vital issues, proto-danksharding still has a long way to go in the bid to be the forerunner of full sharding. 

Foremost, data availability sampling is still theoretical and has not yet been implemented. Part of the reason for this is that the developers are still deciding whether or not the Ethereum Improvement Proposal should only implement point evaluation precompile and drop the idea of coupling it with blob verification precompile. 

Indeed, blob verification precompiling is self-achievable among Layer 2s. As a result, the Ethereum community is contemplating whether there is still a need to officially provide for it. 

The Ethereum team is looking into the most realistic architecture of blobs and the smartest security measures to put in place. 

The Future of Proto-danksharding

The Ethereum network has been battling the problems of relatively slow throughput and high gas fees for years, and Ethereum researchers have proposed various technical solutions, including sharding.

Proto-danksharding is a route to implementing the complete sharding roadmap, and its main aim is to reduce transaction costs for layer-2 protocols through a blob-centric transaction format. 

The Ethereum community has been keen on enhancing their modularity goal by providing Layer 2 blockchains with the needed architecture to build more scalably on the Ethereum protocol.