Other comments and resources
Facilitator emails:
YouTube Stream Links:
Tweet thread - https://x.com/poojaranjan19/status/1953456098188627974
ACDC #162 Action Items
fusaka-devnet-4 is live! Focus on performance to identify any places to harden PeerDAS.ACDC #162 Summary
Fusaka
fusaka-devnet-3 showing excellent participation with successful testing
fusaka-devnet-4 launching tomorrow to simulate mainnet-like scale
BPO Schedule Discussion
fusaka-devnet-4 testing will validate actual target/max numbersfusaka-devnet-4 to parameters we know are safe to lock in; will adjust via subsequent BPOs pending mainnet analysisTimeline Concerns from Client Teams
Beacon API Updates
Glamsterdam Fork Planning
Glamsterdam Implementation Timelines
edit: updated comment on Glamsterdam timelines to clarify this was not a date for mainnet
The team reviewed and approved a VPO schedule for the Fusaka upgrade, with discussions around shipping timelines and testing requirements. Concerns were raised about the aggressive timeline for the September 1st release, leading to a proposal for extending the timeline to the end of September to allow for additional testing and code stabilization. The team also discussed various feature implementations including Fossil and EPBS, with decisions made on shipping timelines and integration approaches while considering community feedback and technical requirements.
The team discussed the VPO schedule for the Fusaka upgrade, with Justin presenting a proposal for three BPO forks approximately one month apart, targeting 21 BPOs with a limit of 32 BPOs per block. They agreed to move the dates forward slightly, with BPO 1 on November 24, BPO 2 on December 15, and BPO 3 on January 14, 2026. The team decided to proceed with shipping the VPOs even if the throughput numbers are lower than expected, as it would provide valuable data on scaling capabilities. They also briefly touched on testing updates for node synchronization and custody backfill features.
Matthew expressed concerns on behalf of Prism and Nimbus teams about the aggressive timeline for the September 1st release, highlighting the need for more testing and the fact that the code is not yet on the master branch. He emphasized the importance of having a stable devnet with no spec changes and all code on the trunk branch, as well as private mempool testing and exercising code paths on the trunk branch. The teams are advocating for an additional 4 weeks to the timeline, aiming for the end of September, to ensure a successful rollout.
The team discussed testing clients without the help of Cablock v2, noting that Devnet became stable after its introduction. They observed that private main pool testing was limited due to non-finality testing and circuit breaker triggers. Matthew expressed concern about unmerged code paths and the need for early and aggressive merging of feature branch changes, emphasizing the importance of avoiding issues that caused problems in previous testnets. Dustin added that achieving stability was challenging due to rapid changes in Defnet 1 and Defnet 2.
The team discussed the timing of merging code for the Mainnet release, with Matthew proposing a 4-week delay to the end of September to allow for additional testing and a devnet on trunk branches. Dustin and Manu agreed that more time would be beneficial for code stability, with Manu emphasizing the need for a final devnet on trunk branches before the Mainnet release. The team considered the possibility of conducting the Mainnet rollout at Dev Connect, though concerns were raised about attendance and the potential for issues during the rollout.
The team discussed the timing and implementation of the Holoski release, with Barnabas confirming a 2-month lead time and emphasizing that Mainnet is still planned for November. Matthew raised concerns about the need for non-finality testing and backfill functionality, suggesting that while trunk branch alignment is important, it might not be critical for a devnet. The team agreed to target Holoski for September, with Stokes proposing to focus on getting code onto trunk branches as a next step, while NFLaig presented a PR regarding beacon node API implementation and filtering options for consumers.
The team discussed the status of roll calls, which have been temporarily paused, and reviewed a PR related to slot and spec structure that deprecates the intervals per slot variable and defines explicit durations for deadlines as a percentage of total slot duration. Justin Traglia explained that merging this PR soon would allow work on Glancer down specs to proceed, as it’s needed for EIPs 778 and 782. The team agreed to merge the PR sooner than after Fusaka, despite Carl’s suggestion to wait 2 weeks, with Mark expressing concern about the costs of further delays.
Nixo presented a summary of stakeholder feedback on various EIPs, highlighting concerns about slot pipelining and the need for adequate notice for engineering costs. The feedback showed strong support for EIP-805 (Fossil) in conjunction with other options, with EIP-732 receiving the most support as a primary option. Jihoon then provided an update on Fossil, explaining its complexity for both CL and EL and demonstrating how it can be implemented and rebased on top of PBS.
Jihoon explained the implementation of Inclusion List (IL) transactions in a blockchain system, detailing how testers and builders handle IL transactions, and how validators and CL (Consensus Layer) enforce IL compliance. He described the process of validating IL transactions, checking gas availability, and handling equivocation. Justin Florentine asked about the implications of missing transactions and gas costs, to which Jihoon clarified that they check if transactions could have been appended to the payload based on gas availability and affordability.
The team reviewed performance metrics for block propagation and attestation times, with Maria reporting improvements due to a table correction and a fixed validator configuration at Klaytn. The 95th percentile block propagation time was reduced to 865ms, and the 95th percentile attestation time for missed slots improved from 2.5 seconds to 1.8 seconds. The team then confirmed PPS as the leading candidate for the Amsterdam headliner, with SFI and El selected as CEO and EL headliners respectively, which will unlock the first step of Glen scoping.
The team discussed the status and implementation of the Fossil and EPBS features, with broad community support for including Fossil despite its demotion from headliner status. Terence, who implemented both features, suggested that combining EPBS and Fossil in the initial fork would not be problematic, as their interactions are mostly orthogonal. Ansgar emphasized the importance of not delaying the Glamsterdam fork, proposing that CL headliners should not hold up the fork, even if CL headliners are not ready. The team agreed to proceed with implementing both features while continuing to evaluate their integration and potential impact on the fork timeline.
The team discussed the timeline for shipping features, with Terence suggesting early next year for SFI and potentially March or April, while Ansgar raised concerns about the EPBS implementation timeline. They decided to SFI EPBS 7.7.3.2 and CFI Fossil, with Justin explaining this would involve renaming the feature spec and rebasing 7.8.0.5. Ansgar expressed concerns about the EPBS readiness, but the team agreed to focus on Fossil for now and keep the option open to decouple the features later if needed.
=P?uL2E2)=P?uL2E2)YouTube Stream Links: