All Core Devs - Testing (ACDT) #36 | May 12 2025

[marioevz]

All Core Devs - Testing (ACDT) #36, May 12 2025

• May 12, 2025, 14:00 UTC
• 60 Minutes
• Recurring meeting : true
• Call series : All Core Devs - Testing
• Occurrence rate : weekly
• Already on Ethereum Calendar : true
• Need YouTube stream links : true

Agenda

• Pectra fork (if necessary)
• Decide which CFI'd EIPs move to SFI status for include in Fusaka Devnet-0
• PeerDAS testing
• Introduce blob schedule CL discussion (Introduce blob schedule consensus-specs#4277)
• Discussion about history expiry and what our plan is for rollout, releases, docs, testing

Other comments and resources

The zoom link will be sent to the facilitator via email
Facilitator emails: mario.vega@ethereum.org

🤖 config

• Duration in minutes : 60
• Recurring meeting : true
• Call series : All Core Devs - Testing
• Occurrence rate : weekly
• Already a Zoom meeting ID : true
• Already on Ethereum Calendar : true
• Need YouTube stream links : true
• display zoom link in invite : false

[github-actions]

Discourse Topic ID: 24076

• Action: Updated at 2025-05-12 13:48 UTC
• URL: https://ethereum-magicians.org/t/24076

Zoom Meeting: Reusing meeting 84251237513 for series 'all core devs - testing'.

• Zoom link hidden (sent to facilitator email)

Existing YouTube Stream Links (Reused):

• Stream 1 (May 12, 2025): https://youtube.com/watch?v=Lzpb1czKWR8

Calendar Event: Reusing existing event for series (Link/ID not found in mapping).

• Skipping email notification (already processed issue All Core Devs - Testing (ACDT) #36 | May 12 2025 #1528 before).

Telegram Notification

• Updated message for this occurrence to Ethereum Protocol Updates channel

[marioevz]

Adding discussion to decide which CFI'd EIPs move to SFI status for Fusaka:

EIP-5920: PAY opcode
EIP-7883: ModExp Gas Cost Increase
RIP-7212: Precompile for secp256r1 Curve Support
EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS
EIP-7823: Set upper bounds for MODEXP
EIP-7825: Transaction Gas Limit Cap
EIP-7907: Meter Contract Code Size And Increase Limit
EIP-7917: Deterministic proposer lookahead
EIP-7918: Blob base fee bounded by execution cost
EIP-7934: RLP Execution Block Size Limit

[ralexstokes]

we should get final comments on this so we can merge it and move ahead w/ blob scaling

ethereum/consensus-specs#4277

[parithosh]

I'd like to bring up the topic of history expiry and what our plan is for rollout, releases, docs, testing

[marioevz]

EELS+EEST CFI'd EIPs analysis: https://notes.ethereum.org/@marioevz/fusaka-cfid-testing-analysis

[ralexstokes]

if there is time, we should discuss plans for introducing a per-transaction blob limit in fusaka

there's some interest in this (as a single transaction with e.g. 48 blobs is quite unwieldly at the networking layer) and it would be good to align on:

1. in-protocol rule
2. mempool restriction
3. what the actual limit should be

[will-corcoran]

PeerDAS Update for All Core Dev Testing (ACDT) #36

HEADLINE: peerdas-devnet-7 is live and consensus-spec v1.5.0 was released!

A. Client Updates

CL Client Teams

Team	Active ICs	Validator Custody Status
Lighthouse	Jimmy, Pawan + J	Not yet supported
Prysm	Manu, Terence & Radek + Francis & Niram from Base	Supports w/out backfill
Teku	Dmitrii + Jerone Ost from Soneium	Supports w/ backfill
Nimbus	Agnish & Dustin	Not yet supported
Lodestar	Matt K, Katya + Derek & Hugh from Base	Supports w/out backfill
Grandine	Hangleang & Saulius Grigaitis	Not yet supported

EL Client Teams

Team	Active ICs	peerdas-devnet-7 Status
Geth	Felix, Marius, Lightclient, jwasinger	Branch status for peerdas-devnet-7 needs confirmation
Nethermind	FLCL, Marcin	Included in peerdas-devnet-7
Reth	Roman, Dan	Included in peerdas-devnet-7
Besu	-	-
Erigon	-	-
EthereumJS	Gajinder	Included in peerdas-devnet-7

B. Devnet / Testing Updates

Topic	Subtopic	Details
peerdas-devnet-7	Included:	- Data colum sidecars by root - Validator Custody (optional) - Distributed Blob Publishing - Shifting Cell Proof Computation to tx-sender
-	Config	- 37 nodes total (1 bootnode, 36 validating nodes) - 18 supernodes (50%), 18 non-supernodes (50%) - Each node has 8 validators - 16GB machines with 250GB storage
-	Blobs	- Target/max blob 6/9 similar to Pectra - Future blob increase will be via BPO in future devnets - FULU fork upgrade completed ✅
-	Validator Custody	- Most clients have partial implementation - Concerns about dynamic validator custody and possible debugging issues - Discussion on whether to maintain it as optional or remove from devnet-7
ProbeLab	Node-custody Tool	- Development status update from cortze - Tool to visualize validator custody
Sunnyside Labs	Update	- Voiceover

C. Spec / EIP Discussion

Spec	Number	Topic	Opened by	Status	Status / Discussion
consensus + EIP	PR: #4277	Blob schedule PR (addresses #4267 and #4266)	Gabe	Open	- PLEASE REVIEW. Goal is to merge by Friday. "Ignore table parsing code btw" - Related: Update EIP-7594: Add blob count per tx limit via blobSchedule (link) [FLCL]
beacon API	PR: #524	Add new getBlobSidecars spec	Francis	Open	- Debate about all-or-nothing approach to blob retrieval - API primarily supports local block building where blobs are in public mempool - Data shows 60% success rate with current getBlobsV1 on mainnet
-	Issue: #519	produceBlock and publishBlock: Remove blobs and KZG proofs	Manu	Open	-
beacon-metrics	PR: #14	PeerDAS metrics: add data column, kzg, custody metrics	Katya	Draft	-
EIPs	PR: #9588	Update EIP-7594: Polish EIP, expand rationale	Alex	Open	Reviewing security w/ Francesco and Marco

D. Open Discussion

• BPO Fork Blob Schedule

  • Discuss any blockers to merging #4277

• Validator Custody Implementation

  • Discuss implementation differences across clients
  • Concerns about dynamic validator custody in devnet-7
  • Backfill mechanisms and their challenges

• Blob Data Observations

  • Derek's observation about blob data/commitments/hashes not being unique
  • Implications for spammoor at high blob counts

• Client Readiness

  • Assessment of client readiness for Fusaka
  • Outstanding issues to resolve before fusaka-devnet-0

• Blob Fee EIPs

  • Track outcome of EIP-7762 & EIP-7918

F. Schedule

Date	Item	Status
May 7th, 2025	Pectra Mainnet Upgrade	Completed ✅
May 7th, 2025	consensus-spec Release v1.5.0	Completed ✅
May 9th, 2025	peerdas-devnet-7 Launch	Completed ✅
May 13th, 2025	FULU Fork Activation on devnet-7	Completed ✅
Late May, 2025	fusaka-devnet-0 (based on devnet-7)	Planned
June 8-14, 2025	EL / CL Interop	Planned
Post June 14, 2025	Audits: KZG libraries	Planned

[benaadams]

Nethermind's support for Fusaka, ordered by inclusion preference/timeline

1. EIP-7594: PeerDAS - Peer Data Availability Sampling (SFI)
2. EIP-7935: Set default gas limit to XX0M (SFI)
3. EIP-7883: ModExp Gas Cost Increase
4. EIP-7823: Set upper bounds for MODEXP
5. EIP-7934: RLP Execution Block Size Limit
6. EIP-7825: Transaction Gas Limit Cap
7. EIP-7918: Blob base fee bounded by execution cost
8. EIP-7917: Deterministic proposer lookahead
9. RIP-7212: Precompile for secp256r1 Curve Support
10. EIP-7642: eth/69 - Drop pre-merge fields (SFI)
11. EIP-7892: Blob Parameter Only Hardforks (SFI)

With remaining time spent on improving scalability (and possible EIPs that address blockers that may arise during investigation; if they require consensus coordination and are not just individual client implementation improvements)

Additional EIPs inclusion should be addressed by maintaining an improved cadence on future forks.

[jochem-brouwer]

@benaadams PAY EIP is missing? 😢 (EIP-5920)

Other EIPs inclusion should be addressed by maintaining an improved cadence on future forks.

This sentence is somewhat confusing since "Other EIPs" is also a term used in Fusaka's Hardfork Meta: https://eips.ethereum.org/EIPS/eip-7607#other-eips

[benaadams]

Other EIPs inclusion should be addressed by maintaining an improved cadence on future forks.

This sentence is somewhat confusing since "Other EIPs" is also a term used in Fusaka's Hardfork Meta: https://eips.ethereum.org/EIPS/eip-7607#other-eips

Changed to Additional. One issue with historic fork timelines is the are so infrequent that they need to be jammed with EIPs as the next inclusion round is so far in future.

Hopefully with principle of adopting a faster fork cadence; EIPs can be included more frequently and the pressure to stuff forks reduced (e.g. Fusaka 6 months after Pectra, and Glamasterdam perhaps 6 months after Fusaka, etc)

[jochem-brouwer]

I agree (and hope) we should/will get a faster fork schedule 😄 👍

Could you elaborate why Nethermind does "not want" (I'm assuming this is the signal given here) PAY in Fusaka? Especially with EIPs, which I think are "bigger"/more complex, which are on the inclusion list: RIP-7212?

[benaadams]

which I think are "bigger"/more complex, which are on the inclusion list: RIP-7212?

RIP-7212 has been implemented for a long time for all the ELs and most L2s already support it; so is just making available to L1 (and geth bringing back from one of the rollup-geth variants)

Rest are mostly minor changes

Appetite for Evm changes was rejected in this fork; and focus was determined to be improving ELs performance rather than specific EIPs

[jochem-brouwer]

(This comment is not supposed to be read in a frustrated/irritated tone, but I feel that PAY is relatively small-ish change compared to the huge benefits it unlocks for users/smart contract developers, which is also why I am pushing this rather hard lately 😅 )

I have relistened to last ACD, I think the EVM changes you mentioned here are rejected in the context of "removal of dynamic jumps" (for Fusaka). This rejection also seems to be part of the broader context of the "big"/broader EVM updates (like EOF) and specifically thus the removal of dynamic jumps.

The two ModExp EIPs are EVM, as is RIP-7212.

The PAY EIP is extremely helpful from a smart contract development perspective. I'll copy the current state of the motivation part from this PR (would also like feedback there).

Currently, to send ether to an address requires you to call into that address, which transfers execution context to that address, which creates several issues:

• First of all, it opens a reentrancy attack vector, as the recipient can call back into the sender. More generally, the recipient can unilaterally execute arbitrary state changes, limited only by the gas forwarded, which is not desirable from the point of view of the sender.
• Secondly, it opens a DoS vector. Contracts which want to send ether must be cognizant of the possibility that the recipient will run out of gas or revert.
• The EXTCALL opcode (introduced in EOF) does not provide a way to restrict the amount of gas being forwarded to the recipient, which means sending ether via EXTCALL is always subject to the reentrancy attack vector.
• The CALL and EXTCALL opcodes will execute code on the receipient, which is unintended when wanting to send ether and which could lead to unintentional operations. The code execution also has to be paid for in gas, even when the intention is to only send ether, which is thus an unnecessary waste of gas.
• Finally, EIP-7702 allows to delegate externally owned accounts (EOAs) to other accounts, which breaks the invariant that EOAs cannot contain code. Therefore, calling such EOA with the intention to send ether will thus also execute code and cost unnecessary gas.

Having a dedicated opcode for ether transfers solves all of these issues, and would be a useful addition to the EVM.

I have also dedicated myself to ensure there are tests in execution-spec-tests and help on the reference implementation in execution-specs