Add EIP: Block-in-Blobs (BiB)

[kevaundray]

No description provided.

[eth-bot]

File EIPS/eip-8142.md

Requires 1 more reviewers from @g11tech, @jochem-brouwer, @lightclient, @SamWilsn

[kevaundray]

From @soispoke

idk if it's discussed later but curious to know why the prefix option is preferable to a bitmap, another gossip subnet that only contain payload blobs, etc..

[kevaundray]

I was under the assumption that all payload blobs will be next to each other, so the prefix seemed like a simpler way to represent this information, if we then also assume that they will be first

[kevaundray]

From @soispoke

would be good to comment somewhere that this approach is somewhat wasteful (worst case scenario you have a whole blob wasted just because there was 1 byte of the payload left to include, and then you have to zero pad the rest)

[kevaundray]

From @soispoke

Should there be special-casing for empty payloads?

right now I guess there would be container overhead so it would actually consume a full blob for no reason

[kevaundray]

I'm not sure why an empty payload would consume a full blob here -- I imagine that payload_blob_count would be zero in that case

[kevaundray]

From @soispoke

shouldn't this be equal to max blobs per block?

[kevaundray]

This is a bit different to MAX_BLOBS_PER_BLOCK -- added a section in the rationale On MAX_PAYLOAD_BLOBS_PER_BLOCK that explains why its there, but I think we can remove it, if we think the concern is not valid.

[kevaundray]

Added in comments made by soispoke from the hackmd

[frisitano]

Nice write-up! Added some comments and questions inline. The biggest question I have in mind is the inclusion of withdrawals and requests in payload blobs. Intuitively, I think only transaction data should be included, but I'm keen to hear your reasoning and get some more clarity here.

[frisitano]

I don't follow this point. Could you elaborate on this please?

[kevaundray]

Here I was trying to say that validators could come to consensus on a payload, but if that payload is never revealed then other entities cannot make use of the updated state -- Builders wouldn't be able to build ontop of the block because they don't know what changed. RPC providers would similarly not be able to function because they need to apply the state updates to their databases (the BAL would be in the execution payload)

[kevaundray]

Let me know if this should be rephrased to be clearer!

[frisitano]

I think it's fine as is. Optional: Maybe specifically referencing "data withholding attack" would give strong comprehension because it is essentially what you are describing here and is well understood by those operating in the protocol layer.

[frisitano]

Why constrain this instead of letting market dynamics/block builders determine how to build blocks?

[kevaundray]

This was something that I was uncertain about and wanted some more eyes on, since the block builder is not directly paying for these blobs. I added a section in security considerations, let me know what you think about that scenario :)

[frisitano]

I don't have a strong technical basis here; I'm trying to understand a little better. I have a feeling it would be good if we could price things fairly and then let market dynamics take over.

[jihoonsong]

Isn't block builder pays for payload-blobs? In the Fee Accounting section below, it says: "The cost of including payload-blobs, in terms of blob gas usage, is implicitly paid by the builder, and reflected in block profitability."

I also think it feels not right to specify this constant as gas_limit affects on this value, which is determined dynamically by validators.

[kevaundray]

The builder pays in terms of opportunity cost in this specific block, but the argument is that if they can get more in priority fee later, then its rationale for them to artificially induce blob congestion

[jihoonsong]

So does it mean that payload blob costs a builder blob gas fee or is it about opportunity cost of including more blob transactions? That sentence is unclear to me.

[kevaundray]

I think its opportunity cost because if we imagine that there are a lot of type3 transactions that want to be included, the builder must leave space for payload blobs, so they can't include upto MAX_BLOBS_PER_BLOCK.

So payload blobs are taking up space that could have been used for type3 transactions

[jihoonsong]

Yeah I get that and we can elaborate "implicit pay" to convey that meaning. Builders might pay nothing when there is not enough blob transactions.

I also think it is not ideal that payload blobs and normal blobs share the same blob count limit because it means gas_limit scaling conflicts with blob scaling. Something that could be handled in other EIP.

[kevaundray]

I think this is a relationship that is introduced by this EIP because they are using up the same resource on the CL.

Something that could be handled in other EIP.

Ah I don't understand, could you elaborate?

[frisitano]

Is there a third alternative, namely, leaving this to market dynamics based on gas/blob gas pricing?

[kevaundray]

I think so, though I'd want to double click on what it means for a rational builder since they are not explicitly paying for the payload blob.

Will CC @Ma-Julian for this and the whole EIP for thoughts

[frisitano]

Is there anything wrong with that if it's economically favourable for a builder to do so? Couldn't market dynamics via priority fee allow for fair bidding / inclusion?

[kevaundray]

The payload blobs need to be included in the same beacon block for the block to be seen as valid, or else we have the DA problem. This means that payload blobs have a "guaranteed spot" no matter what the blob market looks like, so priority fee would mostly affect type 3 transactions.

Still mulling over this, let me know if I missed something here

[frisitano]

The payload blobs need to be included in the same beacon block for the block to be seen as valid, or else we have the DA problem. This means that payload blobs have a "guaranteed spot" no matter what the blob market looks like.

Yep, I agree with this. My point is that there is nothing inherently wrong with a block full of payload blobs. If a user has a strong desire to get a type 3 transaction included in the block, then they should increase their priority fee such that it's economically favourable for a builder to remove some of the other non-type 3 transactions to allow for space for the type 3 transaction to be included. Ultimately, things should be priced fairly so it just comes down to a fair auction.

[kevaundray]

My point is that there is nothing inherently wrong with a block full of payload blobs

Yeah I agree and this is a fair point

I think having the builder control the market for free seems undesirable though, in this case they would

• Add non-type-3 transactions for 10 minutes such that users need to keep increasing their priority fee (FOCIL wouldn't help here since blob capacity is reached)
• Once priority fees are at a desirable amount for the builder, they start accepting type-3 transactions

MAX_PAYLOAD_BLOBS_PER_BLOCK doesn't completely mitigate this though, it just limits how effective it is. One reason I don't like MAX_PAYLOAD_BLOBS_PER_BLOCK is that it does also mean that the builder has another constraint when they are block building; the set of transactions when serialized must not only fit within MAX_BLOBS_PER_BLOCK but this more constrained MAX_PAYLOAD_BLOBS_PER_BLOCK.

Will also CC @anderselowsson since he worked on 7918

[frisitano]

Please correct me if I'm wrong, but I don't think this EIP introduces any new censorship vectors. In the current protocol, fulu, if a builder doesn't want to include a type-3 transaction, no one is forcing inclusion?

[kevaundray]

yeah exactly, since we don't have FOCIL

[kevaundray]

Nice write-up! Added some comments and questions inline. The biggest question I have in mind is the inclusion of withdrawals and requests in payload blobs. Intuitively, I think only transaction data should be included, but I'm keen to hear your reasoning and get some more clarity here.

Yep I agree -- since the withdrawals can be derived on the CL and execution requests are the output of executing -- it was added only for completeness, so you don't need to reconstruct some of the payload from blobs and then the withdrawals from CL. Though I can see a point being that this could be encapsulated in a reconstruct_payload method in the CL.

I don't have a strong opinion here, let me know what you think

[kevaundray]

Added engine_getPayload to show how that would be modified to correspond to both newPayload variants

[kevaundray]

Thanks for the review @frisitano @jihoonsong @soispoke 🙏

There are three items that I think we can merge without resolving:

• Fee accounting (whether the current strategy is okay)
• MAX_PAYLOAD_BLOBS_PER_BLOCK constant (This is linked to fee accounting)
• Whether BALs should go in blob data too

[kevaundray]

Rethinking the decision to put both engine API versions(native and zk optimized) in the EIP, since they have different APIs -- we could make another EIP with the zkVM optimized version that relies on this that we will do with mandatory proofs, then we can separate pre and post mandatory proofs with the EIPs themselves

[frisitano]

Just a high-level comment in terms of communication. I think it would be cleaner if we use the following terminology when referring to the payload artefacts.

• execution payload body: the data structures from the execution payload that are used to re-execute blocks on an EL re-execution node. Currently, this is only transaction data, but in the future, possibly BALs as well.
• execution payload header: execution payload with fields from the execution payload body replaced by cryptographic commitments.
• execution payload: execution payload with full execution payload body included (not replaced by commitments).

[jsign]

Great write-up! Left some comments.

[jsign]

This ensures that execution payloads are always available even when validators no longer require them to verify the state transition function(STF).

Maybe be good to remove the "always available", since these are blobs which get deleted after some defined window?

[kevaundray]

Yeah the word available is a bit weird, it was meant in the sense of "data availability" -- if we had named it "data publishing", then this would have been easier to read. I will change it it to "always published"

[jsign]

Uhm, I was thinking about the same reg NewPayloadRequestHeader -- I guess this is somewhat covered by point 3) in L40 by "other commitments".

[jsign]

Is this required? As in, can we avoid this new field and put everything in the existing blobs field in BlobsBundle and semantically take the payload_blob_count value (new field in ExecutionPayload) to know the boundaries with type-3 txs?

[kevaundray]

I think it would be confusing because the proofs in BlobsBundle are CellProofs for DAS, whereas these proofs are the proofs needed to show equivalence between the kzg commitment and the payload.

Noting that payload blobs have their own cell proofs in BlobsBundle, like any other blob

[jsign]

Some lines above said:

This EIP does not mandate that payload-blobs pay a per-blob fee like transaction blobs.

and here says:

is implicitly paid by the builder

Just to check: by "like transaction blobs" you mean that is not paid by the same actor? i.e. not paid by users but the builder (but someones always pays)?

Edit: in a comment above you said " I was noting that the payload blobs were not being directly charged", so not sure if the builder is paying then? Or maybe "implicitly paid" means nobody is paying? :P

[kevaundray]

Ah here I was trying to say that there is no explicit type-3 like payment for payload blobs, its a cost that the builder implicitly pays by not having space for more type-3 blobs

[jsign]

But maybe there are no more type3 to include, so doesn't sound there is always a tradeoff to say that something is "implicitly paid" from my perspective.

In any case, I prefer to see it as a protocol accepted cost rather than frame it as a "builder effort". But might be my own preference!

[kevaundray]

Ah yeah I mentioned it in a different comment, re it being "opportunity cost" for the builder, but there might not be any type-3 transactions.

I'll use protocol accepted cost -- I think we still want to emphasise the case where the builder use payload blobs to inflate the priority fee, ie they just include large payload transactions, taking up the space for blobs with payload blobs, so rollups etc will increase their priority fee to get their blob in.

[jsign]

They would have to pay for CALLDATA costs or similar to do that kind of "attack" no?
But I agree is a new angle of the attack tha should be accounted for about its implications.

[jsign]

Sidenote: might be useful to ask RIG team to estimate the impact of this maybe using history?

[jsign]

Feel this sentence a bit confusing, mostly the last , if ... part -- but maybe that's only me. No strong opinion.

[kevaundray]

It's most meant to convey the fact that we don't need BiB, if we do the naive DA solution which is to have zk attesters download the full execution payload. If we were to do that though, the bandwidth for those nodes would grow linearly with the gas limit since the payload size grows linearly with the gas limit

[jsign]

Yep, I got the idea. My point was mostly that the sentence might be confusing on how it is redacted. Just a nit.