Add EIP to uncouple blob counts between CL and EL

Author: ralexstokes

EIPS/eip-7742.md

@@ -0,0 +1,114 @@
+---
+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: Draft
+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. 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.
+
+## Specification
+
+| constants                    | value                                        |
+|---                           |---                                           |
+| `FORK_TIMESTAMP`             | TBD                                          |
+
+### 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-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.
+
+### Block structure and validity
+
+Beginning at the execution timestamp `FORK_TIMESTAMP`, execution clients **MUST** extend the header schema with an
+additional 64-bit field: the `target_blob_count`. This value is set to the current target blob count. The Engine API
+is modified along with this EIP to provide the `target_blob_count` with each payload and implementations can use this
+value to correctly set the block header field.
+
+Validity of the `target_blob_count` 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
+
+At the start of processing any execution block where `block.timestamp >= FORK_TIMESTAMP` (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, any reference to `TARGET_BLOB_GAS_PER_BLOCK` from EIP-4844 can be derived by taking the `target_blob_count` from the CL and multiplying by `GAS_PER_BLOB` as given in EIP-4844.
+
+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.
+
+## Rationale
+
+### Why not have the CL also compute the blob base fee and remove any notion of blob counts from EL processing?
+
+TODO
+
+## 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).