This is an opinion piece from myself and @CPerezz
In this opinion piece, we discuss how EIPs proposed for Hegotá can impact our current work on state. It thus focuses on those EIPs with a direct impact on state management, state access or the trie migration.
The state roadmap has two goals in our view:
- Keep state manageable to hold, access and serve as throughput rises.
- Prepare a safe transition to a new state trie.
Hegotá can help by keeping state growth within a clear budget, keeping Frames’ new state bounded, resolving some legacy state issues and, if fork timing allows, improving access to existing state through Block Access List sidecars. It should defer changes whose benefit is small today but whose cost would show up during the migration or in increased state growth.
Hegotá follows Glamsterdam’s introduction of BALs (EIP-7928) and state gas (EIP-8037); the PBT migration is expected later, in fork I*.
Quick primer on PBT and the migration
The Partitioned Binary Tree (PBT), specified in EIP-8297, replaces Ethereum’s current state trie layout with a binary structure designed for smaller proofs and more efficient proving. It separates different kinds of state into zones and stores contract code by its content, allowing identical code to be shared.
EIP-8347 proposes an offline migration: clients convert the state at a finalized anchor block and then use block access lists (BALs) to replay changes until the new tree catches up. The PBT activation fork later switches the state root from MPT to PBT. This avoids a full conversion at the activation boundary, but makes complete and reliably available BALs a migration dependency.
EIP-8025’s optional execution proofs tilt the tradeoff further toward this offline approach. An online migration would otherwise have to keep proof generation working against both trees through the transition. This is not an argument for or against EIP-8025, but it affects the migration design.
State growth control: observe, then choose
EIP-8037 introduces a separate state-gas dimension, priced via a standardized cost per state byte (CPSB), so that all state-creating operations charge proportionally to the bytes they write and state growth is bounded. This EIP is scheduled for Glamsterdam.
After Glamsterdam activates, the first step is to observe how demand for state creation responds to EIP-8037 and compare state-gas and execution-gas utilization with their targets. That evidence determines whether Hegotá should modify CPSB or the state-gas mechanism at all. There are three possible scenarios:
-
State and execution demand are mismatched: one resource’s utilization remains far from its target while the other resource constrains the block. This is an EIP-8037 failure mode. In this case, we should adopt EIP-8372, which performs a one-time recalibration of
CPSBand scales the raw state-gas limit at the hard fork boundary, bringing state and execution capacity back into balance. -
Demand is balanced, but Hegotá raises the block gas limit: in this case, we should adopt EIP-8368 to re-derive
CPSBfor the higher limit and keep state growth on target without changing the mechanism. -
Demand is balanced and the block gas limit stays unchanged: in this case, we should make no Hegotá update and retain EIP-8037’s existing parameters.
EIP-8368 and EIP-8372 should therefore remain alternative contingency paths until there is enough post-Glamsterdam utilization data. The decision should be evidence-gated and dependent on the final gas limit target for the fork.
Frames need a bounded state footprint
EIP-8141 introduces frame transactions as Hegotá’s native account abstraction design. Programmable validation must read only a bounded slice of state so that validity-checking nodes, including future inclusion-list builders, do not need to hold the whole state. This is why we should push back on ERC-20 fee sponsorship as a Frames feature: it would make validity depend on arbitrary token storage and defeat that constraint.
Two Frame extensions add new state types. EIP-8250 adds keyed nonces, and EIP-8272 adds a rolling window of recent application state roots. Both can begin as regular storage in a system contract and move into their own PBT zone later. This only works if demand stays bounded, especially for keyed nonces, where each new key adds a permanent slot. Privacy pool usage is the best current proxy, and nullifier growth looks feasible so far based on this Dune dashboard. We should keep watching it as adoption grows.
Resolve the legacy accounts
EIP-8253 addresses a small set of legacy accounts left over from before Spurious Dragon: accounts with storage but no code and a zero nonce. Hegotá should remove this account shape before the PBT migration. EIP-8253 does so by setting the nonce of 28 accounts to 1, while an alternative would be to clear their 129 storage entries. The nonce bump is the smaller and simpler transition; clearing the storage removes more state. We should resolve the anomaly in Hegotá, choosing the exact mechanism after verifying the account list and comparing the transition complexity.
Add BAL as sidecars if fork timing allows
EIP-7928’s Block Access List (BAL) contains every account, storage slot, and code or balance/nonce change a block touches. EIP-8146 moves BAL delivery out of the payload and sends it early on its own channel, giving clients more time to prefetch state and compute the state root.
This is a good improvement if it does not delay the fork. Before including it, we should benchmark the execution benefit of one additional second of prefetching and state-root calculation.
State tiering can wait
Today’s client databases weren’t built for multi-terabyte state. A possible fix is hot/cold separation: keep hot state in the live database and push cold state to flat files on cheaper media. Measurements show that about 94% of storage writes hit state from the last 30 days, and that the top 1% of accounts absorb 96–98% of reads (Hot-Cold Storage Separation in Practice, The Anatomy of Ethereum’s State Access). Cold state should target HDDs, since big, slow, cheap disks need a job.
EIP-8188 records the last block that wrote to each account and storage slot, providing a clean signal for this split. We will likely want it eventually, but it puts write-recency into state while the current PBT leaf format does not represent it. Adding it before the migration would mean resolving that gap and carrying more data through the conversion, while its main operational benefit arrives only as state approaches the TB mark.
We should therefore revisit EIP-8188 after the trie migration and keep only low-priority exploration going for now. More work is also needed on serving cold state from HDDs without making access too expensive.
SETCODEFROM subsumes SETDELEGATE
EIP-7819 and EIP-8298 both let an EIP-7702 delegated account clear its delegation and become a smart account. EIP-8298’s SETCODEFROM also lets an account reuse code already deployed elsewhere.
That reuse avoids writing duplicate bytecode. EIP-8037’s CPSB charges for bytes written even when identical code exists, while PBT deduplicates those bytes without giving the deployer a discount. SETCODEFROM skips the write entirely. Roughly 62% of deployed contracts reportedly duplicate existing bytecode, and this saving would remain after the migration.
Hegotá does not need to include delegation clearing. But if it does, it should choose EIP-8298: it covers EIP-7819’s use case and reduces duplicate code deployment, whose cost will be more visible after EIP-8037.
SELFDESTRUCT and ephemeral storage
EIP-4758 removes the only account-deletion case left by EIP-6780: an account created and self-destructed in the same transaction. Removing this case is neutral to PBT or its migration, since these accounts do not exist in the pre-state and do not survive into the post-state.
The plan to replace SELFDESTRUCT is EIP-8360’s TCREATE, a CREATE2 variant that deploys a contract whose code, nonce, and storage are all removed at the end of the transaction, leaving only its balance behind. Inside a TCREATEd contract, SLOAD/SSTORE are priced and behave like TLOAD/TSTORE.
There are some use-cases that would benefit from this ephemeral storage layer, however, current usage is limited. In a sample covering one month of blocks, we see an average of roughly 1,500 accounts per day created and self-destructed in the same transaction. There are two patterns of usage in this sample, namely, internal wallet maangement for centralised exchanges or NFT marketplaces and laundering from scams. At current usage, and counting only 120 bytes per account while ignoring storage, this deletion avoids roughly 62 MiB of state growth per year, which is fairly small. Thus, this is not a clear win and likely not a priority for now.