# PeerDAS local block building

In PeerDAS, there are essentially three ways to fulfill proposal duties:
- Outsourcing (PBS), for example through mev-boost. The propagation of block and blobs is done by a relay and/or builder
- Local block building, with two subcategories based on the capabilities of the node:
- Higher resources: node is able to quickly compute the encoding for up to the maximum number of blobs and propagate them
- Lower resources: node is only able to do the above for less than the maximum number of blobs

No changes are required in order to help nodes falling in the first two categories to successfully propose. On the other hand, nodes with lower resources might be able to successfully propose up to 6 blobs most of the time, but might for example not be able to do so with 12 blobs. This poses two questions:
1. Are there protocol changes that can help such nodes to propose more blobs than they could by themselves?
1. How economically disadvantaged are validators that cannot afford to propose the maximum number of blobs? In particular, how does this compare to the existing disadvantage of local block building vs mev-boost?

### Network-aided blob propagation

Firstly, keep in mind that it is normally much easier for a node to download up to the maximum number of blobs than it is for them to propagate them in a timely manner, for two reasons:
- If the node is proposing at slot $n$, it can listen for new blobs in the EL mempool for most of slot $n-1$. On the other hand, blobs have to be propagated much faster when proposing, in at most 4s.
- Most home connections have asymmetric download and upload speed.

With this in mind, we know that the blob propagation part of the proposal pipeline is the one that we need to tackle first. Here's one way to go about this:
1. The proposer could set a flag which makes their default proposal behavior to first gossip the block to all their peers, and only afterwards to start propagating column sidecars. It could also begin by propagating only the first half of the column sidecars (meaning, only columns $[1,2, ..., n/2]$ out of $n$) before beginning to propagate the second half, to take advantage of the erasure coding.
2. Upon receiving a block, a node which subscribes to all subnets checks whether it already has all the blobs in its EL mempool. Note that all blobs chosen by a local block builder would have been seen in the mempool. If it does it computes the encoding and propagates the resulting column sidecars as if it had received them via gossip. [Computing the encoding](https://notes.ethereum.org/WcT6jxTcSkGbNJpZomut4A#compute_cells_and_proofs) takes ~200ms of core time per blob. For example, a node with 32 cores would only take ~100ms to compute the encoding for 16 blobs.
3. Upon receiving a block and fifty percent of the column sidecars, and possibly after waiting for a random delay, a node reconstructs all column sidecars and propagates them as if it had received them all through gossip. Note that this is just the default reconstruction and re-seeding behavior [as currently specified](https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7594/das-core.md#reconstruction-and-cross-seeding).

This strategy succeeds as long as the block quickly reaches at least one node subscribed to all subnets and which has also seen the blobs. This node effectively acts as the initial source of column propagation, and so do any other such nodes which see the block subsequently.

### Local blobs per block maximum

Even after implementing the strategy above, some nodes might still wish to limit the maximum amount of blobs that they attach to a block they propose, for example because they don't want to rely on this network-aided propagation strategy too much, or at all. One question is then, how costly is it to consistently propose a lower number of blob txs?

While a deep analysis is out of scope here, we can at least quickly get a sense of the order of magnitude. [The following plot](https://dune.com/queries/3967893/6676892/) shows the average priority fees from blob txs per block (in USD) since the launch of EIP-4844. For all months except June, they were consistently at or below $2 per block. Even at the highest point, they were below $10 per block. On average, a validator will have ~2.5 block production opportunities per year (and steadily decreasing as more stake comes in), so we're more or less talking about $5 to $20 per validator per year. With a higher blob count, there will on the one hand be more blob txs to collect priority fees from, but on the other hand congestion will be more rare (at least for some time), and there might often not be hardly any priority fees to collect at all. Either way, considering a hypothetical validator which sets a maximum blob count of 6 while the actual maximum is maybe 16, it seems quite unlikely that this choice would put them at a considerable economic disadvantage.


The effect is even less pronounced once we compare it to the existing revenue delta between local block building and mev-boost. [This analysis](https://ethresear.ch/t/is-it-worth-using-mev-boost/19753) finds that the expected yearly rewards of a mev-boost user are nearly 0.1 ETH higher than those of a local block builder, which is over an order of magnitude more impactful than the priority fees from blob txs.