feat: EIP-7840

[klkvr]

Motivation

Implements EIP-7840 ethereum/EIPs#9129

Solution

alloy_eips::eip7840 has 2 structs: BlobScheduleItem which is the one present in genesis config as per EIP, and BlobParams which is a new aggregated configuration for blob constants, including an update fraction which is going to change in Prague as well with EIP-7691. All methods of header which need to perform blobfee-related calculations are now accepting BlobParams similarly to methods performing eip1559 calculations.

ChainConfig is extended with blob_schedule which is a mapping from String to BlobScheduleItem. It is not great because this means that we'd need to perform parsing of strings into the actual hardforks names on demand and won't have type-safety during parsing.

One way to improve this could be to make Genesis and ChainConfig generic over hardforks enum but this might be quite invasive, wdyt @mattsse

PR Checklist

• Added Tests
• Added Documentation
• Breaking changes

[mattsse]

nits

[mattsse]

It is not great because this means that we'd need to perform parsing of strings into the actual hardforks names on demand and won't have type-safety during parsing.

imo this is fine because genesis -> chainspec is an additional step anyway

[klkvr]

It is not great because this means that we'd need to perform parsing of strings into the actual hardforks names on demand and won't have type-safety during parsing.

imo this is fine because genesis -> chainspec is an additional step anyway

rn we're keeping Genesis directly on chainspec so we would need to update this to ensure correct hardfork names https://github.com/paradigmxyz/reth/blob/dd4715f5d1b33c695783541fe1b32d07baff8bf5/crates/chainspec/src/spec.rs#L35-L36

[mattsse]

right, I think for this we should introduce a new chainspec field that we then set for the known networks accordingly and update the from genesis -> chainspec conversion as well