[Document shared by the ProbeLab team on 2024-11-05 on a proposal to build a DHT-based blob mempool.]

Problem Statement

Ethereum’s L2-oriented roadmap necessitates an aggressive blob count increase, which, in turn, inevitably increases bandwidth requirements for validator nodes. In the current ProtoDankSharding setup (Dencun onwards), but also in the final DankSharding spec, blob sidecars linked 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.

However, 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.

Current proposals (e.g., FullDAS, PANDAS) do 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.

Proposals close to solving the mempool problem

As far as we are aware, there aren't consolidated proposals to address the current problem of having two separate mempools. Part of the Ethereum research community is leaning towards deprecating the EL’s TX mempool, relying on a CL mempool only. However, this has just been expressed as the personal views of individual researchers, without a dedicated discussion or roadmap item attached to it.

Request Blobs from the EL for block validation Understanding the problem we just presented, and approaching it from a practical point of view, there has been a proposal to add a new endpoint to the EL's engine API to allow CLs to request blobs directly from the EL as they see them included in a new block proposal.

Pros:
- This enables the CL to process the block much faster, as it doesn’t need to wait until that particular blob arrives from the given GossipSub topic.
- Furthermore, this proposal also contributes to faster blob propagation over the network, as they can publish the blob to its neighbours directly (act as a second publisher).
- Nice addition to the block processing flow, as it only can help to block validation and blob broadcast
Cons:
- If a given blob was submitted to a private mempool, the solution can’t provide any improvement in terms of block processing, as validators will need to wait until the blob is shared through the Gossip channels before it can validate it.
- The broadcast of the blob sidecars still happens regardless of being already in the public mempool
Relevant links for discussion:
- https://github.com/flashbots/mev-boost/issues/139

Distributed Block Building

Although rather new (still WIP), distributed block building would mean that resource-restricted nodes could propose a block, only referencing blobs that got validated through some proofs that will, later on, be provided by someone else in the network (aka collaborative building).

Relevant links for discussion:

Proposal: Bringing back a DHT-based structure

What do we propose?

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 retrieval of individual blobs for the expected partial-block validation.

A couple of clarifications:

CL nodes (both validator nodes and non-validator nodes) would participate as DHT servers if they pass a set of conditions, e.g., public IP and some minimum CPU/memory/BW resources to shift from DHT client to DHT server. It’s worth noting that apart from the seeding of blobs and the sampling process, these resource requirements would be minimal for ongoing maintenance.