# 8037 Spec Breakout Notes - Keeping static cpsb for bal-devnet-4, with the same value as bal-devnet-3, release ASAP - Doing option B, state diff at frame return, will be included in glamsterdam-devnet-1 ### Whiteboard photo ![IMG_2102](https://notes.ethereum.org/_uploads/ByU2kL6TZl.jpg) ### Dynamic vs. Fixed State Pricing The primary discussion centered on the complexity introduced by the current specification for dynamic cost per state byte, which is coupled to the block gas limit. * The Problem: Dynamic pricing forces the testing infrastructure to multiply test cases by the number of gas limit bands (e.g., 17 bands). This makes fuzzing difficult and significantly increases the testing matrix. Benchmarking is also severely impacted, as pre-states must be regenerated for every gas limit change. * The Options: 1. Keep the dynamic cost (current spec). 2. Fixed cost per byte (one-time repricing). 3. Fixed cost with scheduled bumps (EIP-style). 4. Fixed cost with ad-hoc mini-forks. * The Decision: The team agreed to drop the dynamic cost per state byte in favor of a fixed cost. This simplifies testing and benchmarking. While there was concern about "overshooting" or "undershooting" the state growth target with a fixed price, the consensus was that the complexity of dynamic pricing was too high. The team also agreed that gas limit increases should happen in small steps rather than one large jump, but the cost per byte will remain fixed within a fork. ### State Gas Accounting Timing The group discussed when state gas should be charged: mid-execution (current), at the end of a call frame, or at the end of a transaction. * The Problem: The current mid-execution method (Option 1) requires complex "refund" rules to move gas between the regular pool and the reservoir. These rules are growing in number and complexity with each devnet, making the spec unmaintainable. * The Options: 1. Mid-execution (current). 2. End of call frame (journaling). 3. End of transaction. * The Decision: Option 3 (End of transaction) was rejected due to severe security and UX issues; an untrusted sub-call could consume all state gas, causing the transaction to fail late and waste execution gas. The team agreed to move to Option 2: End of call frame. This aligns with how CREATE operates (paying for code size at the end of the frame) and removes the need for complex mid-execution refund logic. ### Byte Size Calculations The team briefly reviewed the byte counts used for state costs in the EIP. * New Storage Slot: There was debate on whether to charge for 32 bytes (value only) or 64 bytes (key + value). The consensus was to use 64 bytes to account for the key storage overhead, ensuring consistency with how storage is indexed. * Authorization (EIP-7702): The current cost is based on 23 bytes. Some argued this should include a 32-byte key overhead since clients store code in separate tables. However, to avoid breaking existing tests immediately, the team agreed to keep the 23-byte cost for now, acknowledging it may need adjustment for consistency later. ### Action Items * Implement Fixed Cost: Update client implementations to use a fixed cost per state byte for the upcoming DevNet 4 release (priority for benchmarking). * Implement End-of-Frame Accounting: Refactor the state gas accounting logic to charge at the end of the call frame (Option 2) for Glamsterdam DevNet 1 (target: Thursday). * Update Specs: Update the execution specs to reflect the fixed cost and the new accounting timing.