---
eip: 7742
title: Uncouple blob count between CL and EL
description: Have CL verify blob maximum and have EL get target value from CL
author: Alex Stokes (@ralexstokes)
discussions-to: https://ethereum-magicians.org/t/eip-7742-uncouple-blob-count-between-cl-and-el/20550
status: Stagnant
type: Standards Track
category: Core
created: 2024-07-12
requires: 4844
---

## Abstract

Update blob maximum and target verification from [EIP-4844](./eip-4844.md).

The execution layer no longer verifies the blob maximum and receives the target dynamically from the consensus layer.

## Motivation

Following EIP-4844, the execution layer (EL) maintains a hard-coded blob target value and blob maximum value. Given the relationship
of the EL and the consensus layer (CL) node software, the verification of the blob maximum is redundant so it can be removed
entirely without any change in security. The blob maximum is still provided during block construction via the Engine API.
This EIP also changes how the EL sources the current blob target value for two reasons:

1) Gain more flexibility over the value, rather than the static `TARGET == MAX // 2` relation in EIP-4844.

2) Uncouple development and deployment of the CL and EL layers in the event it is desirable to change the blob target value.

### Background

The data facility introduced via EIP-4844 adds blobs to Ethereum blocks, which are simply fixed sets of data that can be
included in the canonical chain but have no execution semantics (cf. `calldata` in an Ethereum transaction).

The protocol specifies a maximum allowed blob count per block to prevent DoS vectors via the abuse of this data facility.
The protocol also maintains an [EIP-1559](./eip-1559.md)-like "target" value for an intended running average amount of blob throughput per
unit time. Blob usage is compared against this target to influence a "blob base fee" to administer allocation of this
resource to users of the Ethereum protocol.

Both of these values are currently hard-coded in the EL after EIP-4844 and the blob maximum is separately hard-coded in
the CL following EIP-4844. This EIP proposes a set of changes to uncouple these values across the CL and EL to make development
and deployment of changes to the blob count easier.

#### Maximum blobs per block

The blob maximum is verified in the CL node and the EL inherits this verification during the consistency check of the
versioned hashes corresponding to each blob as specified by the Engine API. Because of this, the strict check specified
by EIP-4844 is unnecessary.

#### Target amount of blobs per block

The target is currently specified as a fixed value in relation to the blob count. The Ethereum community intends to increase
the blob parameters as part of its scaling strategy and the ability to have a more flexible target value in relation to
the blob max is desirable to reduce rigidity in this protocol parameter.

Even if the EL keeps a fixed target value based on the max, removing the max implies the EL would not know what the target
value should be. To address this lack of information, this EIP proposes the CL sends the current target value to the EL
with each provided payload over the Engine API. The EL block header will also need to be extended with this target value
to preserve the security of optimistic sync.

## Specification

### Block structure and validity

Upon activation of this EIP, execution clients **MUST** extend the header schema with an
additional 64-bit field: the `target_blobs_per_block`. This value is set to the current target blob count. The Engine API
is modified along with this EIP to provide the `target_blobs_per_block` with each payload and implementations can use this
value to correctly set the block header field.

Validity of the `target_blobs_per_block` is guaranteed from the consensus layer, much like how withdrawals are handled.

When verifying a block, execution clients **MUST** ensure the target blob count in the block header matches the one
provided by the consensus client.

For a genesis block with no existing parent, the value should be set according to the agreed specification for the
target blob count given by that genesis block's protocol rule set.

### Block processing

Upon activating this EIP (i.e. before processing any transactions),
the verification of the blob maximum as given in EIP-4844 can be skipped. Concretely, this means any logic relating
to `MAX_BLOB_GAS_PER_BLOCK` as given in EIP-4844 can be deprecated.

Additionally, `calc_excess_blob_gas` is updated as follows:

```python
def calc_excess_blob_gas(parent: Header) -> int:
    target_blob_gas = parent.target_blobs_per_block * GAS_PER_BLOB
    if parent.excess_blob_gas + parent.blob_gas_used < target_blob_gas:
        return 0
    else:
        return parent.excess_blob_gas + parent.blob_gas_used - target_blob_gas
```

Otherwise, the specification of EIP-4844 is not changed. For example, blob base fee accounting and excess blob gas tracking occur in the exact same way.

### Block construction

The Engine API is extended to provide both the `target_blobs_per_block` and the `max_blobs_per_block` when the CL requests the EL to construct a payload for proposal.

These values should be used to ensure the correct number of blobs are included in any constructed payload, and to ensure that the blob base fee accounting is correctly computed.

## Rationale

### Why not have the CL also compute the blob base fee and remove any notion of blob counts from EL processing?

Hoisting the full computation into the CL is possible, but it does violate the separation of concerns between these two layers of the protocol stack.
The CL maintains a maximum value to address e.g. DoS risks, and the EL maintains knowledge of the target value to address fee accounting.
Putting the target computation in the CL violates the respective responsibilities of each layer.

## Backwards Compatibility

No issues.

## Test Cases

N/A

## Reference Implementation

N/A

## Security Considerations

N/A

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).