EIP-7863: Fix Linter issues

EIPS/eip-7863.md

@@ -2,8 +2,8 @@
 eip: 7863
 title: Block-level Warming
 description: Warm addresses and storage keys over the duration of a block
-author: Toni Wahrstätter (@nerolation), Alex Stokes (@ralexstokes), Ansgar Dietrichs (@adietrichs)
-discussions-to: ""
+author: Toni Wahrstätter (@nerolation), Jochem Brouwer (@jochem-brouwer), Alex Stokes (@ralexstokes), Ansgar Dietrichs (@adietrichs)
+discussions-to: https://ethereum-magicians.org/t/eip-7863-block-level-warming/22572
 status: Draft
 type: Standards Track
 category: Core
@@ -30,8 +30,9 @@ As of Jan. 2025, the empirically messured efficiency gains are around 5%.
 ### Mechanics
 
 When a storage slot is accessed within a block:
-1. The first access to a slot in a block incurs the cold access cost as of [EIP-2929](./eip-2929).
-2. All subsequent accesses to the same slot within the same block incur only the warm access cost as of [EIP-2929](./eip-2929).
+
+1. The first access to a slot in a block incurs the cold access cost as of [EIP-2929](./eip-2929.md).
+2. All subsequent accesses to the same slot within the same block incur only the warm access cost as of [EIP-2929](./eip-2929.md).
 3. The warm/cold status resets at block boundaries
 
 ### Block Processing
@@ -41,14 +42,14 @@ When a storage slot is accessed within a block:
 2. For each transaction in the block:
    * Before processing storage access:
      * Check if touched address is in `block_level_accessed_addresses`
-     * If yes: charge `GAS_WARM_ACCESS`
+     * If yes: charge `WARM_STORAGE_READ_COST`
      * If no:
-       * Charge `GAS_COLD_ACCOUNT_ACCESS`
+       * Charge `COLD_ACCOUNT_ACCESS_COST`
        * Add address to `block_level_accessed_addresses`
      * Check if storage key is in `block_level_accessed_storage_keys`
-     * If yes: charge `GAS_WARM_ACCESS`
+     * If yes: charge `WARM_STORAGE_READ_COST`
      * If no:
-       * Charge `GAS_COLD_SLOAD`
+       * Charge `COLD_SLOAD_COST`
        * Add storage key to `block_level_accessed_storage_keys`
 
 
@@ -117,14 +118,17 @@ The proposal builds on several key observations:
 
 2. **Backward Compatibility**: The worst-case scenario for any transaction remains unchanged - it will never pay more than the current cold access cost for its first access to a slot.
 
-3. **First Access Warms For All**: Under the proposed mechanism, the first transaction in a block that accesses and warms multiple addresses or storage slots bears the entire cost of warming, even if subsequent transactions benefit from those already-warmed slots without incurring additional costs. This approach is deemed acceptable because early execution within a block—where warming typically occurs—is generally occupied for transactions placed by professional builders aiming for top-of-block execution. Since the resulting cost discrepancy is relatively minor, a more complex cost-sharing model is avoided in favor of maintaining simplicity.
+3. **Handling Reverts**: In EIP-2929, if a sub-call reverts, all accessed addresses and slots are reverted to a cold state. Under block-level warming, it remains an open question whether a failing transaction (i.e., one that reverts) should ‘unwarm’ previously warmed addresses and slots for subsequent transactions within the same block. Some propose removing this revert-induced “cold reset” altogether to maintain consistency with block-level warming. This point warrants further discussion, particularly around whether or not preserving a warmed state even upon failure aligns with the broader goal of better matching gas costs to actual client caching behavior.
+
+
+4. **First Access Warms For All**: Under the proposed mechanism, the first transaction in a block that accesses and warms multiple addresses or storage slots bears the entire cost of warming, even if subsequent transactions benefit from those already-warmed slots without incurring additional costs. This approach is deemed acceptable because early execution within a block—where warming typically occurs—is generally occupied for transactions placed by professional builders aiming for top-of-block execution. Since the resulting cost discrepancy is relatively minor, a more complex cost-sharing model is avoided in favor of maintaining simplicity.
 An alternative to the one-warms-for-all mechanism involves distributing the warming costs across all accesses within a block. In this approach, each transaction must at least be able to pay the cold access cost. Once all transactions in the block are executed, the total warming costs are evenly distributed, and transaction originators are refunded accordingly.
 
-4. **Alternative Block Warming Windows**: Instead of applying warming at the block level, more advanced multi-block warming approaches can be considered. Potential options include:
+5. **Alternative Block Warming Windows**: Instead of applying warming at the block level, more advanced multi-block warming approaches can be considered. Potential options include:
     * Warming addresses and storage keys over the duration of an epoch
     * Using a ring buffer spanning `x` blocks
 
-    Since the Execution Layer (EL) currently operates without regard to epoch boundaries, it may be preferable to maintain this design. Therefore, the second option, involving a ring buffer of size x, could be more suitable.
+    Since the Execution Layer (EL) currently operates without regard to epoch boundaries, it may be preferable to maintain this design. Therefore, the second option, involving a ring buffer of size x, could be more suitable. For the ring buffer, one approach might be to store the relevant warmed information in the block header for those x blocks, but this introduces additional overhead and can complicate statelessness. Careful design would be required to manage these trade-offs (e.g., header size, client complexity) if a multi-block warming solution were adopted.
 
 ## Backwards Compatibility
 
@@ -134,11 +138,6 @@ This change is not backward compatible and requires a hard fork activation. Howe
 2. Gas costs will only decrease, never increase
 3. Contract logic depending on gas costs will remain valid, as the worst-case scenario is unchanged
 
-## Reference Implementation
-
-TBD, first draft here:
-https://github.com/nerolation/execution-specs/tree/block-level-warming
-
 ## Security Considerations
 
 1. **Memory Usage**: The set of warm slots is still bounded by block gas limit / minimum gas cost per slot access, preventing DoS attacks through excessive memory usage.