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.

Sign up for GitHub

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

Jump to bottom

Update EIP-7742: Move to Review #8837

Merged
merged 2 commits into from
Sep 4, 2024
Merged

Update EIP-7742: Move to Review #8837

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8839df8
update EIP-7742 to `Review` status
ralexstokes Aug 29, 2024
9c4ab4b
address review feedback
ralexstokes Sep 3, 2024
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
14 changes: 5 additions & 9 deletions EIPS/eip-7742.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ 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
status: Review
type: Standards Track
category: Core
created: 2024-07-12
Expand All @@ -28,12 +28,6 @@ This EIP also changes how the EL sources the current blob target value for two r

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
Expand Down Expand Up @@ -65,9 +59,11 @@ value should be. To address this lack of information, this EIP proposes the CL s
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

Beginning at the execution timestamp `FORK_TIMESTAMP`, execution clients **MUST** extend the header schema with an
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.
Expand All @@ -82,7 +78,7 @@ 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),
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_blob_count` from the CL and multiplying by `GAS_PER_BLOB` as given in EIP-4844.
Expand Down
Loading