Update EIP-8141: Add explicit second dimension for state gas to frames by lightclient · Pull Request #12062 · ethereum/EIPs

lightclient · 2026-07-31T21:01:33Z

This splits gas_limit field in the frame into:

execution_gas_limit
state_gas_limit

There are important distinctions between the two, but most notable is that execution gas continues to (generally) be a callframe level concept while state gas is treated as a frame level concept.

Hopefully this illuminates the remaining edge cases around frames and 2780, 7623, 7708, 7825, and 8037!

eth-bot · 2026-07-31T21:01:56Z

✅ All reviewers have approved.

github-actions · 2026-07-31T21:20:45Z

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

jochem-brouwer

Saw this PR and gave it a read, some comments.

Allowing state gas introspection to other (earlier) frames means we can (in some specific cases) verify if such frame created a slot. This thus adds a subset of journal introspection to the EVM.
We could fix this by pinning the state gas used of previous frames to the value at the start of the currently executing frame. Any refills can thus not be measured by the EVM, while they are accounted for in the end.

The other thing is that not allowing state gas to be paid with execution gas also means that deep call frames can exhaust all state gas and therefore not allow later operations to create state (as this would attempt to put state gas below 0). This is something to think about, it might be the same argument for sending all your gas to untrusted accounts, but this definitely is something which "rogue contracts" can use to attack. The only way to then regain the "rights" to create state is to revert the current frame and therefore rollback the state creation by the rogue account.
Note that in EIP-8037 execution gas would pay for it if the state gas / state reservoir is empty.
Also note that we now have two gas journaling modes, one for frame txs and the other for non-frame txs.

Lemme know if you have some questions if I made a comment which is unclear 😄 👍

Exciting work!! 😄 🚀

jochem-brouwer · 2026-08-01T01:12:53Z

+| `STANDARD_TOKEN_COST` | `4` | [EIP-7623](./eip-7623.md) |
+| `TOTAL_COST_FLOOR_PER_TOKEN` | `10` | [EIP-7623](./eip-7623.md) |


jochem-brouwer · 2026-08-01T01:18:25Z

 [chain_id, nonce, sender, frames, signatures, max_priority_fee_per_gas, max_fee_per_gas, max_fee_per_blob_gas, blob_versioned_hashes]

-frames = [[mode, flags, target, gas_limit, value, data], ...]
+frames = [[mode, flags, target, execution_gas_limit, state_gas_limit, value, data], ...]


What happens if we introduce another gas dimension? How would we pack this in frame txs?

Is it necessary to split gas limit in these two dimensions? I would initially say that this is not necessary: all gas is execution gas. If a state operation happens and it gets cancelled, then this moves into the reservoir. However, not allowing this splitting means that a tx which has an intended split of execution/state gas does not fit in the block anymore because one (or both) of the gas dimensions would exceed the block gas limit. So I guess there is indeed reason to add this feature here.

Only worried if we go to multidimensional gas, then this is not forward compatible, and then we need to introduced "typed frame transactions" 😜

jochem-brouwer · 2026-08-01T01:19:25Z

    assert frame.flags < 8
    assert frame.target is None or len(frame.target) == 20
-    assert frame.gas_limit <= 2**64 - 1
+    assert frame.state_gas_limit <= 2**64 - 1


There is no check for execution_gas_limt

Suggested change

assert frame.state_gas_limit <= 2**64 - 1

assert frame.execution_gas_limit <= 2**64 - 1

assert frame.state_gas_limit <= 2**64 - 1

Ah ok, maybe this is not necessary, because this is implicitly checked by the EIP-7825 check?

jochem-brouwer · 2026-08-01T01:23:34Z

        assert i + 1 < len(tx.frames)            # must not be last frame
        assert tx.frames[i + 1].mode != VERIFY   # batches never contain VERIFY frames
+
+# Intrinsic gas must fit the EIP-7825 transaction cap.


Suggested change

# Intrinsic gas must fit the EIP-7825 transaction cap.

# Intrinsic and execution gas must fit the EIP-7825 transaction cap.

jochem-brouwer · 2026-08-01T01:29:33Z

