All Core Devs - Execution (ACDE) #218, August 14, 2025

[nixorokish]

UTC Date & Time

August 14, 2025, 14:00 UTC

Agenda

• Fusaka
  • devnet-4 updates
    • BPO update rule
  • Testing: devnets vs. spec tests
  • Timelines
    • Alex proposal
• Glamsterdam
  • Headliner Finalization
    • Size vs. Impact
    • Update EIP-7773: Move EIP-7732 and EIP-7928 to SFI, EIP-7792 to DFI EIPs#10117
  • Scope & Timelines
  • EIP-7928
    • Including state locations that are not modified in the BAL or not.
    • RLP vs. SSZ
    • System contracts
• safe head
• Other EIPs
  • Add EIP: Deterministic Factory Predeploy EIPs#10092
  • EIP-2926

Call Series

All Core Devs - Execution

Duration

90 minutes

Occurrence Rate

bi-weekly

Use Custom Meeting Link (Optional)

• I will provide my own meeting link

Facilitator Emails (Optional)

tim@ethereum.org

Display Zoom Link in Calendar Invite (Optional)

• Display Zoom link in invite

Custom Meeting Link (Optional)

No response

YouTube Livestream Link (Optional)

• Create YouTube livestream link

[github-actions]

🎉 Protocol Call Resources Created:

⏭️ Zoom: Skipped (user opted out)
✅ Calendar: Add to Calendar
✅ Discourse: Created Topic
✅ YouTube: Streams created
📺 - Stream 1 (Aug 14, 2025): https://youtube.com/watch?v=iPYHJnEeY9g

[github-actions]

🔄 Protocol Call Resources Updated:

✅ Zoom: Join Meeting
✅ Calendar: Add to Calendar
✅ Discourse: Created Topic
✅ YouTube: Streams created
📺 - Stream 1: https://youtube.com/watch?v=iPYHJnEeY9g

[pochenai]

🔄 Protocol Call Resources Updated:

✅ Zoom: Join Meeting ✅ Calendar: Add to Calendar ✅ Discourse: Created Topic ✅ YouTube: Streams created 📺 - Stream 1: https://youtube.com/watch?v=iPYHJnEeY9g

Can't add it to my calendar

[frangio]

I'd like to propose EIP-7997: Deterministic Factory Predeploy for inclusion. I can present it if the agenda is open to non-headliners.

[nerolation]

I want to quickly chat about EIP-7928 (Block-Level Access Lists) and see if we find agreement on the remaining two open topics:

• Including state locations that are not modified in the BAL or not.
• RLP vs. SSZ

If it turns out that we need more discussion, I'd suggest trying to find a time for a follow-up breakout call.

[ralexstokes]

hello! following up from last week's ACDC, i'd like to propose a refinement of fusaka timelines

8th Sep: client releases for sepolia (and holesky if needed); bug bounty begins
15th Sep: Holesky fork (can provide branch, no releases needed)
29th Sep: Sepolia fork
1st Oct: Hoodi and mainnet releases
8th Oct: Hoodi fork
5th Nov: Mainnet

would be great to hear feasibility from each team for this schedule -- ideally both CL and EL teams

[mkalinin]

If there is a time on the call i’d like to quickly go over potential safe block usage by EL clients and consumers, more context is in #1624 (comment). The default option is to re-define safe block tag to denote the most recent fast confirmed block, and we’re looking for potential pitfalls and alternative opinions on that.

[jwasinger]

I have an additional topic I would like to bring up related to block access lists:

Currently, changes from system contracts (and eip-4895 withdrawals) are encoded in the BAL as having occurred at transaction len(block.transactions): the index after the last transaction in the block.

I think it would be simpler from the implementation perspective if we moved theses changes into separate "transaction indices" based on whether or not they occurred pre or post transaction execution. We should also consider renaming these indexes to "layer index" or something similar to disassociate them from being tied to transactions only.

What I am proposing is that the layer index of a BAL entry maps to the block as follows:

• index 0: pre-tx-execution system contract state changes
• index 1 to len(block.transactions): post-state changes for each block transaction
• index len(block.transactions) + 1: post-block system contract state changes and eip-4895 withdrawal balance changes.

I think this is easier than the current spec for several reason:

• the order of state changes for each account in the encoding format of the BAL reflect the order they would be sequentially applied to perform the block execution
• there is no need to implement fork-specific logic to determine how to separate the system contract BAL state changes into pre/post-tx-execution changes and validate that the change set is complete and succinct:
  • as an example, consider the edge case where an eip-4895 withdrawal is sent to a system contract address, requiring client-specific logic to know that BAL-reported balance changes from system contract addresses must have occurred in the post-transaction-execution state change. This edge-case alone could restrict Ethereum from adding new system contracts which can change account balances before the start of transaction execution.
  • a future system contract which executes both before and after transaction execution would not be able to be supported with the current spec.

[nerolation]

I understand the point about the current system not supporting system contracts that have both pre-execution and post-execution changes to the same storage slot at the same time.

For all other cases (e.g., withdrawals), it’s straightforward:

• These happen post-execution, and you can tell because they’re mapped to the dummy transaction index at len(transactions).

• The same applies for parent hashes and beacon roots: by looking at len(transactions), you immediately know which changes are:

  • Pre-execution: beacon root, parent hash
  • Post-execution: withdrawals, EL-triggered withdrawals, consolidations

Splitting these into two entries and thus causing the tx_index in the BAL to diverge from the tx_index in the block feels unnecessarily messy and provides no real benefit.

If we ever need to handle the rare case where a contract has both pre- and post-execution changes to the same slot, we could:

• Allow the address to appear twice in the BAL (once for pre, once for post, in that order), or
• Use an alternative index like len(transactions) + 1.

Since we don’t have that scenario today, it’s better to keep things simple.

Example: Consider the supposed edge case where an EIP-4895 withdrawal is sent to a system contract address. This would require client-specific logic to interpret BAL entries for system contracts as post-execution changes.

In this case, you’d simply see a positive balance for the system contract address with tx_index = len(transactions). That alone tells you enough to know it's a withdrawal, so it must be applied post-execution, no extra logic is needed. If that system contract is the beacon root system contract, then you'd only apply the actual storage changes pre-execution and the balance changes post-execution.