EIP-4844: Remove system contract concept

[lightclient]

trafficstars

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[bot]]

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

[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).

[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.

[ndengeyingoma]

hey i need blockchain project for using in my defense and graduation who are able to give to me???