# Optimizing Blob Throughput

short abstract with main results in 2-3 paragraphs.

## Introduction

Why do we want mempool sharding and asynch Blobs? What proposals are there on these?

- Mempool sharding: has been said before many times.
- Free option problem introduced by ePBS
- Prepropagation should be used (remove things from the critical path as much as possible).

Blobs are among the data heaviest objects in today's Ethereum. As a consequence, communicating Blobs in sufficient quantity introduces challenges both for users but also to the protocol. This is evident by looking at bandwidth requirements introduced by increasing target/max Blobs from 6/9 to 48/52 in Fusaka by means of introducing peerDAS. In peerDAS the CL verifies data availability through sampling, reducing the per Blob bandwidth and thus allowing an 8-fold increase in Blob throughput. However, this is not mirrored on the EL where Blobs are still handled in their entirety, increasing the bandwidth requirements on running a blob mempool from 64/96 kB/s to 512/768 kB/s. In absence of some direct benefit, this introduces an incentive to users towards *not* running a blob mempool in the first place.

If nothing else this would be undesirable for the reason that it increases the pressure of propagating blobs in the critical path. This is due to the fact that today the mempool is the only way to have some degree of blob data being distributed prior to inclusion in a block. The importance of pre-propagation, beyond the obvious reasons of introducing unnecessary points of failure by solely relying on propagation in the critical path, has been highlighted by means of the "free option" problem in ePBS. Without going into the details here we just want to highlight that the free option problem can be significantly alleviated if the blob propagation window is kept minimal. It becomes clear then that the current protocol introduces a real tension between increasing the blob throughput and relying on propagation in the critical path. In the remainder of this note we will propose and discuss two ways in which this tension can be relaxed or removed altogether. Concretely we tackle this by mirroring on the EL the sampling introduced by peerDAS. Here we build on ideas discussed before at length and by a number of different people. Furthermore, we introduce the option of prepropagation into the protocol itself. Based on these principles we will discuss two concrete proposals. We will begin by discussing an "asynchronous Blobs" proposal which we see as a potential end goal. However, due to the significance of the aforementioned implications, we also discuss the idea of "unconditional payments". We see this as a short term solution acting as a stepping stone towards asynchronous blobs.
## Asynchronous Blobs

- High level idea of design.
- How does it address problems identified in the introduction?
- Prepropagation is now part of the protocol.
- Which are the main points in which it differs to todays design?
- We see this as the longer term solution. Can we, in the meantime do something that goes in this direction which is closer to todays design?
> **Figure 1.**

The main objective here is to make pre-propagation of blob data be facilitated by the protocol directly. By pre-propagating blobs which don't rely on being in sync with the chain, we can allocate propagation resources more efficiently.

We do this by introducing the option to split type 3 blob transactions into two parts, a type 4 and a type 5 tx. Crucially, we envision the coexistence of both regular type 3 txs and type 4/5 tx pairs. Blobs that can afford to be send in an asynchronous manner could be submitted by the two part method while blobs which have to be in sync with the chain would be submitted via regular type 3 txs. It is clear that this could also introduce two different fee markets for the two blob submission options. The role of the type 4 tx is to assign propagation resources to the corresponding Blob data sidecar. Thus a type 4 tx can be taken to be a transaction that commits to a "regular" Blob transaction while also paying the blob base fee and should be understood as a request for blob data propagation. Concretely we can take it to have fields: [`chain_id`, `nonce`, `max_priority_fee_per_gas`, `max_fee_per_gas`, `gas_limit`, `to`, `max_fee_per_blob_gas` ,`blob_versioned_hashes`, `y_parity`, `r`, `s`]. Consequently a type 5 tx can be taken to be a complementary, optional transaction conditioned on data availability with fields [`chain_id`, `nonce`, `max_priority_fee_per_gas`, `max_fee_per_gas`, `gas_limit`, `to`, `value`, `data`, `access_list`,`blob_versioned_hashes`, `y_parity`, `r`, `s`]. In particular this means that the PTC decides on availability of type 4 txs, included in block `N`, at some point during slot `N+1`. Thus, the type 5 tx is only valid if in addition to the usual validity checks the PTC's vote on availability of the corresponding type 4 tx was positive. Linking between the two transactions, in order to check validity can be done via the `blob_versioned_hashes`.

By introducing the two different options to submit Blob transactions we can reduce the amount of blob data requiring propagation within the critical path of a given slot. This means that we can shorten the propagation window for type 3 txs, thus alleviating the free choice problem introduced by ePBS.

## Unconditional Payments (or something like that)

- High level idea of design.
- How does it address problems identified in the introduction ? Which problems does it not address?
- Prepropagation made easier due to mempool sharding however, not part of the protocol itself.
- Which are the main point in which it differs to todays design?
- We see this as a short term solution that shares much of the structural features of Asynchronous Blobs which makes it forward compatible.

As mentioned earlier, today's mempool can act as a tool for pre-propagating data. An intermediate step towards asynchronous blobs, discussed in the previous section, is to introduce sampling to the mempool itself. This ensures that the bandwidth requirements for running a mempool remain relatively low and thus increases the likelihood that users will continue doing so. There is by now a plethora of different approaches towards introducing sampling to the mempool or "sharding" the mempool. Here we will discuss a variant that can be seen to lay the foundations towards asynchronous blobs, making it more forward compatible than some of the competing approaches.

The main challenge with regards to mempool sharding is to introduce adequate DOS resistance. If we consider "vertical sharding", that is sampling certain cells of each blob we have to introduce a mechanism that prevents a potential attacker from causing congestion by submitting unavailable blobs and resulting in limiting the systems throughput. In today's mempool, Blobs are only forwarded in the mempool if the type 3 tx is valid and data is available. This ensures DOS resistance since invalid blobs don't get spread in the p2p network. However, due to the lack of individual level guarantees on availability, once sampling is introduced it becomes impossible for a node to decide availability with high confidence. Thus, a different strategy is needed.

We propose unconditional fee payments as a mechanism for DOS resistance. The fundamental idea here is to make a certain fee payable independently of the actual inclusion of the associated blob in the block. With this "mempool fee" in place, distribution of blobs in the mempool can be made unconditional from availability since DOS attacks come at a financial cost.

====Concretely we propose the following:====

> **Figure 2.**