Update EIP-7742: update the required EL headers and the gas fee mechanism

EIPS/eip-7742.md

@@ -1,8 +1,8 @@
 ---
 eip: 7742
-title: Uncouple blob count between CL and EL
+title: Uncouple blobs per block between CL and EL
 description: Have CL verify blob maximum and have EL get target value from CL
-author: Alex Stokes (@ralexstokes)
+author: Alex Stokes (@ralexstokes), Gajinder Singh (@g11tech), Bert (@bkellerman), Toni Wahrstätter (@nerolation), Ansgar Dietrichs (@adietrichs), Barnabé Monnot (@barnabemonnot)
 discussions-to: https://ethereum-magicians.org/t/eip-7742-uncouple-blob-count-between-cl-and-el/20550
 status: Review
 type: Standards Track
@@ -13,7 +13,7 @@ requires: 4844
 
 ## Abstract
 
-Update blob maximum and target verification from [EIP-4844](./eip-4844.md).
+Update blob maximum, target, and blob gas fee computation from [EIP-4844](./eip-4844.md).
 
 The execution layer no longer verifies the blob maximum and receives the target dynamically from the consensus layer.
 
@@ -33,67 +33,99 @@ This EIP also changes how the EL sources the current blob target value for two r
 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 specifies a maximum allowed blobs 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.
+and deployment of changes to the blobs per block 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.
+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
+For optimistically synced blocks from peer nodes, EL may further assume that the entire ancestor EL peer synced chain blocks correctly obeys this condition by the canonicality and correctness of the block they backfilling from as instructed by the CL.
 
-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.
+Hence we entirely deprecated the `MAX_BLOB_GAS_PER_BLOCK` checks from [EIP-4844](./eip-4844.md) in the EL while letting the maximum blobs per block constraints in the CL stay at `6` equivalent to `MAX_BLOB_GAS_PER_BLOCK`.
 
-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.
+#### Target blobs per block
+
+The target is currently specified as a fixed value in relation to the blobs per block. 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.
+
+This target is now driven by the CL which sends the current target value to the EL for purposes of `excess_blob_gas` accumulation and validation. The EL block header will also need to be extended with this `target_blobs_per_block` value to preserve the security of optimistic sync.
+
+The target blobs per block in CL (and hence indirectly in EL) is also increased from [EIP-4844](./eip-4844.md)'s `OLD_TARGET_BLOBS_PER_BLOCK` to `TARGET_BLOBS_PER_BLOCK_EIP_7742`.
+
+#### Normalized `excess_gas`
+
+With the changing target, we also need to scale the `BLOB_BASE_FEE_UPDATE_FRACTION` from [EIP-4844](./eip-4844.md) accordingly to bound the price jumps by +-12.5%. But this introduces some irregularity whenever target gets updated because excess blob gas (accumulated via old target) is now effectively scaled down by this changed fraction in the fee calculations.
+
+To mitigate this irregularity, we now save a _normalized_ excess gas with respect to a fixed `EXCESS_BLOB_GAS_NORMALIZATION_TARGET` and use a corresponding `BLOB_BASE_FEE_UPDATE_FRACTION_NORMALIZED` in the base fee calculations.
+
+#### Increased min blob base fee
+
+The community feels that there is a need to increase the min blob base fee for a fair blob market. To this end the base fee per blob gas will be increased to `MIN_BASE_FEE_PER_BLOB_GAS_EIP_7742`.
 
 ## Specification
 
-### Block structure and validity
+| Constant | Value | Remarks|
+| - | - | - |
+| `OLD_TARGET_BLOBS_PER_BLOCK` | `3` | blob target corresponding to [EIP-4844](./eip-4844.md) |
+| `TARGET_BLOBS_PER_BLOCK_EIP_7742` | `4` | increase the target blobs to `4`|
+| `MIN_BASE_FEE_PER_BLOB_GAS_EIP_7742` | `2**25` | the new min blob base fee |
+| `EXCESS_BLOB_GAS_NORMALIZATION_TARGET_BLOBS` | `128` | normalize excess gas to a target of `128` blobs |
+| `BLOB_BASE_FEE_UPDATE_FRACTION_PER_TARGET_BLOB` | `1112825` | used to calculate normalized update fraction for excess gas |
+| `BLOB_BASE_FEE_UPDATE_FRACTION_NORMALIZED` | `142441600`| excess gas update fraction for the normalized target of `128` blobs |
+
+### Block processing
 
 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.
