Merge f8da514 into 6354028

ethereum · Nov 28, 2024 · cc53043 · cc53043
2 parents 6354028 + f8da514
commit cc53043
Showing 1 changed file with 21 additions and 6 deletions.
diff --git a/EIPS/eip-7691.md b/EIPS/eip-7691.md
@@ -29,13 +29,16 @@ The current long term plan of Ethereum is to implement peerDAS as specified by [
 
 ### Parameters
 
-| Constant                         | Value               |
-|----------------------------------|---------------------|
-| `PECTRA_FORK_EPOCH`              | `tbd` <!-- TODO --> |
-| `MAX_BLOBS_PER_BLOCK_ELECTRA`    | `9`                 |
-| `TARGET_BLOBS_PER_BLOCK_ELECTRA` | `6`                 |
+| Constant                                 | Value               |
+|------------------------------------------|---------------------|
+| `PECTRA_FORK_EPOCH`                      | `tbd` <!-- TODO --> |
+| `MAX_BLOBS_PER_BLOCK_ELECTRA`            | `9`                 |
+| `TARGET_BLOBS_PER_BLOCK_ELECTRA`         | `6`                 |
+| `BLOB_BASE_FEE_UPDATE_FRACTION_ELECTRA`  | `5007716`           |
 
-The values defined are consumed by the consensus layer clients and are passed via the engineAPI to the execution layer clients. The mechanism describing this uncoupling is specified in [EIP-7742](./eip-7742.md).
+`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. `TARGET_BLOBS_PER_BLOCK_ELECTRA` is then passed via the engineAPI to the execution layer clients. The mechanism describing this uncoupling is specified in [EIP-7742](./eip-7742.md).
+
+`BLOB_BASE_FEE_UPDATE_FRACTION_ELECTRA` is consumed by the execution layer clients, and starting at `PECTRA_FORK_EPOCH` replaces the old update fraction value.
 
 ## Rationale
 
@@ -51,6 +54,18 @@ While this EIP may not achieve the new optimal blob limit, it offers a compromis
 
 Through the use of big block/blob tests on Ethereum mainnet as well as testnets, we can earn a high degree of certainity that the blob limit increase would not negatively impact the network. These tests as well as the associated analysis can be performed mostly by non-client team entities, with minimal input required. Since the changes are quite contained, the EIP should be able to reduce the risk of the blob limit increase.
 
+### Update Fraction
+
+The original target and max values from [EIP-4844](./eip-4844.md) were at a 1:2 ratio. As a consequence, responsiveness to full and empty blob sections was symmetrical:
+* full blobs: basefee increases by ~12.5%
+* no blobs: basefee decreases by ~11.1%
+
+The new target and max values from this EIP are at a 2:3 ratio, which breaks that symmetry.As a consequence, the basefee becomes significantly more responsive to empty blob sections (that are 6 blobs under target) than to full ones (that are 3 blobs over target). This is by design, as it takes two blocks with full blobs in a row to make up for a single block with no blobs. However, it creates the challenge of finding a good compromise base fee sensitivity level.
+
+The `BLOB_BASE_FEE_UPDATE_FRACTION_ELECTRA` value in this EIP is chosen as the mid-point between keeping the responsiveness to full blobs and no blobs constant:
+* full blobs: basefee increases by ~8.2%
+* no blobs: basefee decreases by ~14.5%
+
 ## Backwards Compatibility
 
 The consensus clients would continue to use `MAX_BLOBS_PER_BLOCK` for the deneb fork and once the `ELECTRA` fork is active, they would use `MAX_BLOBS_PER_BLOCK_ELECTRA`.