Running an Ethereum node allows users to independently verify what is happening on the network instead of relying entirely on a third-party service. However, as Ethereum attracts more users, applications, and smart contracts, the amount of data handled by these nodes continues to increase.

This raises the challenge of enabling Ethereum nodes to verify the blockchain without storing the complete data of every smart contract.

What Problem Is EIP-8268 Trying to Solve?

EIP-8268 offers one possible part of the solution. Formally titled “Storage Roots in Block Access Lists,” the proposal would add a small but important piece of information to every modified account recorded in a block. This information could help a new type of Ethereum node verify network updates while storing only the contract data it needs.

EIP-8268 depends on another proposal called EIP-7928, which introduces Block-Level Access Lists. Its future therefore depends heavily on whether the wider Block Access List design is successfully implemented.

Ethereum’s state includes the ETH balance of every account, its transaction count, the code used by smart contracts, and the information stored inside those contracts. Token balances, liquidity positions, lending records, NFT ownership, and governance votes are all examples of information that may form part of the state.

Ethereum nodes store and process this information so they can independently check that new blocks follow the network’s rules. This is an important part of Ethereum’s decentralization because users do not need to trust a single company’s record of the blockchain.

The challenge is that Ethereum’s state keeps expanding as new accounts and applications are created. A node maintaining the latest network state may have to store data belonging to thousands of applications it never uses.

For example, a node operated for a decentralized exchange may mainly need the exchange’s contracts, liquidity pools, supported tokens, and price feeds. It may not need immediate access to the complete storage of every gaming, lending, identity, and NFT application on Ethereum. This has led Ethereum researchers to explore a concept called partial statefulness.

A partially stateful node would maintain Ethereum’s main account records but store detailed contract data only for selected applications. An exchange-specific node might retain the complete state of the exchange it supports while avoiding the storage of unrelated applications. This could reduce storage requirements and make specialized nodes easier to operate.

Ethereum has already started reducing some data burdens through features such as Partial History Expiry, which allows supported clients to remove certain historical data that is no longer required for everyday validation.

However, history expiry and partial statefulness address different problems. History expiry deals with old blockchain records, while partial statefulness concerns the latest data stored inside accounts and smart contracts.

Both ideas form part of Ethereum’s wider effort to make node operation more sustainable. Similar scalability concerns have influenced major upgrades such as Pectra and the ongoing development of Glamsterdam.

Partial statefulness, however, creates a major verification problem. If a node does not possess all the information stored by a contract, it may be unable to verify the contract’s final state after that contract changes. EIP-8268 attempts to provide the missing information needed to address this problem.

Why Block Access Lists Are Not Enough

EIP-8268 builds on EIP-7928: Block-Level Access Lists. A Block-Level Access List, commonly called a BAL, is a record showing which accounts and storage locations were accessed during the execution of an Ethereum block. It also records the account information that changed during that block.

A BAL can be compared to a report created after someone updates files in a large record room. The report may show which files were opened, which records were read, which pages were changed, and the new values added to those pages. This makes it easier for another person to understand what happened without searching through the entire record room.

A Block Access List performs a similar function for Ethereum clients. It shows which accounts and contract storage locations were used while processing a block. It can also record changes involving account balances, transaction counts, contract code, and individual storage values.

This information could help Ethereum clients prepare required data earlier, perform some operations in parallel, and calculate state updates more efficiently. EIP-7928 is not a minor supporting proposal. Block-Level Access Lists were selected as the execution-layer headliner for Glamsterdam.

EtherWorld’s report on the finalized Glamsterdam headliners explains why BALs are considered important for auditability, parallel data access, and future transaction-processing improvements. The BAL specification has continued evolving through Ethereum core developer discussions. During ACDE Call #218, developers discussed retaining both read and write information in Block Access Lists despite the additional block-size cost. The information could be valuable for auditors and may enable future client optimizations.

Imagine that a smart contract contains 10,000 stored values and a block changes only two of them. The BAL can show the two values that changed. But a partial node may not possess the remaining 9,998 values. Because the node does not have the contract’s complete storage, it cannot calculate the contract’s final fingerprint by itself.

Ethereum’s main record for an account includes its balance, transaction count, code information, and storage root. A Block Access List already provides information about balance, transaction count, code, and individual storage changes. The storage root is the missing piece.

Without it, a partial node cannot completely rebuild the modified account record. This prevents it from updating Ethereum’s wider account structure and checking whether the final network state matches the result published in the block. EIP-8268 proposes adding this missing fingerprint directly to the Block Access List.

How EIP-8268 Works

EIP-8268 would add the final storage root to the BAL entry of every account whose state changed during a block. Returning to the record-room example, the current Block Access List identifies the pages that changed. EIP-8268 would also attach the final digital fingerprint of the complete file.

The partial node would not suddenly receive all the pages it chose not to store. However, it could use the supplied fingerprint to rebuild the account’s main record and continue checking Ethereum’s broader state.