+additional 64-bit field: the `target_blobs_per_block`. This values is set to the one provided by the CL during block production.
 
-Validity of the `target_blobs_per_block` is guaranteed from the consensus layer, much like how withdrawals are handled.
+Any reference to `TARGET_BLOB_GAS_PER_BLOCK` from [EIP-4844](./eip-4844.md) (for e.g. for `excess_blob_gas` calculations) can be derived by taking the `target_blobs_per_block` from the EL block header and multiplying by `GAS_PER_BLOB`.
 
-When verifying a block, execution clients **MUST** ensure the target blob count in the block header matches the one
-provided by the consensus client.
+Validity of these values is guaranteed from the consensus layer, much like how withdrawals are handled. Hence when verifying a block, execution clients **MUST** ensure the target blobs per block 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.
+Furthermore `get_base_fee_per_blob_gas` as specified by [EIP-4844](./eip-4844.md) is as modified below:
 
-### 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, any reference to `TARGET_BLOB_GAS_PER_BLOCK` from EIP-4844 can be derived by taking the `target_blobs_per_block` from the CL and multiplying by `GAS_PER_BLOB` as given in EIP-4844.
+```python
+def calc_excess_blob_gas(parent: Header) -> int:
+  # normalize parent's excess blob gas if this block was fork block
+  if(parent.timestamp < FORK_TIMESTAMP)
+    # note multiplication of parent excess blob gas with EXCESS_BLOB_GAS_NORMALIZATION_TARGET_BLOBS is before
+    # integer division by OLD_TARGET_BLOBS_PER_BLOCK to preserve sensitivity
+    normalized_parent_excess_blob_gas = (parent.excess_blob_gas * EXCESS_BLOB_GAS_NORMALIZATION_TARGET_BLOBS) // OLD_TARGET_BLOBS_PER_BLOCK
+    target_blobs_per_block = OLD_TARGET_BLOBS_PER_BLOCK
+  else
+    normalized_parent_excess_blob_gas = parent.excess_blob_gas
+    target_blobs_per_block = parent.target_blobs_per_block
+
+  # note: multiplication of diff with EXCESS_BLOB_GAS_NORMALIZATION_TARGET_BLOBS is before interger 
+  # division by target_blobs_per_block to preserve sensitivity
+  return (normalized_parent_excess_blob_gas + ((parent.blob_gas_used - target_blob_gas) * EXCESS_BLOB_GAS_NORMALIZATION_TARGET_BLOBS) // target_blobs_per_block)
+
+def get_base_fee_per_blob_gas(header: Header) -> int:
+  return fake_exponential(
+    MIN_BASE_FEE_PER_BLOB_GAS_EIP_7742,
+    header.excess_blob_gas,
+    BLOB_BASE_FEE_UPDATE_FRACTION_NORMALIZED
+    )
+```
 
-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.
+Rest of the [EIP-4844](./eip-4844.md) specification is not changed
 
 ### 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.
+To kickstart block construction, CL provides EL a target and a maximum blobs per block. 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 done as specified above.
 
-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.
+For a genesis block with no existing parent, the value should be set according to the agreed specification for the target blobs per block given by that genesis block's protocol rule set. For the purposes of this EIP, the `target_blobs_per_block` at genesis is set to `OLD_TARGET_BLOBS_PER_BLOCK`.
 
 ## Rationale
 
-### Why not have the CL also compute the blob base fee and remove any notion of blob counts from EL processing?
+### Why not have the CL also compute the blob base fee and remove any notion of blobs per block 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.