Decoupling gas price from payload size

[arnetheduck]

As discussed, depending on the gas limit in effect the execution layer may create payloads larger than what the consensus network can carry, based on max payload size limits.

This creates an unfortunate situation where block builders create payloads that are valid according to execution and consensus fork choice rules, but not valid according to consensus network rules, paving the way for network-based splits.

Several solutions have been discussed and we should eventually settle on one - this issue catalogues the top contenders:

(a) Increase the payload size

#4041

+ increases the "safe gas limit"
+ simple, in terms of specification
- increases attack surface for network-based DoS/amplication
- coupling remains, just further away
- coordination problems, when done outside of a hard fork

(b) Limit encoded total transaction size

From the max payload size, we can derive a "max transactions size" easily.

+ aligns execution layer with carrying capacity of consensus network
+ removes coupling
+ EL already knows transaction encoding and can trivially compute size
+ flexibility in small vs large transactions
+ bound can be "close" to CL limit - no extra safety margin needed
- requires a coordination mechanism to express the limit (spec-based constant, CL informs EL via RPC, etc)
- requires execution layer mempools to be aware of byte limit, in addition to gas limit
- effectively acts as a second pricing dimension on transactions

(c) Limit single transaction size

Currently, execution clients have no common "single transaction limit" meaning that some will accept transactions that others will not - the effect is exacerbated by private mempools whose rules are unknown.

+ same as above
- still requires a max total transaction size
- inefficiently limits single transaction size (one large transaction is "cheaper" to process than N smaller ones with the same data)

(d) Derive gossip limit from gas limit

+ removes coupling
+ community remains empowered to pick any gas limit
+ single limit to rule them all, enforced by consensus/execution validity rules
+ gas pricing can be used to adjust effective limit
- formula is complex to derive - depends on gas schedule, "best known method to create large transactions", gas limit update range over non-final chain portion
- dynamic "max size" is tricky to enforce during non-finality using present-day libp2p implementations
- community may choose a gas limit that the network is unable to carry (amplification, latency) or that breaks implementations (resource usage)
- increases DoS protection implementation complexity due to the variable-sized and unbounded nature of the limit

(e) Max gas limit

See post below

[nisdas]

Another approach which would be similar to b) and is the inverse of d). Instead of deriving the gossip limit from the gas limit, we derive the maximum possible gas limit from the specified consensus gossip limit. This can be done easily enough by the modelling the worst case block size which comes under the current consensus gossip limit and then deriving what would be the gas limit required to build such a block.

This value would be hardcoded in execution clients, so both in block building and validation you would always ensure that the built and received block never exceeds the specified gas limit. If validators vote for a gas limit higher than this max value, you would simply just build a block up to the hardcoded maximum gas limit. If you get a block from gossip that has a higher gas limit than the maxiumum then that block is invalid.

Benefits of doing it this way:

• Simpler implementation complexity for execution clients , as they have to simply adhere to this limit and will not have to do any non-trivial changes to their mempool in validating transactions or packing them into blocks.
• Clearer and easier co-ordination on what is required to increase the gas limit in execution substantially (hardforks).
• Most importantly it acknowledges that the consensus network has limits on how much data it can reasonably propagate within the slot boundary in a timely manner. This value isn't left unbounded and cannot be dynamically adjusted to any value.
• If there are improvements to how blocks are gossiped ( new pubsub protocol, new gossipsub extension, , etc), this value can be increased in a hardfork.

Cons:

• The gas limit is no longer left up to validators to vote on without restrictions. This might not be favorably received in the community.

A counterpoint to the con above is that validators/miners have been very careful not to raise gas limits indiscriminately in ethereum's history and would only increase it if it was assumed to be safe. So this proposal would be codifying a social norm.

[nflaig]

Has anyone tested what happens if you propose a block on mainnet even close to 10MB from a home server? My guess is that it would likely get orphaned and I don't see how my node would be able to gossip that block in time (even without blobs), the problem already starts with transmitting the block over the engine-api via JSON.

Increasing the gossip limit as suggested in #4041 seems unreasonable to me as even the 10MB limit we have now is two orders of magnitude larger than a "normal" block on mainnet which ranges between 80 to 150KB (uncompressed). Even if we increase the gas limit by 10x, the gossip limit is still enough, also considering we wanna make calldata more expensive in Pectra.

In my opinion this is more of a question of how big the execution payload (mostly the transaction list size) can be before it produces a block that is unfeasible to propose in a timely manner. This issue is already present with a gas limit of only 30M.

Option (b) seems like the best solution and can be implemented without a hard fork and even allows ELs to decide themselves what they wanna use as a reasonable limit which realistically should be much lower than the CL gossip limit to not miss the proposal.

[benaadams]

Block building is already an NP hard knapsack problem; adding an additional dimension (byte length) in addition to gas makes it considerably harder.

If it needs to be constrained by byte length that should be incorporated into the gas schedule to not make it vastly harder.