# Problem description

In the following we will discuss a possible strategy for achieving sharding of the mempool that is making use of the Blob base-fee mechanism as a mean to disincentivize DoS attacks. As has been discussed before, such an attack could be performed in the case where Blob-data are being posted to the mempool *without* them being fee paying, for example by virtue of the Blob not being available.

More concretely, mempool sharding here is understood as a mechanism that allows us to brake up Blob data into small chunks (cells) which are then propagated through the mempool. This is in contrast to the current situation in which Blob data is propagated in its entirety.

While proposals for "horizontal sharding" already address to a certain extend the problem of data throughput maximization, there is a clear motivation to exploring "vertical sharding". Horizontal sharding can be understood as a mean to shard the mempool as such while vertical sharding can be understood as sharding Blobs (and as such also the mempool) Given that currently, on the consensus layer Blobs are sharded in this vertical manner, we will argue that it makes sense to replicate this also on the execution layer.

# Mechanism overview

The mechanism we will consider is based on a very simple idea. Instead of having Blob base-fees being charged only once a Blob is included in a Block, we make the payment *unconditional*. That is, once a Blob has been submitted to the mempool base-fees are charged independently of whether it is actually included in the Block or not.

The logic here is that if base-fees are charged in this unconditional manner, DoS attacks relying on spamming the mempool with Blobs which lead to no fees being payed, comes at a cost (understood as penalty) while in the case where all parties behave honestly, no additional costs are being placed on the Blob sender.

A minute of thought should reveal that introducing such unconditional payments can introduce a potential attack with direct financial impact on the Blob sender. In particular, if we naively make Blob base-fees unconditional, a dishonest Block proposer could charge a Blob's fees while not including it. What today would be a censorship attack on the Blob-sender thus is worsened by the additional financial loss.

In the next sections we will discuss different mechanisms to combat this problem.
# Simple fix: Deposit plus Final payment

As the attack just discussed fundamentally stems from the potentially misaligned incentives of the Block proposer and the Blob sender, a simple approach to solving it would be to realign them.

In particular we could split the Blob base-fees into:

- Unconditional deposit.

- Conditional final payment from which the Block proposer receives a fraction as reward.

The exact details i.e. the deposit percentage and proposer reward percentage would have to be considered in more detail (for example they could be static, dynamic, the Blob-sender could choose the proposer reward percentage etc.). Nevertheless, it is quite likely that with appropriately chosen parameters a good middle-ground can be found where both attacks (spamming mempool with unavailable Blobs and censorship attack with financial cost on the Blob sender) come at a sufficiently high financial cost to the attacker to be unattractive.

# Committees: Fix with added benefits.

As we saw, the potential attack by the Block-proposer basically reduces to a censorship attack with an added financial cost. Thus, it makes sense to use the mechanisms developed already in order to combat this. In particular, we can introduce two committees which should be familiar from FOCIL and ePBS:

- An inclusion committee (IC) for slot $N$ which compiles a list of Blobs to be *considered* by the next Block proposer.
- An availability committee (AC) for slot $N$ which checks availability of Blobs listed by the IC.

**Note:** By *considering* a Blob we mean the process of charging the (deposit) base-fees. Considering a Blob does not necessarily mean including it in a Block but merely means not ignoring it altogether.

Once again, details about the sizes of these committees and their inner workings (or indeed whether to use the corresponding committees from FOCIL/ePBS) shall be discussed later.

For now we will treat the IC as a process that outputs a list $L_{global}^N$ and the AC as process that outputs a bitstring $x^N \in \{0,1\}^{|L_{global}^N|}$ where the value of $x_i^N$ indicates whether the $i^{th}$ element of $L_{global}^N$ is available or not.

**Note:** We clearly do not want $L_{global}^N$ to actually be a list of Blobs. Rather it should be a list with low-weight pointers to Blobs that are to be sampled.

The interplay between IC, AC and Blob proposer for slot $N$ is as expected. The Blob proposer receives the pair $(L_{global}^N,x^N)$ and by default considers at least a $1-\epsilon$ fraction of Blobs $B_i\in L_{global}^N$ including them if $x_i^N=1$. Further, attesters for slot $N$ will perform DAS for all Blobs $B_i\in L_{global}^N$ and vote for the Block iff it considers at least a $1-\epsilon$ fraction of Blobs in $L_{global}^N$ and if their local view on availability aligns.

What this achieves is:

- Force Block proposer to consider a certain (sub-)set of Blobs. This provides censorship resistance.
- Signal (un-)availability to the proposer. This provides guarantees with respect to (un-)availability to the proposer so that she does not have to download all $B_i \in L_{global}^N$.
- Force honest behavior of Block proposer by conditioning Block acceptance on alignment of attesters and proposers view on availability. This combats the problem of censorship attack with added financial cost discussed above.

Additionally we want to highlight that the list $L_{global}^N$ acts as a way to define an "effective mempool" for slot $N$. This is relevant in the scenario where more Blobs are being submitted to the mempool than what is supported due to bandwidth limitations. This allows to move the majority of data-propagation necessary for DAS to happen outside the critical path. In fact, it could even be completely decoupled and asynchronous vis-a-vis the consensus layer. Concretely, the IC and AC for slot $N$ could perform their actions during slot $N-1$ but in fact they could even be made to do so during slot $N-k$. Having the data-propagation happening outside the critical path is clearly advantageous for multiple reasons. On the one hand it allows higher throughput without running into issues such as the "free option problem". On the other hand if the majority of Blob-data gets propagated outside the critical path, it leaves the possibility of some limited amount of Blobs for which synchronicity is might be crucial to still be propagated in the critical path as is today, thus effectively opening the potential for different types of Blobs.====This last part is highly speculative so I will leave it at that====

# Technical implementation

Here we will go a little deeper into how the above proposed mechanism could be implemented. In particular we have to clarify the implementation of:

- The unconditional payment mechanism.
- The internal workings of the IC and AC.

This could be achieved by splitting the Blob-propagation into two parts. When a Blob is submitted, the sender starts by sending the Blob transaction header $\mathrm{tx_{h_i}}$ (including gas information, nonce, from, blob versioned hash etc.). This gets gossiped through the network modulo verification (i.e max fee > blob base fee).

At some predetermined time $t_0$ the IC outputs and gossips $L_{global}^N$ where $L_{global}^N$ could be a list of hashes of the transaction headers, $H(\mathrm{tx_{h_i}})$. If the senders Blob is included in $L_{global}^N$ DAS begins and the Blob sender has to make Blob data available (we don't specify how this would be done as it is completely flexible and could be made to work for any DAS design we have in mind).

After some appropriately chosen time $\Delta t$ the AC outputs and gossips their result string $x_N$.

In slot $N$, for all Blobs in $L_{global}^N$ the block proposer includes:

- Full Blob transactions if AC deemed available.
- Only the blob base fee transaction if AC deemed unavailable.

====It is worth considering the possibility to allow a Blob who's blob-base-fee has been payed in slot $N$ but has not been included due to data unavailability to be made available and be included without double feeing in slot $N+1$====