EIP-7928 Breakout #13, Feb 25, 2026

Protocol Calls & happenings
,
1

Agenda

Discussion:

Meeting Time: Wednesday, February 25, 2026 at 14:00 UTC (60 minutes)

GitHub Issue

2

Hi @Nerolation,
@CPerezz and I are looking for some feedback on the feasibility of using BAL as a vehicle for the payload needed by nodes to become partially stateful. The proposal’s timeline is post - Glamsterdam.

I’m writing the TL;DR on partial statefulness below for context, followed by the link to the Hackmd note containing more detailed information, including the high-level proposed spec changes:

Abstract

With the advent of zero-knowledge proofs, and stateless attesting nodes, state growth and the lack of decentralized RPC access could have a compounded down-side effect on the network: builders might be the only entities that will be incentivised to continue to serve state or answer RPC requests in the future, due to the rational behavior of network participants. This might run Ethereum’s data layer dry.

The gist of Partial Statefulness

Partial statefulness can be viewed as a topology-based approach to state growth and state serving.

Partial statefulness does not require every node to store complex datasets (the entire tree), instead, it makes use of selective persistence , i.e. storing domain-separated subtrees, while a widely affordable and minimal dataset of global commitments, keeps nodes coherent under the canonical state root.

State Topology - refresher

Looking at Ethereum state as a partially divisible graph, we can identify certain state subtrees as functional domains, i.e. Accounts and Contract Storage. Domain separation supports partial statefulness and could help state expiry tooling and enable better caching strategies.

How make partial statefulness technically possible?

In order for partial nodes to be able to correctly store and offer verified slices of state, as well as proofs, they must check two main conditions:

  1. They must be coherent. Partial nodes must maintain the tip of the trie and ensure that their stored state sits under the canonical chain.
  2. They must be Merkle-proof capable. In order to be proof-capable, partial nodes will need to prove that a specific state or storage is correctly included in the account or storage tries, without persisting the entire state. For that it is mandatory to pass all the siblings of a particular node along the path to state root (the authentication path), otherwise the hash of their local storage would not make sense.

Minimal local state

  1. For coherence, partially stateful nodes MUST, at least store accountHash for all accounts. Nodes could store it as an address → accountHash map (~ 10 GB). This dataset is small enough for modest machines, yet complete enough to verify any account’s correct inclusion under the state root, and verify any account or contract changes.

  2. For proof capabilities, the nodes MUST locally persist the Merkle path any tracked account or contract, alongside the minimal data set required for coherence.

Syncing via block enforced diffs

Two types of diffs are needed to to unlock partial state storage, in a coherent, persistent and consistent way, without re-execution:

i. Full-state diffs - a list of all nonce, balance, storage and code changes that the current
block induces to a certain account. These block-enforced state full diffs allow partial nodes to update the stored state values and keep local state persistent - EIP-7928 already adds this to protocol.

ii. Account-hash diffs - the hashes of the account state for the addresses touched by the current block →old_accountHash and their updated correspondent hash after executing the block’s txs →new_accountHash.
These block-enforced state hash diffs allow partial nodes to be synchronized with the global state-root - We see BAL as the ideal vehicle for hash-diffs.

Partial Statefulness capability ladder

Depending on the complexity of locally stored data sets, we have different levels of partial statefulness functionality. The richer the locally stored dataset, the more nodes becomes less dependent on third-party RPC / state providers, while still staying far below “full node” requirements.

The scope of this proposal is to add protocol native support for the minimal payload needed to make partial statefulness functional (the account-hash diffs) leaving the extra functionality optional, for node operators to decide.

Resources

3

Meeting Summary:

The team discussed client optimizations and benchmark testing requirements for various Ethereum clients, focusing on batch I/O and parallel execution features. They reviewed recent EIP merges and implementations related to block access lists, including max item checks and JSON RPC updates for devnet 2. The conversation ended with discussions about partial statefulness proposals and the potential use of BAL to handle account hash diffs, with plans to continue these conversations asynchronously through a Discord group.

