[EIP-4844] Reduce Throughput (ethereum#5863)

* set lower target/max

* add throughput rationale

EIPS/eip-4844.md

@@ -31,7 +31,7 @@ However, data sharding will still take a considerable amount of time to finish i
 This EIP provides a stop-gap solution until that point by implementing the _transaction format_ that would be used in sharding,
 but not actually sharding those transactions. Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded
 by all consensus nodes (but can be deleted after only a relatively short delay).
-Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~1 MB per block and a limit of ~2 MB.
+Compared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.25 MB per block and a limit of ~0.5 MB.
 
 ## Specification
 
@@ -45,10 +45,10 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes
 | `BLOB_COMMITMENT_VERSION_KZG` | `Bytes1(0x01)` |
 | `POINT_EVALUATION_PRECOMPILE_ADDRESS` | `Bytes20(0x14)` |
 | `POINT_EVALUATION_PRECOMPILE_GAS` | `50000` |
-| `MAX_DATA_GAS_PER_BLOCK` | `2**21` |
-| `TARGET_DATA_GAS_PER_BLOCK` | `2**20` |
+| `MAX_DATA_GAS_PER_BLOCK` | `2**19` |
+| `TARGET_DATA_GAS_PER_BLOCK` | `2**18` |
 | `MIN_DATA_GASPRICE` | `1` |
-| `DATA_GASPRICE_UPDATE_FRACTION` | `8902606` |
+| `DATA_GASPRICE_UPDATE_FRACTION` | `2225652` |
 | `MAX_VERSIONED_HASHES_LIST_SIZE` | `2**24` |
 | `MAX_CALLDATA_SIZE` | `2**24` |
 | `MAX_ACCESS_LIST_SIZE` | `2**24` |
@@ -369,7 +369,7 @@ def validate_blob_transaction_wrapper(wrapper: BlobTransactionNetworkWrapper):
 ### On the path to sharding
 
 This EIP introduces blob transactions in the same format in which they are expected to exist in the final sharding specification.
-This provides a temporary but significant scaling relief for rollups by allowing them to scale to 2 MB per slot,
+This provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.25 MB per slot,
 with a separate fee market allowing fees to be very low while usage of this system is limited.
 
 The core goal of rollup scaling stopgaps is to provide temporary scaling relief,
@@ -445,6 +445,10 @@ Hence, it has a similar effect to the existing EIP-1559, but is more "stable" in
 
 The parameter `DATA_GASPRICE_UPDATE_FRACTION` controls the maximum rate of change of the blob gas price. It is chosen to target a maximum change rate of `e(TARGET_DATA_GAS_PER_BLOCK / DATA_GASPRICE_UPDATE_FRACTION) ≈ 1.125` per block.
 
+### Throughput
+
+The values for `TARGET_DATA_GAS_PER_BLOCK` and `MAX_DATA_GAS_PER_BLOCK` are chosen to correspond to a target of 2 blobs (0.25 MB) and maximum of 4 blobs (0.5 MB) per block. These small initial limits are intended to minimize the strain on the network created by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.
+
 ## Backwards Compatibility
 
 ### Blob non-accessibility
@@ -469,8 +473,8 @@ TBD
 
 ## Security Considerations
 
-This EIP increases the storage requirements per Beacon block by a maximum of ~2 MB.
-This is equal to the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.
+This EIP increases the storage requirements per Beacon block by a maximum of ~0.5 MB.
+This is 4x larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.
 Post-merge, block times are expected to be static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.
 
 The _sustained_ load of this EIP is much lower than alternatives that reduce calldata costs, even if the calldata is limited,