Skip to content

Comments

Add EIP-7928 Block-level Access Lists JSON RPC methods#726

Open
nerolation wants to merge 6 commits intoethereum:mainfrom
nerolation:rpcs
Open

Add EIP-7928 Block-level Access Lists JSON RPC methods#726
nerolation wants to merge 6 commits intoethereum:mainfrom
nerolation:rpcs

Conversation

@nerolation
Copy link
Contributor

@nerolation nerolation commented Dec 20, 2025

Add RPC methods for EIP-7928 Block-level Access Lists

This PR introduces two new RPC methods to query block-level access lists (BALs) as defined in EIP-7928:

- eth_getBlockAccessListByHash — returns the BAL for a block by hash
- eth_getBlockAccessListByNumber — returns the BAL for a block by number or tag

This PR introduces one unified RPC method: eth_getBlockAccessList
Accepts BlockNumberOrTagOrHash (hash, number, or tag like latest)
Returns structured JSON object (not RLP bytes)


  • Block access lists are stored separately from EL blocks and are not included in the Block structure.
  • RPC methods use the BlockAccessList naming to avoid confusion with EIP-2930 transaction access lists.
  • Error code 4445 is returned for pre-Amsterdam blocks.

@MysticRyuujin
Copy link

Is there a test for 4444 "pruned history unavailable" or perhaps that not possible with the current hivenet?

Also, maybe a silly question but how will the node know the difference between non-existing and pruned?

Otherwise lgtm

@nerolation
Copy link
Contributor Author

No, there's none on that. Wasn't sure about this one but if you say it makes sense to add one, let's do it.
Re, pruned vs. non-available, there can never be a valid ExecutionPayloadEnvelope with an empty Payload on the CL . As long as the EL block exists, it will always contain some fields in the BAL, e.g. entries from system contracts (4788, 7002, ... ) and won't be empty. If the BAL doesn't exist, but the block did, it must have been pruned.

Copy link
Contributor

@mkalinin mkalinin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec and tests look good!

@bhartnett
Copy link

It's not clear from the naming of eth_getBlockAccessListByHash whether the API expects the block hash or the BAL hash.

I would suggest naming the two endpoints something like:

  • eth_getBlockAccessListByBlockHash
  • eth_getBlockAccessListByBlockNumber

This naming would be consistent with other RPCs such as:

  • eth_getTransactionByBlockHashAndIndex
  • eth_getTransactionByBlockNumberAndIndex
  • eth_getUncleCountByBlockHash
  • eth_getUncleCountByBlockNumber

@fjl
Copy link
Contributor

fjl commented Jan 21, 2026

We have just merged the test generator into this repo, so it's easier now to add the testse. The tests need to be added to the generator in https://github.com/ethereum/execution-apis/blob/main/tools/testgen/generators.go and then recreated.

@fvictorio
Copy link

Why do these methods return '#/components/schemas/bytes'? Shouldn't they return a structured object?

@nerolation
Copy link
Contributor Author

Why do these methods return '#/components/schemas/bytes'? Shouldn't they return a structured object?

Yeah agree. Should be incorporated for amsterdam-devnet-3

@nerolation
Copy link
Contributor Author

The lastest commit consolidated into a single eth_getBlockAccessList method using BlockNumberOrTagOrHash for consistency with eth_getBlockReceipts and to provide a simpler API surface that supports block hashes, numbers, and tags through one endpoint.

Curious to hear if we should change it to byBlockNumber or byBlockHash or keep it as-is?

@matkt
Copy link

matkt commented Feb 12, 2026

I like the naming eth_getBlockAccessList using BlockNumberOrTagOrHash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants