Update EIP-7691: Move to Review

Merged by EIP-Bot.

EIPS/eip-7691.md

@@ -4,15 +4,15 @@ title: Blob throughput increase
 description: Increase the number of blobs to reach a new target and max of 6 and 9 blobs per block respectively
 author: Parithosh Jayanthi (@parithosh), Toni Wahrstätter (@nerolation), Sam Calder-Mason (@samcm), Andrew Davis (@savid)
 discussions-to: https://ethereum-magicians.org/t/eip-7691-blob-throughput-increase/19694
-status: Draft
+status: Review
 type: Standards Track
 category: Core
 created: 2024-04-17
 ---
 
 ## Abstract
 
-This EIP proposes to increase to the number of blobs in a block to provide more scale to Ethereum via L2 solution that rely on L1 data capacity.
+Increases the number of blobs in a block to provide more scale to Ethereum via L2 solution that rely on L1 data capacity.
 
 ## Motivation
 
@@ -31,7 +31,6 @@ The current long term plan of Ethereum is to implement peerDAS as specified by [
 
 | Constant                                 | Value               |
 |------------------------------------------|---------------------|
-| `PECTRA_FORK_EPOCH`                      | `tbd` <!-- TODO --> |
 | `MAX_BLOBS_PER_BLOCK_ELECTRA`            | `9`                 |
 | `TARGET_BLOBS_PER_BLOCK_ELECTRA`         | `6`                 |
 | `MAX_BLOB_GAS_PER_BLOCK`                 | `1179648`           |
@@ -46,24 +45,18 @@ The current long term plan of Ethereum is to implement peerDAS as specified by [
 
 ### Simplicity
 
-A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected co-ordination efforts.
-
 The EIP aims to minimize the amount of testing and implementation effort from the perspective of the client teams, to allow for more resources to be allocated to peerDAS and other scaling research.
 
 While this EIP may not achieve the new optimal blob limit, it offers a compromise for a short term increase.
 
-### Testable changes
-
-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 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:
 
@@ -78,7 +71,13 @@ The execution clients would continue to use `MAX_BLOB_GAS_PER_BLOCK`, `TARGET_BL
 
 ## Security Considerations
 
-todo <!-- TODO -->
+### Network Impacts
+
+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.
+
+### Stability Around Fork Epoch
+
+A blob limit increase at the fork transition is relatively straightforward from an implementation perspective. We would need to deploy an increased amount of monitoring around the fork epoch, but after a period of stability we can assume that the blob limit increase was successful, reducing any unexpected co-ordination efforts.
 
 ## Copyright