Update EIP-4844: Fee Market Update

[adietrichs]

Update to the EIP-4844 fee market design. List of changes:

• introduce data gas
• add max_fee_per_data_gas tx field
• change fake exponential function to taylor expansion
• add min data gasprice of 10,000 Gwei reverted, tbd in separate PR
• remove max blobs per tx restriction
• align tx field naming with EIP-1559
• change DATA_GAS_PER_BLOB to make it easier to add calldata pricing later
• specify that data gas fees are burned

Potential remaining todos:

• make excess blobs calculation slot-based instead of block-based will be a separate PR or EIP
• mention option for mempool to enforce a max blobs per tx restriction solved by EIP-5793
• change data gas name to something more unique (oil? mana?) data gas it is
• move data gas from static to dynamic tracking too opinionated for now
• update EIP structure and rationale to better explain data gas potentially in a later PR

[eth-bot]

A critical exception has occurred:
Message: pr 5707 is already merged; quitting
(cc @alita-moore, @mryalamanchi)

[adietrichs]

I would ideally want to add slot-based excess blob accounting to this PR, but that would mean that calc_excess_blobs would have to include some argument like slots_since_parent, which would introduce the notion of slots to the EL. Alternatively I could use time_since_parent or target_timestamp and calculate the number of slots internally, but then the EL would have to know to use fixed slot-based timestamp for those.

[dankrad]

Is there a rationale for switching to the Taylor expansion?

[adietrichs]

This came out of a discussion with @vbuterin. If I recall correctly, reasons were:

• simpler conceptually
• more precise approximation
• only slightly more computationally expensive (and only done once per block, so insignificant)

[MicahZoltu]

I think this is "conceptually simpler" for a very small set of people (math lovers). I think for the vast majority of the rest of the world (which likely includes most of the people building Ethereum and building stuff on Ethereum) the original was "conceptually simpler".

I don't think the precision here is necessary, given that we are just guessing at capacity targets anyway.

[adietrichs]

Conceptually simpler not from a "reading the code", but an "understanding where the code came from" perspective. Which I would argue is the main objective.

[djrtwo]

nice!

[djrtwo]

oh, and I think "data gas" is sufficient and self explanatory as a name. Coming up with something clever will lead to endless bikeshedding

[roberto-bayardo]

FYI I'm starting to implement this to be part of our next EIP-4844 devnet, hopefully going out by end of week. I'll work around the open discussions best I can, though if some can be closed out in the short term please do so!

[adietrichs]

@roberto-bayardo I made some more data gas related changes:

• updated DATA_GASPRICE_UPDATE_FRACTION
• updated DATA_GAS_PER_BLOB and MIN_DATA_GASPRICE
• changed excess_blobs header field to excess_data_gas and adjusted update rules
• changed TARGET_BLOBS_PER_BLOCK to TARGET_DATA_GAS_PER_BLOCK
• changed MAX_BLOBS_PER_BLOCK to MAX_DATA_GAS_PER_BLOCK

With the exception of the header field, these should be relatively minor changes. Let me know whether you think it is realistic to include these into the next devnet release.

The only remaining planned update to this PR is optional from an implementation pov, it will move blob gas from static tracking (calculate blob gas usage before tx execution) to dynamic (track blob gas during tx execution). Those behaviors are fully equivalent for 4844 though, so any static tracking implementation should remain spec-compliant.

[roberto-bayardo]

We'll work on getting those in @adietrichs I think we can manage.

[roberto-bayardo]

@adietrichs don't see it in the spec, but I assume fees due to data gas are burned rather than go to validator?

[adietrichs]

@adietrichs don't see it in the spec, but I assume fees due to data gas are burned rather than go to validator?

Ah, yes they are supposed to be burned. That's a good point though, that should of course be explicitly specified.

[jessepollak]

Amazing work @adietrichs - thank you!

[SamWilsn]

I really dislike introducing a new resource separate from gas and calling it "data gas". The term "data gas" implies a subtype of gas—this isn't.

As a radical suggestion, I'd suggest calling this resource teu.

I won't let this hold up the PR though.

[SamWilsn]

As established in an earlier EIP-4844 PR, we're going to allow the links to the consensus-specs.