BEP-496: update latest changes; (#513)

BEPs/BEP-496.md

@@ -11,13 +11,13 @@
 # BEP-496: Implement EIP-7623: Increase calldata cost
 
 - [BEP-496: Implement EIP-7623: Increase calldata cost](#bep-496-implement-eip-7623-increase-calldata-cost)
-    * [Abstract](#abstract)
-    * [Motivation](#motivation)
-    * [Specification](#specification)
-    * [Rationale](#rationale)
-    * [Backwards Compatibility](#backwards-compatibility)
-    * [Security Considerations](#security-considerations)
-    * [Copyright](#copyright)
+  * [Abstract](#abstract)
+  * [Motivation](#motivation)
+  * [Specification](#specification)
+  * [Rationale](#rationale)
+  * [Backwards Compatibility](#backwards-compatibility)
+  * [Security Considerations](#security-considerations)
+  * [Copyright](#copyright)
 
 ## Abstract
 
@@ -27,53 +27,56 @@ This is achieved by increasing calldata costs for transactions that predominantl
 
 ## 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. 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).
+The block gas limit has not been increased since [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), 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](https://eips.ethereum.org/EIPS/eip-2028).
+[EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduces blobs as a preferred method for data availability (DA).
 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
 
-| Parameter | Value |
-| - | - |
-| `STANDARD_TOKEN_COST`    |  `4` |
-| `TOTAL_COST_FLOOR_PER_TOKEN`    |  `10` |
+| Parameter                    | Value |
+|------------------------------|-------|
+| `STANDARD_TOKEN_COST`        | `4`   |
+| `TOTAL_COST_FLOOR_PER_TOKEN` | `10`  |
 
 
 Let `tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4`.
 
 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:
+Let `execution_gas_used` be the gas used for EVM execution with the gas refund subtracted.
+
+The current formula for determining the total gas used per transaction (`tx.gasUsed`) is equivalent to:
 
 ```python
 tx.gasUsed = (
     21000
-        + STANDARD_TOKEN_COST * tokens_in_calldata
-        + evm_gas_used
-        + isContractCreation * (32000 + InitCodeWordGas * words(calldata))
+    + STANDARD_TOKEN_COST * tokens_in_calldata
+    + execution_gas_used
+    + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata))
 )
 ```
 
 The formula for determining the gas used per transaction changes to:
 
 ```python
-tx.gasUsed = {
+tx.gasUsed = (
     21000
-    + 
-    max (
+    +
+    max(
         STANDARD_TOKEN_COST * tokens_in_calldata
-           + evm_gas_used
-           + isContractCreation * (32000 + InitCodeWordGas * words(calldata)),
+        + execution_gas_used
+        + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata)),
         TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata
     )
+)
 ```
 
-Any transaction with a gas limit below `21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata` or below it's intrinsic gas cost (take the maximum of these two calculations) 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.
+Any transaction with a gas limit below `21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata` or below its intrinsic gas cost (take the maximum of these two calculations) 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 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.
+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](https://eips.ethereum.org/EIPS/eip-4844) 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.
 
@@ -98,7 +101,7 @@ As the maximum possible block size is reduced, no security concerns have been ra
 
 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).
+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](https://eips.ethereum.org/EIPS/eip-4337).
 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.
 

README.md

@@ -83,6 +83,7 @@ Here is the list of subjects of BEPs:
 | [BEP-440](./BEPs/BEP-440.md) | Implement EIP-2935: Serve historical block hashes from state | Standards | Review |
 | [BEP-441](./BEPs/BEP-441.md) | Implement EIP-7702: Set EOA account code | Standards | Review |
 | [BEP-466](./BEPs/BEP-466.md) | Make the block header format compatible with EIP-7685 | Standards | Review |
+| [BEP-469](./BEPs/BEP-469.md) | Implement EIP-7623: Increase calldata cost | Standards | Review |