Update EIP-7623: Clarify and polish text

Merged by EIP-Bot.

EIPS/eip-7623.md

@@ -1,7 +1,7 @@
 ---
 eip: 7623
 title: Increase calldata cost
-description: Increase calldata cost to decrease the maximum block size
+description: Increase calldata cost to reduce maximum block size
 author: Toni Wahrstätter (@nerolation), Vitalik Buterin (@vbuterin)
 discussions-to: https://ethereum-magicians.org/t/eip-7623-increase-calldata-cost/18647
 status: Review
@@ -10,22 +10,18 @@ category: Core
 created: 2024-02-13
 ---
 
-
-
 ## Abstract
 
-The current calldata pricing allows for significantly large blocks of up to 2.8 MB while the average block size is much smaller at 125 KB. 
-This EIP proposes an adjustment in the Ethereum calldata cost to reduce the maximum possible block size and its variance without impacting regular users. 
-This is achieved by increasing the calldata cost for transactions primarily using Ethereum for data availability.
-
+The current calldata pricing permits EL payloads of up to 7.15 MB, while the average size is much smaller at around 100 KB. 
+This EIP proposes adjusting the calldata cost to reduce the maximum possible block size and its variance without negatively impacting regular users. 
+This is achieved by increasing calldata costs for transactions that predominantly post data.
 
 ## Motivation
 
-The block gas limit has not been increased since [EIP-1559](./eip-1559.md), while the average size of blocks has continuously increased due to the growing number of rollups posting data to Ethereum. Furthermore, the cost for calldata hasn't been adjusted since [EIP-2028](./eip-2028).
+The block gas limit has not been increased since [EIP-1559](./eip-1559.md), while the average size of blocks has continuously increased due to the growing number of rollups posting data to Ethereum. Moreover, calldata costs have remained unchanged since [EIP-2028](./eip-2028).
 [EIP-4844](./eip-4844.md) introduces blobs as a preferred method for data availability (DA). 
-This transition demands a reevaluation of calldata pricing, especially with regards to mitigating the inefficiency between the average block size and the maximum one possible.
-By introducing a floor cost dependent on calldata for transactions that are mainly using Ethereum for DA, this proposal aims to reduce the maximum block size to make room for adding more blobs. 
-
+This transition demands a reevaluation of calldata pricing, especially in order to address the disparity between average and maximum block sizes.
+By introducing a floor cost dependent on the ratio of gas spent on EVM operations to calldata, this proposal aims to reduce the maximum block size to make room for additional blobs or potential block gas limit increases.
 
 ## Specification
 
@@ -42,10 +38,10 @@ Let `isContractCreation` be a boolean indicating the respective event.
 The current formula for determining the gas used per transaction, typically described as `nonzero_bytes_in_calldata * 16 + zero_bytes_in_calldata * 4`, is equivalent to:
 
 ```python
-tx.gasused = (
-    21000 \ 
-        + STANDARD_TOKEN_COST * tokens_in_calldata \
-        + evm_gas_used \
+tx.gasUsed = (
+    21000
+        + STANDARD_TOKEN_COST * tokens_in_calldata
+        + evm_gas_used
         + isContractCreation * (32000 + InitCodeWordGas * words(calldata))
 )
 ```
@@ -54,45 +50,50 @@ The formula for determining the gas used per transaction changes to:
 
 ```python
 tx.gasUsed = {
-    21000 \ 
+    21000
     + 
     max (
-        STANDARD_TOKEN_COST * tokens_in_calldata \
-           + evm_gas_used \
+        STANDARD_TOKEN_COST * tokens_in_calldata
+           + evm_gas_used
            + isContractCreation * (32000 + InitCodeWordGas * words(calldata)),
         TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
     )
 ```
 
-Any transaction with a gas limit less than `21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata` is invalid. This limitation exists because transactions must be able to pay for the floor price of their call data without relying the execution of the transaction. There are valid cases where `gasUsed` will be below this floor price, but the floor price needs to be reserved in the transaction gas limit.
+Any transaction with a gas limit below `21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata` is considered invalid. This limitation exists because transactions must cover the floor price of their calldata without relying on the execution of the transaction. There are valid cases where `gasUsed` will be below this floor price, but the floor price needs to be reserved in the transaction gas limit.
 
 ## Rationale
 
