# Blob scaling overview

In this document we will provide a brief overview of the actively pursued R&D initiatives that are, broadly speaking directed towards scaling the Blob throughput.

We begin by noting that today the blob throughput is dependent on both propagation of blob data (by means of sampling, through the CL) in the critical path as well as prepropagation of blob data in the mempool. We further note that in today's design this prepropagation through the mempool is vital but in fact not stipulated by the protocol. Furthermore, the prepropagation capacity is limited due to the fact that sampling is to this date has *not* been introduced to the blob mempool.

The ideas we will discuss can be understood as different mechanisms to increasing prepropagation capacity as well as regulating the way it is done in a more structured way than is today.

## Sparse mempool

The first initiative which has lead to the following [EIP](https://eips.ethereum.org/EIPS/eip-8070) and is summarized in the [document](https://www.notion.so/efdn/EIP-Sparse-Blobpool-24fd9895554180cc978bf577d55203ec) is that of "sparse mempool". This design can be understood as both a way of "vertically sharding" the blob mempool as well as an explicit design to introduce sampling to the EL. The protocol can be summarized as follows:

- Upon receiving an announcement about a new blob tx, a node flips a biased coin and with probability $p=0.15$ assumes the role of "provider" while with probability $1-p$ assumes the role of "sampler".
- Provider nodes fetch the *full blob data* from their peers while sampling nodes only fetch those blob cells they have custody for (i.e they *sample* the same blob data required for DAS in the CL).
- A node fetches and announces a new blob to its peers only if a critical number of its own peers have announced it and if local verification was successful.

On a high level it can be understood that the dual role design is meant to on the one hand reduce, in expectation, the volume of data downloaded by each node while at the same time ensuring that for each blob there is a sufficiently high number of nodes that fetch it completely. These provider nodes have a dual role to play, on the one hand they are meant to ensure that only available blobs get propagated in the mempool and on the other hand they are meant to ensure that each sampling node can indeed fetch all required nodes from its peers. It's not difficult to see then that provider nodes can be the Achilles heel of the design as has been shown in this [concrete attack](https://hackmd.io/@yZzECM-fQt2ePeYIwC4CUw/ByufNL90le). However, we can alleviate the severity of such attacks by introducing communication on availability between peers as suggested in [this note](https://hackmd.io/@gMH0wL_0Sr69C7I7inO8MQ/rk3TSjgJbe). This is currently being actively discussed.

## Decoupled payments

A complementary design that is built on the the ideas of [unconditional payments](https://hackmd.io/@gMH0wL_0Sr69C7I7inO8MQ/S1jjaLi_lx) and [blobpool tickets](https://ethresear.ch/t/variants-of-mempool-tickets/23338/3). This once again can be understood as a form of "vertical sharding" and can be understood as primarily a DoS-resistance mechanism. Concretely, the decoupled payments mechanism as well as unconditional payments/blobpool tickets are built on the premise of linking mempool propagation to a payment that happens regardless of availability of the blob. In mempool tickets this is done by forcing a blob sender to buy a ticket which gives them the ability to propagate a blob. In unconditional payments this is done by making the blob base fee be payed independently of the blobs availability. In the [decoupled payments design](https://www.notion.so/efdn/Blobpool-with-decoupled-payments-29ad98955541803f973af8bd7b104c65), a blob tx is coupled to an additional payment tx which itself can be executed (and thus a fee be charged) independently of the availability of the blob tx.

Note that this proposal does not make any reference to sampling and thus can be seen as a mechanism that can be included *on top* of any sampling scheme such as the sparse mempool proposal. The decoupled payments mechanism provides DoS resistance by means of potential economic penalty (by means of the payment tx) in case the blob is not available. Thus, it circumvents the problem we encounter in the sparse mempool proposal where nodes have to established some degree of confidence regarding availability before propagating a blob even if they only have partial knowledge due to the fact that they are sampling.

## Asynchronous Blobs

In the introduction we have mentioned the idea of making prepropagation an explicit part of the protocol. This is the main idea behind [asynchronous blobs](https://hackmd.io/eS6I5YkrQkunKpW3KKlAJw). This can be seen as a further development of the decoupled payments/unconditional payments/tickets ideas. Concretely, in addition to regular type 3 txs the idea is to introduce a type 4 tx, linked to some blob which assigns propagation resources for a given time window. Concretely, once a type 4 tx is included in a block, the corresponding blob has to be propagated for a given time window $\Delta t$ (say one slot). This allows prepropagation to be a more integral part of the protocol rather than relying entirely on mempool mechanisms for prepropagation. It is worth noting that with this proposal we end up having two types of blobs:

- Synchronous blobs: As today, associated with a type 3 tx (propagation happens within the slot, in the critical path).
- Asynchronous blobs: Based on submitting a type 4 tx (propagation happens in the slot before the actual blob tx, outside of the critical path).

As such this allows for a better allocation of resources and a more smooth bandwidth usage.