Danksharding

Basics

• A term used within the Ethereum community which describes one of the ways Ethereum will built towards Sharding.
• From Figment (17-10-2022):

"From a high level, Dankshsarding 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 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. 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.

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."

Technical details

• From Ethereum.org (27-10-2022):

"The main difference between all recent Ethereum sharding proposals since ~2020 (both Danksharding and pre-Danksharding) and most non-Ethereum sharding proposals is Ethereum’s rollup-centric roadmap: instead of providing more space for transactions, Ethereum sharding provides more space for blobs of data, which the Ethereum protocol itself does not attempt to interpret. Verifying a blob simply requires checking that the blob is available - that it can be downloaded from the network. The data space in these blobs is expected to be used by layer-2 rollup protocols that support high-throughput transactions.

The main innovation introduced by Danksharding is the merged fee market: instead of there being a fixed number of shards that each have distinct blocks and distinct block proposers, in Danksharding there is only one proposer that chooses all transactions and all data that go into that slot. To avoid this design forcing high system requirements on validators, we introduce proposer/builder separation (PBS).

Proto-danksharding (aka. EIP-4844) is a proposal to implement most of the logic and “scaffolding” (eg. transaction formats, verification rules) that make up a full Danksharding spec, but not yet actually implementing any sharding. In a proto-danksharding implementation, all validators and users still have to directly validate the availability of the full data.

The main feature introduced by proto-danksharding is new transaction type, which we call a blob-carrying transaction. A blob-carrying transaction is like a regular transaction, except it also carries an extra piece of data called a blob. Blobs are extremely large (~125 kB), and can be much cheaper than similar amounts of calldata. However, blob data is not accessible to EVM execution; the EVM can only view a commitment to the blob.

Because validators and clients still have to download full blob contents, data bandwidth in proto-danksharding is targeted to 1 MB per slot instead of the full 16 MB. However, there are nevertheless large scalability gains because this data is not competing with the gas usage of existing Ethereum transactions."