Update EIP-7840: Add BaseFeeUpdateFraction

[MarekM25]

ATTENTION: ERC-RELATED PULL REQUESTS NOW OCCUR IN ETHEREUM/ERCS

--

When opening a pull request to submit a new EIP, please use the suggested template: /~https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eth-bot]

File EIPS/eip-7840.md

Requires 1 more reviewers from @lightclient

[g11tech]

lgtm from ethjs

[siladu]

LGTM from Besu

[jochem-brouwer]

When there is no explicit configuration for the current fork, use the last specified fork value. If no last value is specified, set both to zero.

(From the current EIP). This "talks" about "both", maybe for clarification mention that then the fraction is undefined (cannot divide by 0).

I also think for completeness it would be great if in the Rationale there is an addition that this new param also allows to tweak the gas adjustments.

[somnathb1]

LGTM

[MarekM25]

@jochem-brouwer Thanks! Regarding defaults without configuration, I think the correct behavior for clients should be to throw an exception. In this way, we will notice quickly misconfigured tests/tooling etc. So, if 4844 is enabled and there's no blob configuration, let's throw an exception. I believe the EIP shouldn't force clients to handle defaults in a specific way, and we have soft consensus on either throwing an exception or using zeroes/undefined values.

Another option could be falling back to the Cancun blob parameters.

[g11tech]

@jochem-brouwer Thanks! Regarding defaults without configuration, I think the correct behavior for clients should be to throw an exception. In this way, we will notice quickly misconfigured tests/tooling etc. So, if 4844 is enabled and there's no blob configuration, let's throw an exception. I believe the EIP shouldn't force clients to handle defaults in a specific way, and we have soft consensus on either throwing an exception or using zeroes/undefined values.

Another option could be falling back to the Cancun blob parameters.

the way I see it is this:

that these are overrides, so if cancun isn't specified than cancun 4844 default eip , if overridden in a lower hardfork, that carries to a higher hardfork unless an eip there in changes these same params or the schedule is specified for that hardfork which overrides both the lower hardfork values and any hardfork eip params of that hardfork.

[jochem-brouwer]

(Everything striked through here is outdated, see my new comment)

So this raises some questions about what is defined regarding the configuration and what is not defined. In 4844, MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK are in the EIP, but the question is if these should also be interpreted as "default configuration" for 4844. That is: if the supplied config in this EIP (7840) does not contain a cancun field, should it fall back on 4844 or should it throw? The same goes for EIP-7691, it has MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK defined in the EIP, should we also consider this the default values in here (7840)?

The default configuration of the blob schedule should be:

"blobSchedule": {
  "cancun": {
    "target": 3,
    "max": 6,
    "baseFeeUpdateFraction": 3338477
  },
  "prague": {
    "target": 6,
    "max": 9,
    "baseFeeUpdateFraction": 5007716
  }
}

(i.e. this is as-defined currently in this EIP). A small note: we now define target/max representing the count of blobs, in order to calculate the gas and to apply the formulas in 4844, we have to thus multiply with GAS_PER_BLOB (from 4844) to get the relevant MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK parameters to use in the formulas defined in 4844.

Configuration behavior

The question now is, how should clients handle this EIP / the configuration? Note that 4844 (blobs) somewhat define the configuration parameters for Cancun and 7691 (blob schedule upgrade) define them for Prague. However since these are different EIPs than this one, and in order to be explicit, let's self-contain this EIP:

• The configuration above is the "default" configuration
• It is possible to override those values (so for instance a network on Prague with 12 max blobs)

The rules for overriding holds, so if there is an override JSON which only defines cancun for instance, then prague will use the params read from the default JSON above, but cancun will use the override.

If there is a fork (for instance: amsterdam) which is active but not defined in the default JSON (above) and the supplied JSON, then the configuration should throw.

This also means that for future forks we should update this EIP to reflect the correct "base" JSON.

[jochem-brouwer]

@jochem-brouwer Thanks! Regarding defaults without configuration, I think the correct behavior for clients should be to throw an exception. In this way, we will notice quickly misconfigured tests/tooling etc. So, if 4844 is enabled and there's no blob configuration, let's throw an exception. I believe the EIP shouldn't force clients to handle defaults in a specific way, and we have soft consensus on either throwing an exception or using zeroes/undefined values.

Another option could be falling back to the Cancun blob parameters.

Yes, I agree. Clients should explicitly provide a blob schedule. If Cancun / 4844 is active but there is no field in the config, then throw. If Prague / 7691 is active but there is no field in the config, then also throw. For me this would also hold for future forks to explicitly define the schedule in the config.

I would not fall back on Cancun blob parameters by if the config is not there, it might simply be forgotten but with an active new fork (Prague) it is not clear what schedule should be used (so throw).

[siladu]

This is an informational EIP and thus I don't think we should specify default/error behaviour here. If we do, then clients are not required to follow it so it doesn't achieve the goal of aligning behaviour. I think the preferred approach is to leave it up the clients.

If a particular client sees UX value in throwing then that's fine, but what is the value in cross-client alignment on this?

Current Besu behaviour is to not throw, but instead default to the appropriate fork's hardcoded values (as specified in EIP-4844 and EIP-7691).

Using the blobSchedule then becomes a way to override mainnet values with something non-standard, mainly for testing purposes.

[github-actions]

The commit e3a893d (as a parent of 355e7db) contains errors.
Please inspect the Run Summary for details.

[jochem-brouwer]

Two comments to clarify the text

[jochem-brouwer]

I would add here that the "explicit configuration" means: being explicit means that for every fork where we do change the configuration, we must configure it—including Cancun.

[jochem-brouwer]

Using "explicitly configure" and "explicit configuration" might lead to confusion, I think we are talking about slightly different things here. The point here is that the blobSchedule should be present in config (?) and it should be valid (at minimal the cancun entry should be there in the blobSchedule)

[jochem-brouwer]

LGTM 👍 😄