• Step 1: The process begins when an Ethereum execution client processes all the transactions included in a block. These transactions may transfer ETH, update contract storage, deploy smart contract code, or interact with decentralized applications.
• Step 2: While processing the block, the client creates a Block Access List. The list records the accounts and storage locations that were accessed and identifies which account details changed. After all transactions have been completed, the client calculates the final storage root of every modified account. EIP-8268 requires this final storage root to be added to the account’s BAL entry.
• Step 3: Other Ethereum clients can then check the information. A fully stateful node possesses the complete storage of the account. It can calculate the storage root independently and compare its result with the value supplied in the Block Access List.
• Step 4: A partial-state node may not possess the complete storage. It therefore cannot calculate the root using all the underlying information. However, it can use the supplied root when reconstructing the modified account record. Once the account records have been updated, the node can calculate Ethereum’s wider state root and compare it with the result published in the block.

This approach is part of Ethereum’s wider effort to make nodes more sustainable. Ethereum is also developing ways to reduce unnecessary historical storage, as explained in EtherWorld’s report on History Expiry in the Fusaka roadmap.

History expiry removes older blockchain records that regular nodes may no longer need. EIP-8268 addresses a different part of the storage problem by focusing on the latest contract state. EIP-8268 does not mean a partial node can answer every possible question about a contract it does not store.

Key Technical Changes Proposed by EIP-8268

EIP-8268 does not introduce a new transaction type, wallet feature, or Ethereum Virtual Machine opcode. Its main change is the addition of a new field to the Block Access List structure introduced by EIP-7928.

1. One New BAL Field

Under EIP-7928, the BAL entry for an account can record its address, storage changes, storage reads, balance changes, transaction-count changes, and code changes. EIP-8268 would add one more item, i.e., the account’s storage root after the complete block has been processed.

2. Is the Account Modified?

The new storage-root field would only be required when an account’s state actually changes. An account may be accessed during execution without being modified. A smart contract might read another account’s balance, for example, without changing that account. In this situation, the additional storage root would not be required.

This restriction prevents the proposal from adding unnecessary information to every account mentioned in a Block Access List. The proposal also introduces a special rule for accounts with empty storage.

Many accounts modified in an Ethereum block are ordinary user accounts. A sender may have its transaction count updated, while a recipient may have its ETH balance updated. These accounts often have no contract storage.

3. Choose the Correct Storage Root

Ethereum already has a standard 32-byte value representing empty storage. Repeating the same long value for every account with no storage would unnecessarily increase the size of the BAL. EIP-8268 therefore proposes using a shorter empty value for these accounts. Ethereum clients would understand that this short representation means the account’s final storage is empty.

The rule depends on whether an account’s storage is empty after the block, not on whether the account is described as a user account or smart contract. This distinction is important because the line between user accounts and smart contract accounts has become more flexible. EIP-7702, activated through Pectra, allows regular Ethereum accounts to temporarily use smart contract functionality.

EtherWorld’s overview of the top Ethereum and blockchain updates of 2025 explains how EIP-7702 introduced features such as transaction batching, sponsored gas, and session keys. Readers can also explore its effect on wallet development through EtherWorld’s analysis of ERC-7779 and wallet interoperability.

EIP-8268’s empty-storage rule can therefore cover ordinary accounts, newly created contracts without stored information, contracts whose storage has been cleared, and EIP-7702 delegated accounts. The proposal also establishes strict validation rules. If an account has non-empty storage, its BAL entry must contain the correct final storage root. If the account has empty storage, it must use the required shorter representation.

A block would be invalid if it contained an incorrect storage root or used the wrong representation for empty storage. These rules ensure that all Ethereum clients produce the same Block Access List for the same block result. This is essential because clients must agree on the data used to validate blocks.

Since EIP-8268 changes the BAL structure, it is not backwards compatible. It would need to be activated through an Ethereum network upgrade, commonly referred to as a hard fork. One client or application could not introduce the change independently. Readers can follow proposal status changes and upgrade decisions through EtherWorld’s guide to tracking Glamsterdam on EIPsInsight.

Benefits, Risks, & Open Questions

Benefits

The primary benefit of EIP-8268 is that it could make partial-state Ethereum nodes more practical.

• Reduced Storage Requirements An application-specific node could store the complete data required by one application instead of retaining the storage of every contract on Ethereum. This may reduce storage requirements for developers, RPC operators, infrastructure providers, and organizations that only need access to a defined part of the network.

