diff --git a/EIPS/eip-7742.md b/EIPS/eip-7742.md new file mode 100644 index 00000000000000..0f7cd445a60080 --- /dev/null +++ b/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](./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. + +### 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).