Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 22 commits into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 55 additions & 24 deletions EIPS/eip-7742.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
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)
author: Alex Stokes (@ralexstokes), Gajinder Singh (@g11tech), Bert (@bkellerman)
discussions-to: https://ethereum-magicians.org/t/eip-7742-uncouple-blob-count-between-cl-and-el/20550
status: Review
type: Standards Track
Expand All @@ -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.

Expand Down Expand Up @@ -44,37 +44,68 @@ 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.
The max blob count is now provided and controlled by the CL during block production and a corresponding `max_blob_count` uint64 field is added to the EL header for purposes of optimistic sync validation of the maxmium versioned hashes a block can contain as well as for `excess_blob_gas` validations. This will supersede the [EIP-4844](./eip-4844.md) max blob gas validations.

#### Target amount of blobs per block
#### Target 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.
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.
To this end similar to `max_blob_count`, CL now provides a blob count target as well during block production and the EL block header is extended with this `target_blob_count` value to preserve the security of optimistic sync for the purpose of `excess_blob_gas` validation.

#### Normalized excess blob gas

At any block we don't want the gas update factor (whether pushing gas up or down) to exceed ~1.125. This is essentially achieved in [EIP-4844](./eip-4844.md) by having an appropriate `BLOB_BASE_FEE_UPDATE_FRACTION` to divide `excess_blob_gas` accumulator while exponetiating it

Since the target from CL could theoretically change block to block, we need to normalize excess gas accumulation because the update fraction is actually directly based on both the target and max (max value `excess_blob_gas` can jump by in a block).

We propose to "normalize" the gas diffs every block against its target/max and then accumulate in `excess_blob_gas` so that we accumulate normalized `excess_blob_gas` every block and can use a constant normalized update fraction in our fee calculations.

## Specification

### Block structure and validity
### Execution Block structure and validity

Upon activation of this EIP, 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.
additional 64-bit field: the `target_blob_count`. This values is set to the one provided by the CL with the modified engine api fcU's payload attributes.

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 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.

`excess_blob_gas` in the block now holds _normalized_ excess blob gas accumulating `((blob_gas_used-target_blob_gas)/target_blob_gas) * EXCESS_BLOB_GAS_NORMALIZATION_FACTOR`. We choose `EXCESS_BLOB_GAS_NORMALIZATION_FACTOR` to `100E6` and this makes our choice of `NORMALIZED_BLOB_BASE_FEE_UPDATE_FRACTION` as `3338477 * 100E6 // 393216 = 849018605`.

| Constant | Value |
| - | - |
| `EXCESS_BLOB_GAS_NORMALIZATION_FACTOR` | `100E6` |
| `NORMALIZED_BLOB_BASE_FEE_UPDATE_FRACTION` | `849018605` |
| `OLD_TARGET_BLOB_GAS_PER_BLOCK` | `393216` |

At the fork block (where parent.timestamp < FORK_TIMESTAMP), we convert parent's accumulated `excess_blob_gas` to the normalized `excess_blob_gas` to be used in this block's `excess_blob_gas` accumulator.

```python
def calc_excess_blob_gas(parent: Header) -> int:
if(parent.timestamp < FORK_TIMESTAMP)
normalized_parent_excess_blob_gas = parent.excess_blob_gas * EXCESS_BLOB_GAS_NORMALIZATION_FACTOR // OLD_TARGET_BLOB_GAS_PER_BLOCK
target_blob_gas = OLD_TARGET_BLOB_GAS_PER_BLOCK
max_excess_gas_diff_possible = OLD_TARGET_BLOB_GAS_PER_BLOCK
else
normalized_parent_excess_blob_gas = parent.excess_blob_gas
target_blob_gas = parent.target_blob_count * GAS_PER_BLOB
max_excess_gas_diff_possible = max(parent.max_blob_count - parent.target_blob_count, parent.target_blob_count) * GAS_PER_BLOB

Validity of the `target_blob_count` is guaranteed from the consensus layer, much like how withdrawals are handled.
return (normalized_parent_excess_blob_gas + (parent.blob_gas_used - target_blob_gas) * EXCESS_BLOB_GAS_NORMALIZATION_FACTOR // max_excess_gas_diff_possible)

When verifying a block, execution clients **MUST** ensure the target blob count in the block header matches the one
provided by the consensus client.
def get_base_fee_per_blob_gas(header: Header) -> int:
if header.timestamp < FORK_TIMESTAMP
update_fraction = BLOB_BASE_FEE_UPDATE_FRACTION
else
update_fraction = NORMALIZED_BLOB_BASE_FEE_UPDATE_FRACTION

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.
return fake_exponential(
MIN_BASE_FEE_PER_BLOB_GAS,
header.excess_blob_gas,
update_fraction
)
```

### Block processing

Expand All @@ -83,11 +114,11 @@ the verification of the blob maximum as given in EIP-4844 can be skipped. Concre
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.
Block's `excess_blob_gas` and blob base fee calculations are updated to be the ones specified in this EIP Otherwise, the specification of EIP-4844 is not changed.

### Block construction

The Engine API is extended to provide both the `target_blob_count` and the `maximum_blob_count` when the CL requests the EL to construct a payload for proposal.
The Engine API is extended to provide both the `target_blob_count` and the `max_blob_count` 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.

Expand Down
Loading