Skip to content

EIP-7928: Block level access lists#3911

Merged
bhartnett merged 33 commits intomasterfrom
bal-devnet-2
Jan 16, 2026
Merged

EIP-7928: Block level access lists#3911
bhartnett merged 33 commits intomasterfrom
bal-devnet-2

Conversation

@bhartnett
Copy link
Copy Markdown
Contributor

This PR contains all the changes required to implement EIP-7928 which includes:

  • Added BAL tracking into the evm to collect the required data for BAL building.
  • BAL pre and post execution validation.
  • Engine API changes.
  • Added two new RPC endpoints debug_getBlockAccessList and debug_getBadBlocks.

BALs are only enabled at Amsterdam and the tracking is disabled otherwise so this change should have minimal impact pre-Amsterdam.

bhartnett and others added 30 commits November 28, 2025 23:52
* Implement debug_getBlockAccessList rpc endpoints.

* Store block access lists by blockHash to enable pruning in the future.
* Fix BAL persist in ForkedChain.

* Implement debug_getBadBlocks RPC endpoint.
@bhartnett bhartnett marked this pull request as ready for review January 16, 2026 02:17
@bhartnett bhartnett merged commit 8949cee into master Jan 16, 2026
17 of 18 checks passed
@bhartnett bhartnett deleted the bal-devnet-2 branch January 16, 2026 04:03
Bpo4 : Opt.none(BlobSchedule),
Bpo5 : Opt.none(BlobSchedule),
Amsterdam: Opt.none(BlobSchedule),
Amsterdam: Opt.some(BlobSchedule(target: 14'u64, max: 21'u64, baseFeeUpdateFraction: 11_684_671'u64)),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just as a side note, Kurtosis genesis generator by default doesn't configure Bpo1 and Bpo2, so Amsterdam is set to Osaka values. This is not necessarily more / less correct, it just is a difference in defaults.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

One still has to be careful, that if no BPO is scheduled, that it doesn't randomly assume default BPOs. But if that's wrong, it wasn't a regression in this specific PR as Bpo1/Bpo2 are already assumed to be part of the 'default blob schedule'.

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.

2 participants