Meeting Summary:
The team reviewed the status of Fusaka Devnet-3 and discussed various technical issues including transaction propagation problems and sync bugs that are being addressed by different team members. They evaluated the integration of Nevermind with builders and discussed potential gas limit increases, while also considering proposals for slot component times and custody group balances. The team explored syncing capabilities in perfect peerless mode and discussed the implementation of blob syncing and backfill features, with plans to revisit these topics at the next meeting.
Click to expand detailed summary
The team discussed the status of Fusaka Devnet-3, where Barnabas reported 90% participation with two clients experiencing issues. Matthew mentioned ongoing work on a sync bug and implementing updates for the genesis validator set. Bharath explained that transaction propagation issues were occurring due to a flag disabling local transaction propagation in the reth builder, and proposed two potential solutions: using a direct RPC server or removing the flag entirely. The team agreed to continue exploring these solutions, with Bharath planning to provide an update once a final approach is determined.
Agnish reported on several issues, including a custody column mismatch in the DA’s guardian system and MEV-related problems, both of which have been fixed. He is investigating a peering issue affecting Erigon nodes and a Segfault crash, which he suspects may be related to incorrect slot indication. Agnish expects to resolve these issues in the next few days and mentioned that the fixes will be deployed to Devnet 3.
The team discussed the integration of Nevermind with builders, noting that while it replaces state providers, it still uses EVM for execution and requires more testing. They decided to keep the transaction gas limit at 16 million, addressing concerns about backward compatibility and defi transactions. Kamil reported progress on stateful testing and gas benchmarks, mentioning the need for further verification and improvements in worst-case scenarios. Marcin introduced a new tool to check modex repricing issues, while the team considered a potential increase in gas limits to 60 million in the future.
The team discussed two main topics: a PR for explicit slot component times and a proposal to increase the balance for additional custody groups. They decided not to merge the slot component times PR at this time, as it would deprecate intervals per slot but make no substantial changes. The team also rejected the proposal to increase the balance for additional custody groups, citing concerns about last-minute changes and potential issues with dynamic DA conditions. Finally, Jae presented a new report from Sunnyside Labs on high block loads and perfect PDAOs, highlighting the need for more bandwidth for sync nodes and discussing plans to retest with unrestricted bandwidth limits.
The team discussed issues with syncing in perfect peerless mode, where Manu explained that Prism currently fails because it doesn’t reconstruct peers from 64 columns. They tested several clients including Lighthouse and Grandine, finding that while full syncing is possible without blobs, the connection issues prevent proper operation. The team agreed that while supporting 72 blobs might be necessary before Glamsterdam, it’s not currently a blocker for Fusaka releases, with Parithosh suggesting they could scale up to 30+ blobs for Fusaka without immediately requiring 72 blob support.
The team discussed the need for a “perfect peer mode” feature, with Manu advocating for its inclusion to ensure nodes can sync correctly even without supernodes. Francesco raised concerns about the practicality of operating without peers sharing the desired columns, questioning how a node could function in such a scenario. Jae noted that while tested nodes correctly received their columns for the first 1,000 slots, having the feature would provide added security. Raúl suggested that reconstruction during idle time could address scheduling issues, but Francesco remained unconvinced about the long-term viability of operating without compatible peers.
The team discussed two main topics: blob syncing and backfill features. For blob syncing, there was consensus that while the feature isn’t immediately necessary for 30+ blobs in Fusica, clients should prepare for potential implementation, with Prysm expected to complete their implementation by end of week. Regarding backfill, while some clients like Prysm and Lighthouse are working on it, there was discussion about whether it’s a critical feature for the 4.0 launch, with Agnish noting it would require significant CPU resources and Matthew indicating it’s a substantial body of work for Lodestar. The team agreed to revisit both topics at Thursday’s meeting, with Mario requesting CL teams to provide implementation timelines for the blob syncing feature.
Next Steps:
- All CL teams to investigate how long it would take to implement perfect peerless syncing and provide updates at ACDC on Thursday.
- Nimbus team to work on optimizations to support higher blob counts.
- Lodestar team to continue working on implementing backfill functionality.
- Prism team to continue work in progress on implementing backfill.
- Sunnyside Labs to launch new devnets for testing as needed by client teams.
- All teams to review the PR on explicit slot component times and provide feedback before ACDC.
- Besu team to follow up async on the EIP 7951 benchmarking results.
- All teams to focus on fixing bugs in Nimbus and Lodestar this week before proceeding further.
- All teams to review the Sunnyside Labs report on high block loads and perfect peerless testing.
Recording Access:
chosen