Add EIP: Add blob schedule to EL config files

[lightclient]

Adds a new object to the EL genesis chain config:

of the shape:

"blobSchedule": {
  "prague": { "target": 6, "max": 9 },
  "osaka":   { "target": 12, "max": 16},
  ...
}

[eth-bot]

✅ All reviewers have approved.

[github-actions[bot]]

The commit 16a64273c68257679b7c3588226b0f2fef570b71 (as a parent of 6586687e6e3f7c8422e57a3cd883b15f8791de7e) contains errors. Please inspect the Run Summary for details.

[siladu]

Besu is ok with this change to get us through Prague and have a prototype implementation ready https://github.com/hyperledger/besu/pull/8042

[marioevz]

I prototyped the test changes required in this PR: https://github.com/ethereum/execution-spec-tests/pull/1040

Feedback is appreciated.

[klkvr]

Should we configure update fraction in this object as well? Given that EIP-7691 defines different update fractions for Cancun and Prague it seems reasonable to handle it in the same way as target/max blob count?

[g11tech]

i think in interop call was discussed that upgrade fraction should also be provided with the config butt it only matters w.r.t. to handle the max swing on the asymmetry schedule (drop is bigger on empty blobs compared to full blobs block)

7691 already modifies that for 6/9 so not sure if we need to provide it here. although there could be later EIPs to deal with assymetry (like normalization) so we don't really need it.

[parithosh]

i think in interop call was discussed that upgrade fraction should also be provided with the config butt it only matters w.r.t. to handle the max swing on the asymmetry schedule (drop is bigger on empty blobs compared to full blobs block)

7691 already modifies that for 6/9 so not sure if we need to provide it here. although there could be later EIPs to deal with assymetry (like normalization) so we don't really need it.

However, without the update fraction being specified in the genesis files - we can't properly test future blob increases on testnets (atleast not with proper gas markets). E.g if we set 10/20 as the blob target/max on pectra (in order to do some load testing), we will have a situation where the wrong update fraction is applied for this blob limit. Allowing us to specify everything in the genesis file will fix this.

[g11tech]

However, without the update fraction being specified in the genesis files - we can't properly test future blob increases on testnets (atleast not with proper gas markets). E.g if we set 10/20 as the blob target/max on pectra (in order to do some load testing), we will have a situation where the wrong update fraction is applied for this blob limit. Allowing us to specify everything in the genesis file will fix this.

this EIP itself is baffling,

1. so do we expect node runners to be able to play with these values for their clients like how they signal change to the gaslimit? if this is the case one should only be able to change their "soft max" locally which only impose limit on amx blobs their client can include

2. or this is just a testing tool? in that case why is this an EIP on core track, it will never be activated in mainnet? may be this could be an informational EIP for client testnet tooling that goes into "living status" and not "final" status

[parithosh]

However, without the update fraction being specified in the genesis files - we can't properly test future blob increases on testnets (atleast not with proper gas markets). E.g if we set 10/20 as the blob target/max on pectra (in order to do some load testing), we will have a situation where the wrong update fraction is applied for this blob limit. Allowing us to specify everything in the genesis file will fix this.

this EIP itself is baffling,

1. so do we expect node runners to be able to play with these values for their clients like how they signal change to the gaslimit? if this is the case one should only be able to change their "soft max" locally which only impose limit on amx blobs their client can include

2. or this is just a testing tool? in that case why is this an EIP on core track, it will never be activated in mainnet? may be this could be an informational EIP for client testnet tooling that goes into "living status" and not "final" status

For 1. I don't imagine node runners using any signaling as the canonical files for mainnet are coded into the client implementations. This is mostly just for testnets and testing purposes that we care about specifying the values instead of just hardcoding it. 2. I would agree that its an informational, but its @lightclient 's EIP so i'd let him justify that bit

[timbeiko]

@g11tech can we please merge this now that the track has been changed, as we've already accepted to include it in the fork. Thanks!

[jochem-brouwer]

@timbeiko Side-topic, it would be new (?) for informational EIPs to become part of a hardfork spec? (Because this is not part of consensus and thus does not require a fork)

[timbeiko]

@jochem-brouwer we agreed to put non-Core EIPs in hardfork spec for clarity (e.g. PeerDAS isn't a Core EIP), but I haven't formalized that anywhere. Need to open a PR to EIP-7723 to mention it 😄