This EIP updates the gas cost of state-access operations to reflect Ethereum’s larger state and the consequent slowdown of these operations. It raises the base costs for GAS_STORAGE_UPDATE, GAS_COLD_SLOAD, and GAS_COLD_ACCOUNT_ACCESS and updates the access cost for EXTCODESIZE and EXTCODECOPY. The design coordinates with EIP-8032: before EIP-8032, parameters assume worst-case contract size; after EIP-8032, they assume worst-case up to ACTIVATION_THRESHOLD, with additional depth-based scaling beyond.
One of the goals would be to have these statefull tests performing at the same million gas per second target (or close enough), accounting for the added cost of state creation. Of course, SSTORE will not have the same million gas per second performance as SLOAD since it also includes a state creation cost component.
Also, state access operations should be harmonized with other compute operations. So these tests should also have similar million gas per second performances.
How does this EIP interact with 8037? Given that 7825 severely limits the amount of state that can be accessed atomically, increasing the cost of that state limits the amount even further. Using the 8037 “reservoir” mechanism in combination with the 8038 state access cost increases bills end users appropriately for the state that they touch and constrains the amount of state that a block can touch, without degrading the maximum transaction complexity and impacting dApp end users. Obviously the regular gas billed by each opcode would still need to represent the cost of proving that state access, but what I’m understanding from the text of the EIP is that the desire to increase the cost of state access comes from the cost of accessing state in a larger on-disk database, not the cost of proving that state against the root.
In fact, adopting the same state gas reservoir model as 8037 could improve transaction complexity.