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

Update EIP-7691: clarify that all 3 EL constants change in Prague #9243

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+4 −4
Open

Update EIP-7691: clarify that all 3 EL constants change in Prague #9243

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
8 changes: 4 additions & 4 deletions EIPS/eip-7691.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@

Additional EIPs such as [EIP-7623](./eip-7623.md) proposes a calldata cost increase which would significantly lower the worst case base block size, thus creating more headroom for a potential blob throughput increase.

The current long term plan of Ethereum is to implement peerDAS as specified by [EIP-7594](./eip-7594.md), but given the uncertain timelines, this EIP aims to increase the throughput short term to provide some scaling until future solutions are deployed. In order to alleviate valid concerns about solo-stakers, approaches such as the inclusion of a flag indicating the max blobs per block for locally built blocks could be considered.

Check failure on line 25 in EIPS/eip-7691.md

View workflow job for this annotation

GitHub Actions / EIP Walidator

proposal `eip-7594.md` is not stable enough for a `status` of `Review` 

error[markdown-link-status]: proposal `eip-7594.md` is not stable enough for a `status` of `Review`
  --> EIPS/eip-7691.md
   |
25 | The current long term plan of Ethereum is to implement peerDAS as specified by [EIP-7594](./eip-7594.md), but given the uncertain ti...
   |
   = help: because of this link, this proposal's `status` must be one of: `Draft`, `Stagnant`
   = help: see https://ethereum.github.io/eipw/markdown-link-status/


## Specification
Expand All @@ -33,13 +33,13 @@
|------------------------------------------|---------------------|
| `MAX_BLOBS_PER_BLOCK_ELECTRA` | `9` |
| `TARGET_BLOBS_PER_BLOCK_ELECTRA` | `6` |
| `MAX_BLOB_GAS_PER_BLOCK` | `1179648` |
| `TARGET_BLOB_GAS_PER_BLOCK` | `786432` |
| `MAX_BLOB_GAS_PER_BLOCK_PRAGUE` | `1179648` |
| `TARGET_BLOB_GAS_PER_BLOCK_PRAGUE` | `786432` |
| `BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE` | `5007716` |

`MAX_BLOBS_PER_BLOCK_ELECTRA` and `TARGET_BLOBS_PER_BLOCK_ELECTRA` are consumed by the consensus layer clients, and starting at `PECTRA_FORK_EPOCH` replace the respective old max and target values.

`MAX_BLOB_GAS_PER_BLOCK`, `TARGET_BLOB_GAS_PER_BLOCK` and `BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE` are consumed by the execution layer clients, and starting at the epoch when this EIP is activated, replace the old max, target and update fraction values.
`MAX_BLOB_GAS_PER_BLOCK_PRAGUE`, `TARGET_BLOB_GAS_PER_BLOCK_PRAGUE` and `BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE` are consumed by the execution layer clients, and starting at the epoch when this EIP is activated, replace the old max, target and update fraction values.

## Rationale

Expand Down Expand Up @@ -67,7 +67,7 @@

The consensus clients would continue to use `MAX_BLOBS_PER_BLOCK` and `TARGET_BLOBS_PER_BLOCK` for the deneb fork and once the `ELECTRA` fork is active, they would use `MAX_BLOBS_PER_BLOCK_ELECTRA` and `TARGET_BLOBS_PER_BLOCK_ELECTRA` respectively.

The execution clients would continue to use `MAX_BLOB_GAS_PER_BLOCK`, `TARGET_BLOB_GAS_PER_BLOCK` and `BLOB_BASE_FEE_UPDATE_FRACTION` for the cancun fork and once the prague fork is active, they would use `MAX_BLOB_GAS_PER_BLOCK`, `TARGET_BLOB_GAS_PER_BLOCK` and `BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE` respectively.
The execution clients would continue to use `MAX_BLOB_GAS_PER_BLOCK`, `TARGET_BLOB_GAS_PER_BLOCK` and `BLOB_BASE_FEE_UPDATE_FRACTION` for the cancun fork and once the prague fork is active, they would use `MAX_BLOB_GAS_PER_BLOCK_PRAGUE`, `TARGET_BLOB_GAS_PER_BLOCK_PRAGUE` and `BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE` respectively.

## Security Considerations

Expand Down
Loading