Go to Home
Web3 security pattern.
Pectra Competition
Web3 security pattern.
EIP-7840
EIP-7840 adds a blobSchedule object to client configs, enabling per-fork blob limits without constant updates or complex coordination.EIP-7840 introduces a blobSchedule in client configs, simplifying per-fork blob limit adjustments without frequent updates or complexity.

EIP-7840

Table of Contents

Heading 2
Heading 3
Heading 4

What is this EIP about?

EIP-7840 proposes adding a blobSchedule object to Ethereum client configuration files to define the target and maximum blob counts per block for each network fork.

It aims to provide a dynamic and straightforward way to adjust blob limits for forks without relying on constant updates via APIs.

Problem: Managing these blob limits solely on the consensus layer or through frequent communication with the execution layer is inefficient and complex.

Why is this EIP needed?

Currently, execution clients depend on blob configuration data (like max counts) for features like the eth_feeHistory RPC method. Storing this data only in the consensus client makes frequent updates cumbersome and requires additional API calls between clients for each block.

This EIP addresses performance optimization within Ethereum's client architecture by offloading the need for execution and consensus layers to perform excessive data handshakes. It improves client efficiency by statically defining fork-specific limits in configuration files.

What does this EIP propose, and how does it function?

The EIP introduces a blobSchedule configuration object that includes target and max blob counts for each fork. The object is defined as:

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

If a fork does not explicitly specify limits, the values from the last fork are used. If no values exist, both are set to zero.

How it functions:

  1. Adds a simple, per-fork configuration to execution client files.
  2. Reduces the need for frequent client communication over APIs by directly referencing configuration files for blob limits.

What are the security implications of this EIP?

  • Potential risks: Misconfigured or outdated client files could result in incorrect blob limits for execution clients.
  • Mitigation measures: This can be minimized by ensuring that client files are properly updated during forks. The static configuration model reduces runtime errors compared to dynamic APIs, and fallbacks prevent undefined states.