ACDC #160 Action Items
- Prepare/publish releases with updated default gas limit
- Debug
fusaka-devnet-2and prepare forfusaka-devnet-3genesis the week of 21st July - Start preparing client opinions for headliner selection to occur after
fusaka-devnet-3is live and stable- https://forkcast.org/upgrade/glamsterdam for a nice digestible EIP explorer
ACDC #160 Summary
Releases for higher (default) gas limit
- CL releases require updated gas limit values to 45M
- Clients plan releases soon with updated gas limits
Fusaka
-
devnet-2
- Participation rate and proposals are healthy but could be better
- Some nodes experiencing memory issues with high column participation; some other peering issues
- Current focus on fixing existing bugs to ready for devnet-3
-
devnet-3
- Launch targeted for week of 21st July
- Will reflect the mainnet Fusaka spec
- [clarification for EL EIPs] Will include CLZ and transaction gas cap changes
- Refer to https://notes.ethereum.org/@ethpandaops/fusaka-devnet-3 for the latest
-
With a stable devnet-3, then turn to hardening implementations
- Focus on testing non-finality scenarios and syncing
-
GetBlobs API Changes
- Proposal to revert GetBlobs v2 semantics and move partial response functionality to v3
- Current v2 spec uses “may” language for partial responses which creates ambiguity
- Agreement to:
- Restore v2 to all-or-nothing responses
- Implement mandatory partial responses in v3
- meaning merge in #674
- Aim to have v3 in Fusaka so that we can leverage the feature with further networking optimizations even ahead of Glamsterdam
-
Builder API changes
- One open spec item for
devnet-3is changing the response of the builder API’sgetPayloadcall to reflect the high planned blob count - A PR proposing one solution is here:
- Add `eth/v2/builder/blinded_blocks` which does not return the execution payload and blobs by bharath-123 · Pull Request #123 · ethereum/builder-specs · GitHub
- Core devs present generally favored this solution
- One open spec item for
-
Mainnet Planning
- Rough target timelines from Sigma Prime blog post:
- Road to Shipping PeerDAS to Mainnet in 2025
- Mid-October mainnet launch
- September testnets
- August preparation
- General consensus on something like this to target Q4 Fusaka launch
- although consider the above post a strawman for now
- Wide agreement that we need the following before going to mainnet:
- Need extensive testing of:
- Non-finality scenarios and other failure cases
- Syncing behavior
- Network with 1000+ nodes and more realistic P2P conditions
- Need extensive testing of:
- Attendees also favored a conservative BPO rollout strategy
- Initial modest increase at launch, with an observation period to gather mainnet data
- Then, a second increase early next year aiming for the full theoretical gain PeerDAS can unlock
- Rough target timelines from Sigma Prime blog post:
⠀Glamsterdam EIP Discussion
- Focus on selecting single headliner EIP per layer
- Key CL headliner candidates:
- EIP-7732 (ePBS)
- EIP-7782 (6-second slots)
- EIP-7805 (FOCIL)
- EIP-7919 (Pureth)
- EIP-7942 (Available attestation)
- Plenty of discussion on the best way to select a single headliner to start to form the Glamsterdam scope
- Participants felt it was too early to begin headliner selection today, and after checking with EL representation we decided to coordinate more closely with ACDE which needs more time
- Reflecting all of the discussion, we decided to wait for Glamsterdam headliner selection until
fusaka-devnet-3is live and healthy - Client teams still have time to assemble their opinions on headliner, but there seems to be early interest in a headliner that generally follows the “theme” of scaling
- We also highlighted the need for better community input as a way to surface to core developers what is best for Ethereum at this time
fusaka-devnet-3is still some time out, but we did agree that allocating two ACD calls, 1 for headliner discussion and 1 for headliner decision, made sense