On the future of the blob mempool

[leobago]

Thank you for the write-up; it’s a nice exploration of the vertically sharded mempool idea.

I believe this is not the right path to follow. My arguments below:

@mikeneuder

The obviously ‘correct’ solution is to shard the blobpool vertically

This statement is very strong and you provide no data to back it up. Why is it obviously correct?

You mention that it mirrors the vertical sharding of the DA check, but that is only now for PeerDAS, which is not necessarily the same custody structure we want for the next stage of DAS. In the original 2D data sharding scheme and FullDAS, we expect to custody both rows and columns so the mirror does not exist anymore. It seems to me that you are not considering the future design.

@mikeneuder

Public blobs are vertically sharded and gossiped to the blobpool by the blob originator.

This does not make much sense to me. The blob originator cannot send the final column to be broadcasted on the CL network because this is only known at the time of the block creation, which happens after blobs are broadcasted to blobpool. Therefore the columns broadcasted to the blobpool cannot be the same columns that are necessary for sampling at the DA layer. In fact, rollups might not have enough blobs to fill an entire block, most likely you will need to include several type3 transactions from diverse rollups.

@mikeneuder

Without a vertically-sharded blobpool, the attesters would be stuck downloading the full public blobpool blobs.

This is not correct, the attester can download only a few horizontal blobs and a few horizontal columns, and still have the same DA guarantees as today.

@mikeneuder

Under this model, any column that is gossiped must come from an identity that has paid for the ability to write that data to the blobpool during that slot.

This is a complex new problem that extends the attack surface of Ethereum. There are too many things in the bidding system that you propose that could go wrong. Some of the questions were already raised by @terence (e.g., 2-slots look-ahead, reorg reimbursements, etc). The level of complexity introduced does not equate to the gains offered by this scheme, which are none IMHO, because, again, we will most likely custody both rows and columns in the future.

@mikeneuder

horizontal sharding must degrade the inclusion service of the blobpool, as the probability that a given proposer has any given blob during their slot decreases

Another strong statement made without data to support it. This is unlikely to be correct because, as you mention yourself in the following paragraph:

@mikeneuder

First, many nodes may choose not to horizontally shard and thus will continue downloading all blobs. With estimates of around 90+% of the stake being professionally managed, this could mean that the majority of proposers still have access to all blobs, and the blob inclusion guarantees remain essentially unchanged.

Exactly, and this is likely to happen, regardless of how you shard the blobpool, horizontally, vertically, diagonally…

@mikeneuder

In this idealized outcome, we could get the best of both worlds as at-home operators can limit the bandwidth impact of the blobpool, and the blobpool continues providing a good service to rollups and builders. Second, since proposing is such a rare task for an at-home operator, they could handle the brief spike in bandwidth by downloading all blobs only when they are selected as the proposer; in this way, their bandwidth spike would only take place a couple of times per year.

Exactly.

In summary, it seems to me that the only reason one would prefer vertically sharded blobpools, despite the apparent flaws in mitigating DDoS attacks, is that it somehow aligns with the way custody is currently handled: in columns. However, from the moment we understand that column custody might not be the future, then all this no longer holds.

If we consider the possibility that we might implement the originally proposed 2D erasure-coding design in the future, where sampling is performed at the cell level rather than in columns, are there any benefits to vertically sharding the mempool?