-The current maximum block size is approximately 1.79 MB (`30_000_000/16`). One can create blocks full of zero bytes that go up to 7.5 MB, but it is now standard to wrap blocks with snappy compression at the p2p layer and so such zero-byte-heavy blocks would end up smaller than 1.79 MB in practice. With the implementation of [EIP-4844](./eip-4844.md) this increased to ~2.54 MB. Furthermore, the cost for calldata bytes hasn't been adjusted since [EIP-2028](./eip-2028).
-
-This proposal aims to increase the cost of calldata to 10/40 gas for transactions that do not exceed a certain threshold of gas spent on EVM operations. This change will significantly reduce the maximum block size by limiting the number and size of pure-data transactions that can fit into a single block. Specifically, by adjusting the cost of calldata bytes to from 4/16 to 10/40 gas for DA transactions, the goal is to lower the maximum possible block size to roughly 0.72 MB without impacting the vast majority of users.
+The current maximum EL payload size is approximately 1.79 MB (`30_000_000/16`). It is possible to create payloads filled with zero bytes that expand to 7.15 MB. However, since blocks are typically compressed with Snappy at the P2P layer, zero-byte-heavy EL payloads generally compress to under 1.79 MB. The implementation of [EIP-4844](./eip-4844.md) increased the maximum possible compressed block size to approximately 2.54 MB.
 
+This proposal aims to increase the cost of calldata to 10/40 gas for transactions that do not exceed a certain threshold of gas spent on EVM operations relative to gas spent on calldata. This change will significantly reduce the maximum block size by limiting the size of data-heavy transactions that can fit into a single block. By increasing calldata costs from 4/16 to 10/40 gas per byte for data-heavy transactions, this EIP aims to reduce the maximum possible EL payload size to approximately 0.72 MB (`30_000_000/40`) without affecting the majority of users.
 
-This reduction makes room for increasing the block gas limit or the number of blobs, while ensuring network security and efficiency. 
-Importantly, regular users (sending ETH/Tokens/NFTs, engaging in DeFi, social media, restaking, bridging, etc.) who do not use Ethereum almost exclusively for DA, may remain unaffected.
-The calldata cost for transactions involving significant EVM computation remains at 4/16 gas per byte, ensuring those transactions experience no change.
-
+Notably, regular users (e.g. sending ETH/Tokens/NFTs, engaging in DeFi, social media, restaking, bridging, etc.), who do not use calldata predominantly for DA, may remain unaffected.
+The calldata cost for transactions involving significant EVM computation remains at 4/16 gas per byte, so those transactions are unaffected.
 
 ## Backwards Compatibility
 
 This is a backwards incompatible gas repricing that requires a scheduled network upgrade.
 
-Wallet developers and node operators MUST update their handling of gas estimation to accommodate the new calldata cost rules. Specifically:
+Wallet developers and node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically:
 
-1. **Wallets**: Wallets using `eth_estimateGas` to calculate the gas limit for transactions MUST be updated to ensure that they correctly account for the `TOTAL_COST_FLOOR_PER_TOKEN` parameter. Failure to do so could result in underestimating gas, leading to failed transactions.
+1. **Wallets**: Wallets using `eth_estimateGas` MUST be updated to ensure that they correctly account for the `TOTAL_COST_FLOOR_PER_TOKEN` parameter. Failure to do so could result in underestimating gas, leading to failed transactions.
 
-2. **Node Software**: RPC methods like `eth_estimateGas` must incorporate the revised formula for gas calculation to ensure accurate responses to client requests. Node developers MUST ensure compatibility with the updated calldata pricing logic.
+2. **Node Software**: RPC methods such as `eth_estimateGas` MUST incorporate the updated formula for gas calculation. Node developers MUST ensure compatibility with the updated calldata pricing logic.
 
-Users will be able to continue operating with no changes to their workflows, but underlying wallet and RPC implementations must be updated to ensure smooth functioning.
+Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.
 
 ## Security Considerations
 
-As the maximum possible block size is reduced, no security concerns were raised.
+As the maximum possible block size is reduced, no security concerns have been raised.
+
+In some cases, it might seem advantageous to combine two transactions into one to reduce costs. For example, bundling a transaction that relies heavily on calldata but minimally on EVM resources with another that does the opposite. However, this is not a significant concern for several reasons:
+
+1. This type of bundling is already possible today. Merging multiple transactions can save the 21,000 gas cost for each additional transaction beyond the first, a feature explicitly supported in [ERC-4337](./eip-4337.md).
+2. Such bundling does not compromise the block size reduction objectives of this EIP.
+3. In practice, transaction bundling is often impractical due to challenges such as trust and coordination requirements.
+
+These factors ensure that transaction bundling does not pose a significant issue.
 
 In some cases, it might seem advantageous to combine two transactions into one to reduce costs—for example, bundling a transaction that uses a lot of calldata but minimal EVM resources with another that heavily uses EVM resources. However, this is not a significant concern for several reasons: