Authors: Mikel Cortes, Yiannis Psaras
Ethereum’s L2-oriented roadmap necessitates an aggressive blob count increase, which, in turn, inevitably increases bandwidth requirements for validator nodes.
With ProtoDankSharding already shipped and in production in Ethereum's mainnet since Deneb's upgrade, the upcoming Danksharding goes next with its PeerDAS and FullDAS proposals.
In this document, we present and further explore the idea of relying on a Kademlia-based DHT to support Danksharding. With the final intention being to remove some of the existing limitations that PeerDAS is currently experiencing in its devnets.
NOTE: we come from this first public first version draft → Probelab's Shared Blob Mempool Proposal - Draft Shared
In the current ProtoDankSharding setup (Dencun onwards), but also in the final DankSharding spec, blob sidecars included at each new block proposal are being propagated through Gossipsub to all CL nodes. Block propagation results in a blob mempool at the CL level that allows validators "faster" processing and validation of blocks.
There has been very little discussion around the fact that the same blobs are also being propagated and are present at the EL mempool, effectively duplicating the bandwidth and resource requirements of nodes. Although the EL doesn’t need to download all blob sidecars attached to a blob transaction, clients generally perform this pull operation, **at least to a certain degree.
The following schemas show the existing double seeding of blobs to the network, following the ProtoDankSharding EIP. In the first schema, we see the seeding of blobs at the Execution Layer, where EL clients receive the blob Tx and can pull or not the related sidecar.
In the second one (below), we see that these blob sidecars are sent back to the network together with the block proposal by the Proposer/Builder, but in the consensus layer this time, and using GossipSub topics.
Current proposals (e.g., FullDAS, PANDAS) focus on ways to make blob count increase feasible but do not take into account the above fact: that the same blobs are already present at the EL mempool of nodes, and that this generates two separate mempools with overlapping or redundant data in both.
We propose the consolidation and use of a public Kademlia DHT that would store ephemeral blob sidecars. Through content-addressing and content-routing properties (e.g., through the hash of the blob sidecar), the DHT would allow for the retrieval of individual blobs for the expected partial-block validation.