Click to expand detailed summary

Toni facilitated the 13th EIP 7928 breakout call and opened with updates on client optimizations needed for repricing benchmarking. She specifically requested updates from clients on progress within the last two weeks, particularly regarding Parallel I.O. The meeting was just beginning, with participants joining and Toni waiting for everyone to be ready before starting the formal discussion.

The team discussed optimization work on Besu, including prefetch improvements and Max ETH checks, with Karim reporting they are waiting for test results and working on shadow fork testing for more accurate benchmarking. Toni noted that realistic state testing is needed for batch I/O benchmarking, particularly for execution parallelization not involving state changes. The meeting continued with plans to hear updates from Erigon and Jochem about benchmarking Besu and Geth on shadow fork and devnet environments.

The team discussed benchmark testing requirements, specifically the need for a client that supports the new testing RPC endpoint to run tests on top of mainnet state. Jochem explained that current testing infrastructure doesn’t support Glam EIPs, making it difficult to conduct meaningful batch I/O tests. Karim suggested creating a shadow fork with mainnet transactions to generate worst-case scenarios for stress testing. Jared provided an update on Geth’s BAL optimizations, noting that batch I/O and parallel execution features are implemented but no significant updates have been made recently.

Toni reported that Geth and Besu clients are ready for benchmarking, with necessary flags provided to enable optimizations. The team agreed to focus on batch I/O optimizations first, as this is needed for final pricing changes in Glamsterdam and to determine whether to keep state locations in the BAL. Toni also discussed two recent EIP merges: a clarification about how BAL is used in state transition functions and updates to the max item check for safeguarding against invalid logs that could take longer to execute than valid blocks.

Felipe and Toni discussed the implementation of max item checks in the EIPs PR, focusing on security considerations and testing requirements. Toni explained that certain checks cannot be easily implemented within the state transition function due to limitations in the block-layer access list. They agreed to further discuss the specifics of implementing these checks, particularly regarding the balance access list and gas availability, asynchronously to clarify the approach and ensure proper testing for clients.

The team discussed three main topics related to BAL (Block Access Lists) items. They confirmed that existing tests already handle uniqueness and duplication checks for BAL items, with a recent PR merged that will be included in the next release. The group also verified that tests for BAL item ordering are in place, though Rahul was asked to confirm specific test details. Finally, they discussed JSON RPC implementation for devnet 2, noting recent changes to return JSON objects instead of hex strings, and confirmed that clients had already implemented this for devnet 2.

The team discussed the implementation status of an API on Besu, with Karim confirming it was already implemented and merged. Toni noted that while the PR was posted, it needed to be reviewed before clients implement it, and planned to check with Omar about updates on the RPC standards. The conversation ended with a discussion about to begin regarding the feasibility of using DAO for payload needed by partial stateful nodes, though the details of that discussion were not captured in the transcript.

Dan presented a proposal for partial statefulness, suggesting the use of BAL to handle account hash diffs, which would involve nodes storing a minimal dataset including account hashes, balance roots, and code hashes. Toni expressed interest in the topic and agreed it was relevant for future development, though he noted concerns about potential BAL size inflation with the addition of 32-byte values for each changed account. The group decided to continue the discussion asynchronously through a Discord group set up by Toni.

Next Steps:

  • Besu team (Karim): Post updates into BlockFact Access List Discord when ready for benchmarking on shadow fork or devnet 3
  • jochem-brouwer: Need one client to implement testing RPC endpoint with support for Glam EIPs to enable filling benchmarks on top of state
  • Toni: Double check why JSON RPC PR is not yet merged
  • Toni: Double-check with Omar about JSON RPC PR updates from RPC standards call
  • Felipe and Toni: Chat async about how to implement max item check and remaining gas check in EELS specs
  • Felipe: Double check which test covers BAL item ordering
  • Toni: Set up Discord group with Dan and jochem-brouwer to discuss partial statefulness proposal

Recording Access:

1 Like
4

YouTube Stream Links: