Agenda
Agenda
- blob-devnet-0
- bal-devnet-3
- bal-devnet-4
- epbs-devnet-1
- debug RPC update
Breakouts: Undecided, likely one BAL + ePBS breakout room.
Meeting Time: Monday, March 30, 2026 at 14:00 UTC (60 minutes)
Agenda
- blob-devnet-0
- bal-devnet-3
- bal-devnet-4
- epbs-devnet-1
- debug RPC update
Breakouts: Undecided, likely one BAL + ePBS breakout room.
Meeting Time: Monday, March 30, 2026 at 14:00 UTC (60 minutes)
The 76th ACD testing call discussed progress on partial cell implementations, with multiple teams reporting readiness for DevNet 3 launch including updates on gas limits, 2D gas accounting issues, and client-specific developments. The team reviewed various technical implementations and specifications needed for the upcoming DevNet 3 launch, including builder API changes and required specification updates for EPBS. The conversation ended with discussions about targeting specific dates for DevNet 3 launch and plans for future development including DevNet 4 and Glam Student Zero.
Barnabas opened the 76th ACD testing call on March 30th, noting lower attendance likely due to the concurrent ETHCC event. The meeting began with technical issues as participants joined late, and Barnabas asked about potential attendees from HCSE. Okash was requested to start the stream, though the actual discussion content was not captured in this transcript segment.
The team discussed the progress of partial cell implementations, with Prism and Lighthouse planning to have trunk-ready versions by the end of April. The Pentopâs team announced plans to test these implementations on 300,000 validators. Matthew reported making progress and expected to be ready for DevNet in the next week or two. Barnabas opened a new PR targeting EIP-8136 and sought feedback from the client teams. The discussion briefly touched on NFTEvNet 10, though details were limited due to Mariusâs absence.
The team discussed the requirement for Ethereum 70 (ETH70) for the fork, particularly regarding the gas limit and potential syncing issues. Barnabas noted uncertainty about whether an EIP to raise the gas limit would be added before the fork, suggesting ETH70 could remain optional for now. The group confirmed that Nethermind, Ĺukaszâs implementation, and Besu already support ETH70 and ETH71, with some uncertainty about activating all three versions simultaneously.
Stefan reported that the main blocker for DevNet 3 is issue 837, particularly regarding 2D gas accounting, which causes orphaned blocks when running EVM fuzz scenarios with multiple clients. Spencer announced plans to release additional tests to address edge cases, with no spec changes planned. The team discussed forming a group including representatives from each client team to focus on resolving the 2D gas accounting issues, with Spencer suggesting this could help accelerate progress on the consensus-related problems.
Ĺukasz reported that many testing issues have been resolved and the system is now comparable to other clients, though parallel processing is still pending and a launch next week, possibly on Wednesday, remains optimistic but possible.
The team discussed the readiness of DevNet 3, with Daniel confirming they are prepared for next weekâs launch after completing tests in Beso Networks, though additional testing with Curtosis is still needed. Barnabas announced that discussions about DevNet 4 and merging EPBS with block access list should wait until after DevNet 3 launches. Potuz reported that Prism is nearly ready, with most issues resolved including blob and peering problems, and Barnabas requested client teams to push their changes to the EPPS.net 1 branch before spinning up the network.
Eitan reported that Lighthouse could be ready for Genesis this week, with Alpha 4 spec changes merging to the trunk branch tomorrow and checkpoint sync expected by weekâs end or early next week. Barnabas requested to be notified when the changes are in a feature branch to begin testing. Potuz expressed concerns about making checkpoint sync mandatory before launch, citing potential issues if clients like Lighthouse fail to implement it properly, but acknowledged that implementing it might be straightforward for Lighthouse given its minimal required changes.
The team discussed updates on two projects: Nimbus and Lodestar. Caleb reported that Nimbus Alpha 4 upgrade should be completed by Thursday or Friday, with checkpoint sync implemented. For Lodestar, Nico indicated a similar timeline for completion by weekâs end. The team agreed to exclude blobs from the initial launch but potentially add them later based on client readiness. Barnabas proposed targeting April 15th for Glam Student Zero launch, with April 22nd as the absolute latest date to ensure a stable merged devnet before the end of the month.
The team discussed testing the builder API in isolation before merging it with EPBS, with Potuz expressing concern about potential hardware changes. Bharath clarified that the new builder API would involve new features like proposal preferences and builder preferences, which could be considered a hard fork change. Barnabas proposed targeting the first half of April to finalize the spec and make necessary API changes, while also asking about the difficulty of merging the feature branches for VALs and EPBS.
The team discussed a required specification change for EPBS regarding 4-choice updates for canonical blocks. Potuz explained that the current implementation allows for optional execution but needs to be changed to mandatory. Ĺukasz confirmed that Nethermindâs master branch and version 1.37 would support these changes. Barnabas outlined the specific API changes to be implemented for the devnet, and the team agreed these changes should not be problematic to implement. The conversation ended with a note about targeting Alpha 4 specifications for the second half of April, contingent on successful Nethermind and APPS events.
Bharath presented two proposed PRs for the builder API that would make implementing an external P2P builder easier, including SSE events for proposal preferences and APIs for creating envelopes with beacon state transitions. The team confirmed these changes donât require a hard fork for DevNet 1, though Potuz noted potential future hard fork needs might emerge during testing. The group also discussed the workflow for broadcasting proposal preferences, with Nico clarifying that nodes should only broadcast for the next epoch unless a node hasnât previously broadcasted for a validator. Dan raised awareness about Frederickâs security review tool and proposed implementing deeper client implementation reviews before DevNet launches.
@C7=sgae)@C7=sgae)@C7=sgae)YouTube Stream Links: