Update EIP-4844: Remove system contract concept

[lightclient]

This PR removes the "system contract" concept from EIP-4844. Although the approach has several pros, it tends to be a sticking point in the discussions around EIP-4844 due to the fact that we don't currently have the concept of a system contract with storage and that concept would need to be implemented into clients - whereas the header extension approach has already been performed to add baseFee to the header in EIP-1559.

Additionally, it resolves an issue in the original draft that conflated blobs and blob txs.

Will leave in draft until some consensus among authors is reached.

[eth-bot]

All tests passed; auto-merging...

(pass) eip-4844.md

classification
updateEIP

• passed!

[github-actions]

The commit 3c5e72b (as a parent of 85fc2d3) contains errors. Please inspect the Run Summary for details.

[protolambda]

I was expecting that we'd add a blob_basefee field, not a total blob_txs counter. Since the counter does not capture the fee-adjustment result of previous history, only the total number of blobs.

In EIP-1559 we weigh recent history higher than older history, but now it's basically averaging the usage all-time, which is not the same as the exponential adjustment we have in EIP-1559; adjustments will be smaller and smaller the longer the fork is active.

And the ExecutionPayloadHeader and ExecutionPayload type in the CL spec will need to match the EL definition of the block.

[protolambda]

After re-reading the EIP, and the Blob gasprice update rule text, I do think your implementation is correct, but I think the thing in question for me is this part of the EIP:

Hence, it has a similar effect to the existing EIP-1559, but is more "stable" in the sense that it responds in the same way to the same total usage regardless of how it's distributed.

EIP-1559 responds based on the distribution of blobs throughout history, whereas the current EIP draft handles excess blobs over all time, making excess blobs have long-term effects on the price.

With these effects, we get two unfortunate side-effects:

• Excess blobs (i.e. over target) that were included long ago, and already pruned, will cause the blob price to be higher even if all blocks within the non-pruned period perfectly match the target.
• Few bursts vs many small excesses: stable bandwidth usage and processing cost may be preferable, yet the total cost is lower if you distribute them in bursts.
  • Example:
    • For 8 blocks, if you have 1 excess each time: 2**(1/64)+2**(2/64)+2**(3/64)+2**(4/64)+2**(5/64)+2**(6/64)+2**(7/64)+2**(8/64) = ~ 8.40 total cost (note how the excess keeps growing)
    • For 8 blocks, if you have no excess, and then 8 all at once: 2**(8/64) = ~ 1.09 (or ~ 8.09 if the no-excess blocks charge 1 each, unlike the EIP code which makes those free...)
  • Maybe we embrace it, since batching is good for CPU performance? Would unstable bandwidth hurt the network more than less efficient batch processing?

Also, the EIP describes "blob_gas of block N+1 increases by a factor of 2**((X - TARGET_BLOB_TXS_PER_BLOCK) / GASPRICE_UPDATE_FRACTION_PER_BLOB)." but there's no increase, the code uses this directly as gas price per blob (and it can even be zero).

[vbuterin]

With these effects, we get two unfortunate side-effects:

I think that if we had gone with an EIP 1559 based on excess (so what this EIP does) from the start, no one would seriously consider adding a weird rule where you penalize excess more if it's spread out across blocks than if it's concentrated in a single block (which is what status quo EIP 1559 gives us in practice). The complexity is just not worth it, and the value of having a clean simple invariant of what total usage is targeted is really high.

More concretely, the value that the clean invariant of the excess-based rule gives us includes:

• We would not have to worry about bad proposers manipulating the basefee by strategically delaying transactions, because we know that strategically delaying transactions never affects the basefee
• A cleaner upper bound on how much storage clients need for blobs (target_per_block * (storage_duration / slot_duration + GASPRICE_UPDATE_FRACTION_PER_BLOB * 50), instead of needing 3% extra just in case you get a worst-case distribution
• A 51% attack on the basefee mechanism would actually require the attacker to have 50.01% of proposer slots, instead of ~46.9% with an EIP-1559-style rule

[protolambda]

In favor of less complexity, let's go ahead with this PR. Pruning/batching incentives are interesting to me, but don't have to block this PR, and may just make it worse.

The change from total_blob_txs to excess_blob_txs like Vitalik proposed would be nice though; it's less complex and we may not have to compute what the target total_blob_txs would be (which gets weird once you change the allowed throughput with a hardfork).

[0xGabi]

Is TARGET_BLOB_TXS_PER_BLOCK the same as TARGET_BLOBS_PER_BLOCK constant? If that's the case, can we define only one?

[0xGabi]

After reading the EIP and this Draft I notice the above.

[lightclient]

@0xGabi thanks for the review. I was previously considering renaming the constant but decided against it in this PR. Looks like I didn't revert the change fully! Looks like there was already an issue with the naming and I exasperated it. Should be okay now though.

[Inphi]

LGTM from an inplementer's POV.

[adietrichs]

Some more small recommended changes, then this should be good to merge.

[adietrichs]

lgtm

[axic]

Is this blobs here excess_blobs?

[axic]

cc @adietrichs @lightclient

[lightclient]

fixed in #5629, thanks for catching