• Specialized Ethereum Nodes For example, one node could focus on decentralized exchange contracts, while another stores lending protocols. Other nodes could specialize in NFT marketplaces, games, stablecoins, or frequently requested public data.
• New RPC Service Models This approach could support new RPC service models. Providers might announce which applications or portions of Ethereum’s state they maintain. Users and applications could then direct requests to the appropriate provider.
• Geographic Distribution Partial-state nodes could also make it easier to copy important contract data across multiple geographic regions. An application may be able to place relevant state closer to its users without copying Ethereum’s entire state database to every server. Ethereum has already demonstrated that lowering node-storage requirements can offer operational benefits. EtherWorld’s guide to enabling Partial History Expiry on major Ethereum clients explains how Geth, Besu, and Nethermind can reduce the amount of historical information stored locally.
• Additional Node Use Cases The EIP-8268 discussion also identifies possible use cases involving application-specific RPC services, distributed state storage, synchronization support, and FOCIL includer nodes. FOCIL, or Fork-Choice Enforced Inclusion Lists, is being explored as a way to improve Ethereum’s resistance to transaction censorship.

EtherWorld’s summary of ACDE Call #216 covers how client teams evaluated BAL, FOCIL, gas repricing, and other possible Glamsterdam priorities.

Risks

However, EIP-8268 does not solve every problem associated with partial statefulness.

• Limited Independent Verification A storage root is only a fingerprint of the underlying information. A partial node that does not possess a contract’s complete storage cannot independently recreate that fingerprint from every stored value. The node can use the supplied root to rebuild the account record, but it may still depend on fully stateful nodes, cryptographic proofs, committees, or future verification systems for stronger security guarantees.
• Dependence on External Data Providers Partial nodes may also become dependent on external data providers. If a node receives a request for information it has not stored, it must find another operator that possesses the missing data.

• Effects on Decentralization It could also have mixed effects on decentralization. Reducing storage requirements may allow more people to operate specialized Ethereum nodes. At the same time, smaller operators could become dependent on a limited number of large providers for data they do not retain.
• Larger Block Access Lists EIP-8268 would also increase the size of Block Access Lists. Accounts with empty storage would use the shorter representation, but modified smart contracts with stored data would still add a complete storage root. Ethereum client teams must test how much additional bandwidth this creates under normal and demanding block conditions.
• Client Disagreement Finally, all Ethereum execution clients must interpret the new rules in exactly the same way. A disagreement over when the storage root is required or how empty storage is represented could cause clients to disagree on block validity.

These concerns do not necessarily make EIP-8268 unsafe. They demonstrate that it is one component of a wider partial-state system that still needs research and testing.

Open Questions

Ethereum has faced a similar availability question with history expiry. If ordinary nodes stop retaining older information, another system must continue making it accessible. EtherWorld’s coverage of ACDE Call #208 discusses the Portal Network as one possible decentralized source for historical data that regular nodes no longer store.

Partial statefulness may eventually require a comparable discovery and retrieval system for missing contract state.

Implementation Status & What Comes Next

As of July 18, 2026, EIP-8268 remains in Draft status. It has not been approved for Ethereum mainnet, and no network upgrade has been formally confirmed as its activation target. The proposal depends on EIP-7928, which is currently in Review status. EIP-7928 introduces the Block-Level Access List structure that EIP-8268 would extend.

If the underlying BAL design changes, EIP-8268 may also need to be updated. If EIP-7928 is not adopted, EIP-8268 would have no protocol mechanism to extend. This dependency is especially important because EIP-7928 is the execution-layer headliner for Glamsterdam. Client implementation and interoperability work for that part of the upgrade are being organized around the stability of BALs.

According to the proposal’s Ethereum Magicians discussion, an experimental Geth implementation has been developed using EIP-7928. It can reportedly store selected contract state, process BAL information, respond to chain reorganizations, and return clear errors when users request data belonging to contracts the node does not track.

EtherWorld’s ACDE Call #237 summary covered BAL-related edge cases involving EIP-7702, while its ACDE Call #238 coverage provides more context on Ethereum’s evolving execution-layer priorities. Readers can also follow broader client and devnet progress through EtherWorld’s State of Upgrade: Glamsterdam Edition, which tracks client stability, testing progress, networking changes, and implementation dependencies.

Before EIP-8268 could reach mainnet, it would require further specification review, continued progress on EIP-7928, implementations across multiple execution clients, interoperability testing, bandwidth analysis, and broader examination of the partial-node security model.

The proposal is not a complete solution to Ethereum’s growing state. It does not guarantee that missing contract data will always remain available, and it does not give a partial node all the capabilities of a traditional fully stateful node. Still, EIP-8268 provides a possible building block for a future in which every Ethereum node may not need to store everything.

To promote your Web3 articles, events, and projects, you may reach out anytime via EtherWorld PR for submissions and collaboration.

Related Articles

1. Glamsterdam Headliners Finalised
2. Tracking the Glamsterdam Upgrade on EIPsInsight
3. How to Enable Partial History Expiry on Geth, Besu, and Nethermind Clients
4. History Expiry Moves Forward in Ethereum’s Fusaka Upgrade
5. Highlights from the All Core Developers Execution Call #218

To follow blockchain news, track Ethereum protocol progress, and read our latest stories, subscribe to our weekly today.

Join the EtherWorld & Avarch Internship Program and build your career in blockchain, content, social media, video, podcast editing, or operations. Send your resume and brief introduction to contact@etherworld.co.