# State metering ## Background We are currently exploring options for how to extend the harmonization of state creation operations in EIP-8037 to ensure that an increase in the gas cost for state operations does not impede scaling. Specifically, the concern is that users may spend the majority of the gas on state creation after the cost increase, thus leaving less room for other operations under equilibrium. A solution to this problem is presented in [EIP-8075](https://github.com/ethereum/EIPs/pull/10689), where state creation is tracked separately, such that the EVM keeps track of `state_gas` and `regular_gas`. From the transactor's perspective, there is still only one gas, but the gas required for state creation may drift slowly, set to a rate of 0.1% per block. The `state_gas_per_byte` is set via the EIP-4844 mechanism to target some specific number of bytes per block. ## Outline Another option, which is explored here, is to rely on the EIP-8011 mechanism for updating the base fee. It uses the `max` of the gas consumption among all resources, and the base fee is thus set either from the `regular_gas` or the `state_gas`, depending on which that is used the most in the block. A target for the number of state bytes per block can still be set, letting the `state_gas_per_byte` be computed such that the target is reached if half the block´s gas limit is spent on state creation: `state_gas_per_byte = header.gas_limit // (TARGET_STATE_BYTES_PER_BLOCK * 2)` The exact gas cost for each opcode is then computed by multiplying `state_gas_per_byte` with the opcode bytes specified in [EIP-8037](https://ethereum-magicians.org/t/eip-8037-state-creation-gas-cost-increase/25694). The design relies on the gas limit to anchor the `state_gas_per_byte` calculation relative to available gas, and thus has some similarities to [EIP-8073](https://github.com/ethereum/EIPs/pull/10667). Just as in EIP-8073 and EIP-8075, this also means that the gas charged per state byte may drift from transaction submission to inclusion. The specification below provides further details. ## Analysis The targeting mechanism will be less precise than the one in EIP-8075. Two properties can be noted: * It is only when more state gas than regular gas is consumed that the target is reached (in the long run), due to the `max` operation. If more regular gas is consumed, state creation will instead be below the target. * When more state gas than regular gas is consumed, it is on the other hand regular gas that will be below the target. Still, given that a separation between resources is achieved, such that one resource can approach the target (half the gas limit) before crowding out the other, the mechanism achieves improved scaling relative to when both resources are metered together. It is thus positioned somewhere between the current EIP-8037 and EIP-8075. Exactly where in that range the mechanism is positioned depends on whether it turns out that `regular_gas` and `state_gas` actually are consumed approximately equally when the `TARGET_STATE_BYTES_PER_BLOCK` is set to a desirable level. A more elaborate option is to instead adjust the ranges (target/limit) of `regular_gas` and `state_gas`, relative to each other. However, at that point, complexity naturally increases. It would still be a fixed adjustment, not reaching the more precise targeting from the separate adaptive adjustment via the EIP-4844 mechanism. And if the range is set adaptively, we would just be mimicing EIP-8075 in a more complex and less satisfactory way. ## Specification What follows is a clean way to implement core properties of the design, leaving out parts already specified in EIP-8011. ### Parameters The `TARGET_STATE_BYTES_PER_BLOCK` is set at the upper end of the state creation that is acceptable. It functions as a cap, that the protocol guarantees will not be exceeded. But there is no guarantee that state creation comes close to this level. This will ultimately depend on how much demand there is for state creation, relative to the demand for other resources, at the price required for guaranteeing the set cap. In other words, a lower cap leads to a higher `state_gas_per_byte` at any given gas limit, which may then push down the number of state bytes created. The proposed level of 45 KB per block gives a cap of around 310 MiB of state created per day. | Constant | Value | - | - | | `TARGET_STATE_BYTES_PER_BLOCK` | `45_000` | The number of bytes assigned to each state operation follows EIP-8037. | Constant | Value | - | - | | `CREATE_BYTES` | `112` | | `CODE_DEPOSIT_BYTES` | `1` | | `NEW_ACCOUNT_BYTES` | `112` | | `STORAGE_SET_BYTES` | `32` | | `PER_EMPTY_ACCOUNT_BYTES` | `112` | | `PER_AUTH_BASE_BYTES` | `23` | ### Updating state gas costs for the block The `state_gas_per_byte` is set such that `TARGET_STATE_BYTES_PER_BLOCK` will be created at the given block gas limit when `state_gas` is the most consumed resource and thus metered for the base fee update. ```python def get_state_gas_per_byte(header: Header) -> int: return state_gas_per_byte = header.gas_limit // (TARGET_STATE_BYTES_PER_BLOCK * 2) ``` The block level gas cost for each state operation is computed as `GAS_STATE_OPERATION = state_gas_per_byte * STATE_OPERATION_BYTES`, where the harmonization of EIP-8037 is applied. For completeness, the function below specifies this for all operations: ```python def update_state_op_costs(state_gas_per_byte: int) -> None: GAS_CREATE = state_gas_per_byte * CREATE_BYTES GAS_CODE_DEPOSIT = state_gas_per_byte * CODE_DEPOSIT_BYTES GAS_NEW_ACCOUNT = state_gas_per_byte * NEW_ACCOUNT_BYTES GAS_STORAGE_SET = state_gas_per_byte * STORAGE_SET_BYTES PER_EMPTY_ACCOUNT_COST = state_gas_per_byte * PER_EMPTY_ACCOUNT_BYTES PER_AUTH_BASE_COST = state_gas_per_byte * PER_AUTH_BASE_BYTES ``` Thus, at the beginning of block processing, compute the gas cost of the state creation opcodes for the block: * `state_gas_per_byte = get_state_gas_per_byte(header)` * `update_state_op_costs(state_gas_per_byte)`