-    - Logs emitted by frames that executed before the failure are discarded together with their state changes when the batch is unrolled. Those frame receipts retain their execution status and gas used, with empty logs.
-    - Since skipped frames are not executed, the gas value allotted to them is refunded at the end of the transaction.
+    - Logs emitted by frames that executed before the failure are discarded together with their state changes when the batch is unrolled. Change to any frame receipt's `state_gas_used` during the batch is reverted, as the batch's state modifications are reverted. Executed frame receipts retain their execution status and execution gas used, with empty logs and zero state gas used.
+    - Since skipped frames are not executed, the gas and state gas allotted to them is refunded at the end of the transaction.


The word "refunded" here is ambiguous. Is this an EIP-3529 refund (thus capped at 20%?)

If not the case refunded->returned?

jochem-brouwer · 2026-08-01T03:20:43Z

+| **Total**                         | 141   |

-Notes: Nonce assumes < 65536 prior sends. Fees assume < 1099 gwei. Validation frame target is 1 byte because target is `tx.sender`. Validation gas assumes <= 65,536 gas. Validation frame value is zero. Execution frame target is encoded directly as the destination address. Execution frame value assumes a compact 5-byte encoding. The execution frame data is empty for a plain ETH transfer. The signature is a secp256k1 entry with empty `msg` using a 65-byte ECDSA signature. Blob fields assume no blobs (empty list, zero max fee).
+Notes: Nonce assumes < 65536 prior sends. Fees assume < 1099 gwei. Validation frame target is 1 byte because target is `tx.sender`. Validation gas assumes <= 65,536 gas. Validation frame value is zero. Execution frame target is encoded directly as the destination address. Execution frame value assumes a compact 5-byte encoding. The execution frame data is empty for a plain ETH transfer. The signature is a secp256k1 entry with empty `msg` using a 65-byte ECDSA signature. Blob fields assume no blobs (empty list, zero max fee). State gas limits are zero, assuming the destination exists; a transfer that creates a new account instead requires a 183,600 state gas budget on the execution frame (three additional bytes).


Suggested change

Notes: Nonce assumes < 65536 prior sends. Fees assume < 1099 gwei. Validation frame target is 1 byte because target is `tx.sender`. Validation gas assumes <= 65,536 gas. Validation frame value is zero. Execution frame target is encoded directly as the destination address. Execution frame value assumes a compact 5-byte encoding. The execution frame data is empty for a plain ETH transfer. The signature is a secp256k1 entry with empty `msg` using a 65-byte ECDSA signature. Blob fields assume no blobs (empty list, zero max fee). State gas limits are zero, assuming the destination exists; a transfer that creates a new account instead requires a 183,600 state gas budget on the execution frame (three additional bytes).

Notes: Nonce assumes < 65536 prior sends. Fees assume < 1099 gwei. Validation frame target is 1 byte because target is `tx.sender`. Validation gas assumes <= 65,536 gas. Validation frame value is zero. Execution frame target is encoded directly as the destination address. Execution frame value assumes a compact 5-byte encoding. The execution frame data is empty for a plain ETH transfer. The signature is a secp256k1 entry with empty `msg` using a 65-byte ECDSA signature. Blob fields assume no blobs (empty list, zero max fee). State gas limits are zero, assuming the destination exists; a transfer that creates a new account instead requires a ``STATE_BYTES_PER_NEW_ACCOUNT × CPSB = 183,600` state gas budget on the execution frame (three additional bytes).

(the 183,600 should be defined as a constant somewhere, now it is a magic number for readers not deep in EIP-8037)

jochem-brouwer · 2026-08-01T03:21:53Z

 | Execution frame: target           | 20    |
-| Execution frame: gas              | 1     |
+| Execution frame: execution gas              | 1     |
+| Execution frame: state gas        | 1     |


jochem-brouwer · 2026-08-01T03:24:15Z

+| **Total**                         | 141   |

-Notes: Nonce assumes < 65536 prior sends. Fees assume < 1099 gwei. Validation frame target is 1 byte because target is `tx.sender`. Validation gas assumes <= 65,536 gas. Validation frame value is zero. Execution frame target is encoded directly as the destination address. Execution frame value assumes a compact 5-byte encoding. The execution frame data is empty for a plain ETH transfer. The signature is a secp256k1 entry with empty `msg` using a 65-byte ECDSA signature. Blob fields assume no blobs (empty list, zero max fee).
+Notes: Nonce assumes < 65536 prior sends. Fees assume < 1099 gwei. Validation frame target is 1 byte because target is `tx.sender`. Validation gas assumes <= 65,536 gas. Validation frame value is zero. Execution frame target is encoded directly as the destination address. Execution frame value assumes a compact 5-byte encoding. The execution frame data is empty for a plain ETH transfer. The signature is a secp256k1 entry with empty `msg` using a 65-byte ECDSA signature. Blob fields assume no blobs (empty list, zero max fee). State gas limits are zero, assuming the destination exists; a transfer that creates a new account instead requires a 183,600 state gas budget on the execution frame (three additional bytes).


What is this compact 5 byte encoding? With 5 bytes I can send slightly more than 0.000001 ETH 🤔

jochem-brouwer · 2026-08-01T03:25:54Z

 | Execution frame: flags            | 1     |
 | Execution frame: target           | 20    |
-| Execution frame: gas              | 1     |
+| Execution frame: execution gas              | 1     |


255 gas is not a lot, but I guess that fallback/receive methods consume much less, or have some "tricks" to ensure that receiving ether is cheap in gas units?

jochem-brouwer · 2026-08-01T03:27:46Z

+| **Total additional**                 | 150   |

-Notes: Sponsor can read info from other fields. ERC-20 transfer call is 68 bytes.
+Notes: Sponsor can read info from other fields. ERC-20 transfer call is 68 bytes. State gas fields assume no new storage slots are created; an ERC-20 transfer into a fresh balance slot requires a 97,920 state gas budget (three additional bytes).


This 97,920 should also be referenced to EIP-8037's New slot constant.

jochem-brouwer · 2026-08-01T04:17:58Z

Also, have to admit, this EIP is super well written already. Also nice to see how quickly this is changing, and great to see that the spec is made Glamsterdam-ready now! 😍

Helkomine

assert max(
frame_tx_intrinsic_gas + total_frame_execution_gas,
calldata_floor_gas,
) <= TX_MAX_GAS_LIMIT

As I understand it, frames are equivalent to individual transactions that are grouped together, so static analysis capabilities are still maintained. Therefore, shouldn't we only apply limits per frame instead of across all frames?

lightclient added 5 commits July 29, 2026 14:44

wip

0a3e0ac

nits

5aa3fdd

more nits

d338ad3

simplify rationale

d990f9a

nit

9c0b23f

github-actions Bot added c-update Modifies an existing proposal s-draft This EIP is a Draft t-core labels Jul 31, 2026

eth-bot changed the title ~~Add explicit second dimension for state gas to frames~~ Update EIP-8141: Add explicit second dimension for state gas to frames Jul 31, 2026

github-actions Bot added the w-ci Waiting on CI to pass label Jul 31, 2026

jochem-brouwer reviewed Aug 1, 2026

View reviewed changes

Helkomine reviewed Aug 1, 2026

View reviewed changes

		\| `STANDARD_TOKEN_COST` \| `4` \| [EIP-7623](./eip-7623.md) \|
		\| `TOTAL_COST_FLOOR_PER_TOKEN` \| `10` \| [EIP-7623](./eip-7623.md) \|

	assert frame.state_gas_limit <= 2**64 - 1
	assert frame.execution_gas_limit <= 2**64 - 1
	assert frame.state_gas_limit <= 2**64 - 1

	# Intrinsic gas must fit the EIP-7825 transaction cap.
	# Intrinsic and execution gas must fit the EIP-7825 transaction cap.

	\| Execution frame: state gas \| 1 \|
	\| Execution frame: state gas \| 3 \|

Uh oh!

Conversation

lightclient commented Jul 31, 2026

Uh oh!

eth-bot commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jul 31, 2026

Uh oh!

jochem-brouwer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jochem-brouwer commented Aug 1, 2026

Uh oh!

Helkomine left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

eth-bot commented Jul 31, 2026 •

edited

Loading

Helkomine left a comment •

edited

Loading