Update EIP-7999: add data and state resources, simplify gas accounting

[misilva73]

Summary

Expands EIP-7999 from three resource dimensions to four, adding a data resource and a state-growth resource alongside execution and blob gas.

Changes

• Data resource (replaces standalone calldata): priced from EIP-8131 content bytes (DATA_GAS_PER_CONTENT_BYTE = 16) and EIP-8279 BAL bytes; flat DATA_GAS_LIMIT = 60M; drops EIP-7623 floor pricing; renames CALLDATABASEFEE → DATABASEFEE (0x4b).
• State resource: new separately-priced dimension reusing EIP-8037 metering with its own base fee; no per-block limit (target only), no EIP-7918 anchor; adds STATEBASEFEE (0x4c).
• Gas accounting: extends gas vectors 3→4 dims; reworks get_gas_limits; adopts EIP-2780 intrinsic basis and EIP-7825 per-tx cap; data & state treated as unconditional under EIP-7805.
• Header: requires adds EIP-2780, 7623, 7702, 7706, 7825, 7928, 8037, 8131, 8279.

Several constants remain TBD.

[eth-bot]

File EIPS/eip-7999.md

Requires 1 more review from Authors: @anderselowsson, @vbuterin

[github-actions]

The commit 9ec9e16 (as a parent of f90869f) contains errors.
Please inspect the Run Summary for details.

[albertoblue87-netizen]

Hecho

[anderselowsson]

Thanks for the PR!

Concerning having no limit for state. The potential downside is that someone can buy big chunks of state in a single tx/block at a fixed price. At the same time, there are benefits from a CR perspective (FOCIL inclusion check). A high limit such as 32x can also provide good CR, but of course no limits excludes state completely from any issues there. Can we quantify the implicit limits due to coupling with other resources, and take it from there?

Using the 120 GiB/year target (~49 kB per block) from EIP-8037, and a 600M execution gas limit, I get the following target/limit ratios:

• including EIP-7702 authorizations to empty accounts: 12,041 execution gas for 143 state bytes, i.e. 145x the state target?
• excluding EIP-7702 authorizations: value-bearing CALL to a non-existent account gives 11,000 execution gas for 120 state bytes, i.e. 133x the state target?
• SSTORE zero-to-nonzero gives 13,000 execution gas for 64 state bytes, i.e. 60x the state target?

The outcome will then drift with the execution gas limit. Does it make sense? And then for contract creation we instead need to compare with the data resource. For max-size contracts, there is roughly 1-to-1 in terms of bytes. So at a 6MB data limit that is about 123x the state target. Empty contracts are 120 state bytes per 28 data bytes, so as a data-only bound, assuming enough execution gas, at a 6MB data limit that gives about 525x the state target? I see the PR put the implicit data limit a little lower though.

EIP-7999 would seem like a possible opportunity to move away from gas units by the way. We could clean up by going to bytes directly, although I appreciate there may be complexities associated with this.

The second point is about setting transaction resource limits. As previously discussed and you also have noted, the idea behind 7999 is to have separate resource limits indicated by the user as we move into the EVM. We then pursue universal overflow for facilitating subcalls. This means that we would have to move away from the state gas reservoir in its present form, so it should not be adopted. Specifically, we are not pursuing "Aggregate EVM gas" as defined in the EIP spec for the baseline implementation.

[albertoblue87-netizen]

Listo