EIP-7840 Final

Add blob schedule to EL config files

Authors:

Canonical data: /latest/eips/7840.json

Include per-fork blob parameters in client configuration files

Timeline

Pectra

Included

EIP Created Dec 12, 2024

Key Benefits

● Reduces coordination overhead between clients
● Enables dynamic tuning of blob capacity
● Improves ops clarity for testnets

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

No direct impact.

Application Developers

No changes for contract developers.

Wallet Developers

No impact on wallets.

Tooling / Infrastructure

Simplifies introspection of blob parameters from network configs.

Layer 2s

Rollups can benefit from clearer capacity settings.

Stakers & Node Operators

Easier to follow blob schedule updates.

CL Client Developers

CL needs to be aware of new config fields.

EL Client Developers

Genesis configuration processing needs to implement new fields.

North Star Goal Alignment

● Scale Blobs: Enables easier configuration for blob target value and its scaling in the future.

Abstract

Add a new object to client configuration files blobSchedule which lists the target blob count per block and max blob count per block for each fork.

Motivation

ensure there is a way to dynamically adjust the target and max blob counts per block
ensure there is a way to dynamically adjust the blob base fee update fraction
avoid complex handshake over engine API

Specification

Extend client configuration files with the object blobSchedule, which has the following shape:

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

Clients must configure the target, max and baseFeeUpdateFraction per-fork. The behavior when the configuration is missing or incomplete for a fork is undefined. Clients are free to choose how to handle this situation.

Rationale

Although maintaining the target and max blob only in the consensus client is desirable, we acknowledge the reality that execution clients need these values for various activities. For example, the eth_feeHistory RPC method returns a field blobGasUsedRatio that does require the max, even though the core protocol doesn't specifically need such value. Passing this value over the engine API every block seem overkill so we believe a configuration value is a good middle ground. Additionally, the baseFeeUpdateFraction parameter was added to adjust the responsiveness of blob gas pricing per fork.