Ethereum is moving towards a rollup centric roadmap, where blockchain related activities like DeFi, NFTs etc will be mainly done on L2 layer rollups like arbitrum, optimism etc.

Rollups essentially batch up txs and commit the state change done by these txs to the L1 layer. Each type of rollup has a different way in validating the tx batch, e.g. in optimistic rollups, a set of rolled up txs are considered final until some party proves that the list of txs are invalid.

Rollups have had to deal with fairly high gas costs due to the fact that the rollup data(which can be pretty large) was stored in the calldata of the ethereum tx which is expensive since it is stored in the EVM.

To reduce the gas costs of rollups, the ethereum core development teams have introduced blobs to ethereum. Blobs are essentially opaque bytes of data which are only relevant to rollups(or the users who are using blob txs).

Blobs are committed onchain by the KZG polynomial commitment scheme. Basically, each blob is interpolated into a polynomial whose commitment is computed using the KZG commitment scheme.

Computing the KZG commitment schemes will get expensive for homestakers going forward which will make it harder for home stakers to propose blocks with blob txs. ePBS solves this issue by allowing homestakers to delegate block building to external builders.

One of the other problems is that in full danksharding, n/w bandwidth will be a huge factor.

Below is quoted from the proposal written by Potuz (https://ethereum-magicians.org/t/uncouple-blobs-from-the-execution-payload/13059)

This forces proposers to rely on external builders to prepare these blocks, which in turn imposes a threat to censorship resistance: a few external players (the builders) will have ultimate decision of what transactions are included or not on L1.

While it is true that a non-censoring proposer may always propose execution blocks without any blobs, this becomes a strong centralizing force in that non-censoring validators have to forfeit their earnings from blobs (which in a rollup-centric roadmap are expected to be a large part of the block) if they want to control their execution contents.

We propose the decoupling of blob building from execution tx building for homestakers. Here, the intent is to ensure that smaller home stakers are not squeezed out of the builder market and that the builder market is not dominated by only specialized builders which can increase censorship in Ethereum.

# Some Context

In Eth2.0, the consensus layer randomly selects(through RANDAO) a particular validator to propose a block. To determine which transactions will go in the payload, the validator fetches an execution payload from the local execution engine using `engine_getPayloadV3`, the execution payload contains the following:

type ExecutionPayloadCapella struct {
	ParentHash    []byte
	FeeRecipient  []byte
	StateRoot     []byte
	ReceiptsRoot  []byte
	LogsBloom     []byte
	PrevRandao    []byte
	BlockNumber   uint64
	GasLimit      uint64
	GasUsed       uint64
	Timestamp     uint64
	ExtraData     []byte
	BaseFeePerGas []byte
	BlockHash     []byte
	Transactions  [][]byte
	Withdrawals   []*Withdrawal
}

After receiving the payload from the local execution engine. We also request a "Blinded" execution payload header from an MeV relayer we are connected to. A "Blinded" execution payload header is essentially the same as the execution payload received from the local execution engine, but the main difference being that the transaction list is hidden and is instead replaced by a merkle root of the transaction list. The merkle root is an equivalent substitute for the transaction list for validity. The validator client signs the blinded payload and sends it to the MeV relayer which means that it is essentially "commiting" to the payload and will definitely use it.

Post this, during the unblinding of the payload which essentially means the opening up of the payload and including the txs in the block. The block is then gossiped to the n/w for other validators to include it in their fork choice stores and attest to it.

*TODO*

# Questions

1. It looks like KZG commitment computation doesn't happen at all in the protocol. Just proof verfication happens when a tx is sent to the tx pool. Is this going to really even be a problem?

# Random Musings on the problem

These are some of the different ways in which we can think of the problem.
1. We are trying to acheive building 1 block by 2 different entities. This may cause determinism problems. How do we ensure that 2 different entities produce one deterministic block?
2. Right now, a proposer was a greedy capitalist. It only wanted the block with the most profit. But now its including its own txs because it wants to be a part of the block building process regardless of the fact that the builder may produce better blocks! the proposer is now becoming a capitalist with some morality!! :P
3. In a world with ePBS and expensive block building, we don't want specialized block builders to have the ability to censor transactions, that is the main intent. Assuming that there are no changes to the implementation of Eth2.0 and EVM, We are okay with a situation where eth has only 5 builders but the other proposers are able to provide their preferred txs to the builder to build along side with more expensive txs.
4. With the ethereum philosophy of decentralization applied in so many design decisions like that of validator creation, where a validator has a max cap of 32Eth in deposit(with scope to increase), we don't get whale validators i.e who has more voting power then the others(ofc one operator can run multiple validators). This may not be possible for builders because the power of a builder is directly proportional to the amount of hardware they can dedicate which is a centralizing power. Builders with really specialized hardware can squeeze out a lot smaller builders out of the market and start censoring txs. We want to also include smaller builders(who can be the proposers themselves to take part it tx selection for blocks).
5. Note that in the above point, I have said proposers would want to take part in `tx selection` and not `block building`. Because assuming the protocol specs hold good, having few builders cause the risk of tx censorship and not protocol level changes. Even if there are protocol level changes, the vast number of proposers can reject the block.

# Design Goals

We try to establish some scope of our design

1. We want to make minimum protocol changes and ensure that this system sits well with the existing protocol.
2. Given that, we should ideally not venture into the world of fork choice. We should make sure we are shielded from them by the block abstraction.
3. Make sure we avoid increasing the trust assumptions on the MeV relayer.
4. Make sure that tx order b/w execution and blob txs is always maintained.
5. Avoid decisions that increase centralization of block building and tx selection.
6. Don't increase user bandwidth consumption

# Potential Design Solutions

We discuss below some solutions on how homestakers can cope with the problem of expensive KZG commitment computations in full danksharding.

**Defer Blob validation and not Block building**

We know that the computation of KZG commitments will get expensive with full danksharding.

Currently the KZG commitment computation seems to be happening only when a blob tx is adding to a tx pool in the execution layer. There is no KZG commitment computation or proof verification during block building or block validation. This means that there may not be a guarantee that the blob tx will be available in the pending pool for the proposer to build it.

Given that this expensive operation is happening only during the addition of blob txs to the tx pool, we can think of the following ideas too:

1. Blacklist blob txs from homestakers RPCs: Homestakers will have the choice to disallow users sending blobs txs to their RPC nodes in order to disallow users from sending it and also homestakers will not request blob txs from peers.

This is BAD idea for the obvious reasons

2. Defer blob validation to more powerful entities: This will involve probably building an api based system, where we send an api to an external blob validator who will return true/false based on the blob validity.

This is a bit similar to the idea of an MeV Relayer where we send an api call to it to request a blinded block. This api call could be faster as the blob validator will have much more specialized infra to run these commitments. But there are also centralization issues.

**Proposer builds execution txs, builder builds blob txs and the block is assembled in the MeV relay**

In this solution, the proposer sends execution txs to the MeV relay alongside with the request to get a blinded header. The MeV relay will get the blob txs from the builder and assemble a block with the proposer execution txs and blob txs of the builder and sends back the blinded payload to the proposer who signs and commits to it. The proposer unblinds the payload later and builds the block with it.

There are some questions that come along with this:
1. How do we guarantee the correct state and receipt root for this block. We are having 2 builders building on the same state but applying execution and blob txs in different sequences. This can cause issues in the sequencing.
2. How do we validate that the MeV relayer has indeed used the proposer execution txs. We will have to trust it thereby increasing its trust assumptions. This also boils down to validating whether the builder has included the payout tx for the validator.
3. How do proposer payouts work now? Previously proposer payouts happened by the validator inserting a payout tx at the end of the execution list. Now that the proposer is proposing the execution list, we will have to re-work how the payout is sent. We could probably make the proposer intelligent enough to include enough space in the execution tx list to add the proposer tx.
4. In the current MeV relayer when a blinded header is sent to the proposer, the full execution payload is in fact already present with the MeV relayer. So when the blinded header is successfully committed to, we are able to get back the full payload quickly so that the proposer can propose before the 4s interval to get the proposer boost. If the relay has to re-assemble the blob txs from the builder and execution txs from the proposer, it might end up taking more time and cause the proposer to miss proposer boost.

**Proposer node sends(not builds) preferred execution txs to the MeV relay**

The problem of decoupling blob payload and execution payload can be looked at also as 2 individual execution client building the payload for 1 block. A transaction list should be deterministic in its sequence however its sequenced. All builders must agree to one sequence. If multiple builders build parts of an execution payload, they might have different view of the execution payload sequence which will make block building non deterministic for these builders.

The correct way IMO would be to fetch txs from multiple builders and then one validator will assemble the txs, commit all the txs in a particular sequence, store them in the block and send it to the consensus layer to build the block and broadcast it to the n/w.

This architecture makes me think of a map reduce architecture of sorts, where the mappers send the work to reducers.

now that we have established that tx sequencing should be deterministic, lets move a bit to the consensus layer.

In the consensus layer, we need a heuristic to determine if the validator is capable of building all the txs(including blob txs) by itself or does it need help from external builders to build a blob tx. We can have a validator in 4 possible modes:
1. Validator may not choose to build a block. A validator can just be a proposer
2. Validator may only build execution txs and defer blob txs to an external builder
3. Validator is powerful enough to build execution txs and blob txs.

The ideal heuristic for (2) and (3) should be the system specifications and also to allow the validator to specify what they want. (1) should be based on validators preference. This heuristics should only be determined based on good benchmarks.

(1) and (3) cases are already implemented in existing consensus and execution layers today. We will speak more about (2)

In the case of 2, the blob tx payload construction is being deferred to an external builder and the other execution txs are proposed from the proposer. Since blobs and execution txs dont compete for gas, we don't have to worry about reserving space in the payload for blob txs. We just need to reserve enough gas for the builder to add the payout tx for the proposer.

To fit the current architecture, the following can be done to support such as an architecture:
1. Builders start constructing the payloads when they receive the `onPayloadAttributes` SSE event from the consensus client. Similarly consensus layer can trigger an engine api call to fetch the execution txs(without commiting them) to be proposed from the execution layer and then send the execution tx list to the MeV relayer which will send the execution txs to the builder.
2. Builders similarly will start building the txs when the `onPayloadAttributes` SSE event is triggered. The builder fetches the validator data from the MeV relay where we can add a validator preference which indicates that the validator wants only blob txs to be built and will supply the remaining execution txs. The builder will wait for the execution txs for the proposer to be received. Once the builder receives it, it will commit the transactions to state, generate the tx sequence, state root, receiept root etc. It will add the payout tx to add the proposer reward and send the block payload back to the MeV Relayer.
3. The MeV relayer will verify the block payload sent by the builder. The MeV relayer will verify whether the txs sent by the proposer have been honoured in the payload.
4. Once this is done, the validator will request the blinded header from the MeV and commit to it. It will then unblind the payload header and propose it to the n/w.

Notes on this solution:
1. If onPayloadAttributes is triggered during the start of the proposal slot, we might have an issue where the fetching of execution txs, sending it to the relay and getting the block back might result in a late block delay which will mean that proposer boost won't be applied to the proposal. Need to check this once. Ideally onPayloadAttributes should be triggered in the previous epoch I think. If it is in the same epoch it ll end up racing with the block proposal routine.
2. We will have to break the subpool abstraction in Geth in order to fetch transactions of a specific type.
3. We will have to re-work the payouts for proposer. We will have to increase the propser payout by the value of the execution tx proposed. But the payout method will be the same.
4. We will have to trust the MeV relayer that the proposer's execution txs have indeed been included in the block. We cannot verify this from the blinded payload header.
5. This will involve some tight coupling b/w MeV relayers and builder. i.e we will have to have some sort of stateful session construct b/w a relayer and builder when building a block for this particular validator.
6. We have only 1 tx list but we will have a blob sidecar whose blob order will be in the order in which the blob txs have been commited to state.

# Stuff I need to research

1. Read code on what happens to tx pool in a mempool when an external builder includes it in a block
2. Read code on re-orgs. What happens to txs in a mempool during re-orgs.
3. Ask people where all KZG commitments really happens. Right now I believe its only when adding txs to the mempool. But I want to ask some execution client devs more on this, I might be looking at the wrong code.
4. What happens to the txs of a rejected block? Ideally they must still be in the mempool because we don't really know why they went wrong at a point.