All Core Devs - Execution (ACDE) #207

[timbeiko]

ACDE#207

• March 13, 2025, 14:00-15:30 UTC
  • 🕐 DST warning: double check your local time 🕐
• 90 minutes
• Stream: https://youtube.com/live/byrC-fdTOvE

Agenda

• Pectra
  • Holesky Path Forward
    • Option A — Hoodi?
  • Testing requirements before mainnet
  • System contract calls error handling
  • [async review] Update EIP-6110: Spec parse_deposit_data EIPs#9460
• Fusaka
  • Update EIP-7594: include cell proofs in network wrapper of blob txs EIPs#9378
    • execution-apis: Add EIP-7594 (PeerDAS) related changes execution-apis#630
  • Disabling EOF to help PeerDAS testing
  • Fork deadlines
    • Update dates
    • Change days to Mondays to allow Tue/Wed for review before ACDs
    • Client team DFI proposals
• EIP-4444 progress updates
  • Add error when accessing pruned chain data execution-apis#636
• EIP presentations
  • EOF PAY opcode
  • EIP-7819
• Stateless clients for MPTs

Facilitator email: tim.beiko@ethereum.org

[yperbasis]

I'd like to specify what happens if one of the system contract calls (beacon, block hash history, withdrawal, consolidation) fails. Say it runs out of gas (which should be 30 million for system calls per EIP-2935). Is the block considered invalid? That's unspecified at the moment.

[jochem-brouwer]

Want to discuss this spec clarification in EIP-6110 if this does not get merged / discussed async: ethereum/EIPs#9460

[Amxx]

In the context of Fusaka, I'd like to do a quick presentation of EIP-7819 (either in EOF, or in legacy if for any reason EOF is postponed)

[ralexstokes]

another companion PR to ethereum/EIPs#9378 is this PR concerning the Engine API: ethereum/execution-apis#630

implementers should take a look at both

[dapplion]

• Update EIP-7594: include cell proofs in network wrapper of blob txs EIPs#9378

is already on the agenda but I would like to ask EL teams to think about the remaining design decisions ahead of the call:

• Use new transaction type or not
• If not new transaction type, should ELs accept on the RPC the new format with cell_proofs only or new format + old format

[abcoathup]

Upgrade schedulers (assuming testing goes well now that Holešky testnet has finalized):

• https://slots.symphonious.net/
• https://beaconcha.in/slots/finder#upgrade-scheduler

East coast Australia will be the same timezone as Brisbane after April 7.

[parithosh]

ethPandaOps would like to bring up the topic of how we proceed now that holesky has finalized: https://notes.ethereum.org/@ethpandaops/post-finality-path-forward-holesky

TLDR: With the large exit queue, holesky is not suitable for a lot of testing. We propose 4 potential paths forward and would like to choose the one that staking providers and the community would feel is most useful for them.

[mcdee]

ethPandaOps would like to bring up the topic of how we proceed now that holesky has finalized: https://notes.ethereum.org/@ethpandaops/post-finality-path-forward-holesky

TLDR: With the large exit queue, holesky is not suitable for a lot of testing. We propose 4 potential paths forward and would like to choose the one that staking providers and the community would feel is most useful for them.

I will not be able to attend the meeting, however here is my view of the path forward for holesky:

A: this is my preferred option, with a tweak. When we launched sepolia and holesky there were various views on the lifetime of the testnet, however given what we have seen with holesky I believe that we should create a new testnet with a lower lifetime (max 3 years, ideally 2 years). The rationale behind launching a new testnet, and launching one with a lower lifetime, is the same: too many contracts on, and tooling for, holesky are deployed/built and then forgotten without generating a repeatable process. By keeping the idea that another deployment of the contracts and tooling is likely to happen for the person doing the initial work they are more likely to lay out processes to redeploy. Even if people stick with the 5 year lifespan, this remains my preferred option as it results in a clean testnet (and although it's good for us to have gone through a recovery of holesky, we don't need to deal with the resultant scarring the other options that keep holesky alive will leave for the next 3 years).

B: this is a good network for those that need to test ASAP, as it is available right now. As per my previous comment, turning deployments into a repeatable process is time well spent. The difference in chain parameters should not matter, as long as the parameters are read from spec rather than hard-coded (and if they are this would help flush out the code that did that, making it more resilient).

C: this doesn't seem to have any significant benefits over other solutions, and seems to be a half-way house with some items (contract addresses) staying the same and others (genesis validators root? fork version?) potentially changing.

D: not sure how this would work, likely a hard fork purely for holesky? Possible, but it will probably take a while to code and test fully, and there's always a chance of it in turn going wrong. Optics of that would be... bad.

[fjl]

Something for the agenda: we would like to propose JSON-RPC error code 4444 for the condition when an API call accesses pruned history. ethereum/execution-apis#636

We kind of pre-agreed this with people from Nethermind & Reth at the Portal Network Summit, but would be nice to get a formal decision in.

[github-actions]

Discourse Topic ID: 23020

• Action: Updated at 2025-03-13 14:40 UTC
• URL: https://ethereum-magicians.org/t/23020

[timbeiko]

I've updated the agenda with all of the above. Our first priority should still be to get a clear path to resolve all Pectra issues and get the fork activated on mainnet. IMO we should spend as much time as necessary on the call discussing this.

@fjl we can at least flag your RPC PR but if we're out of time and need more discussion, maybe we can discuss it on next Monday's RPC call?

@Amxx @wjmelements @kevaundray I can't guarantee we'll have time to cover your topics. If you don't want to sit through the call to maybe discuss it at the end, we can already plan the conversation for 2 weeks from now, when most urgent Pectra topics should will hopefully be resolved.