# EIP-8037: State Creation Gas Cost Increase The core idea of 8037 is to make the state growth dependent on the gas limit. This allows for **increasing the gas limit without having to reprice state operations in every bump** ## Idea Imagine two operations: SSTORE, which creates 1 unit of state, and ADD. Both operations perform at 10MGas/s. With a 3s window of execution, we could have a 30M gas limit and someone could create 3 units of state per block in a max-sized block. Now we introduce a change (epbs) which increases the window from 3 to 5 seconds. With this, we are able to increase the gas limit to 50MGas. With this new limit, users can create 5 units of state per block. Now we introduce another change (BALs) which makes ADD and SSTORE much faster and they both run at 100MGas/s now. If we wanted to take advantage of the gains from this change, we would need to increase the gas limit to 500MGas. With this new limit, users can create 50 units of state per block. If we want to avoid increases in the state growth rate, we would either need to reprice the cost of storage whenever we change the gas limit or make the price of state growth dependent on the gas limit. ## Implementation Guide 8037 adds the following logic: - The EIP-7825 transaction limit of 16M gas is moved to the evm initialization phase. - `Gas` in the evm is initialized to `min(txGasLimit, 16MGas)` in order to limit burst resources to 16MGas - A new resource is added to the gas tracker called `StateGasReservoire` which contains gas that can ONLY be spent on state growth - `StateGasReservoire` is initialized to `gaslimit - Gas` - Every operation that can potentially create state (SSTORE, CREATE, CALL*,...) charges both normal `Gas` as well as `StateGas`.Currently the costs for execution and state growth are implicitly bundled in a single number - e.g. with current pricing, SSTORE would charge `2100 (ColdSload)` to normal gas and `20000` to StateGas. - `StateGas` now depends on the block gas limit. The higher the block gas limit, the more we charge for state growth. This allows to couple gas limit increases with keeping state growth constant. The cost is smoothed for a better UX. - `StateGas` is always charged first to the `StateGasReservoire`. If the `StateGasReservoire` is zero, it is charged to normal `Gas`. `StateGas` is only charged if new state is created, not if state is modified. - Logic for non-state creating operations will not change. - The GAS operation and the 63/64 rule will continue to work normally. The `StateGasReservoire` is fully passed to the subcall. ## Alternatives An alternative to 8037 would be a one time bump of the prices for all state-related operations. This one time bump would need to anticipate where the gas limit will end up though. Theoretically we can achieve at most with BALs (3x speedup of compute through parallelization) + Compute repricings (reprice at 60MGas/s) a throughput of 180MGas/s. At a 5s blocktime (EPBS) this would imply a **theoretical block limit of 900MGas** after Glamsterdam. This would imply that all storage operations would need to be **15x more expensive** if we want to keep current state growth. If we figure out after the fork though that a 900MGas block is not achievable and we can only get to 300MGas, all storage operations would be 3x overpriced. If we aimed for 300MGas and ended up at 900MGas, all storage operations would be 3x underpriced. A simple 10x bump of all storage costs would also run into the issue that a max size contract (24k or 32k) deployment would not fit in the current EIP-7825 transaction limit of 16M gas anymore. ## Advantages of 8037 - 8037 allows for gas limit increases (or decreases) without having to reprice storage operations - A small bump will either underprice or overprice storage operations, 8037 will always correctly price operations relative to the block limit. - Metering state growth separately from compute allows to limit the burst resources to 16M and still deploy bigger contracts. - Changes are limited and reusable for multidimensional gas in the future. - We can freely set the target state growth that we feel Ethereum can support (the specified default is 100GB/year, but is up to debate).