The meeting focused on discussing updates and plans for various development networks (DevNets) and proposals related to the Ethereum protocol. The team reviewed PR 5094, which addresses checkpoint sync issues, and decided to merge it without the proposed optimization for data duplication. They discussed the timing of launching different DevNets, ultimately deciding to combine EPBS DevNet 2 and Amsterdam DevNet 0 launches rather than keeping them separate. Two proposals were presented for potential inclusion in the Hagoda release: EIP 7716 on correlated downtime penalties and EIP 8205 addressing a long-standing deposit front-run vulnerability. The conversation ended with an update on repricing work, including changes to state growth EIP 8037 and refinements to how state-related refunds are handled.
Click to expand detailed summary
The team discussed concerns about data duplication in beacon blocks due to execution requests being included both in payloads and blocks. Raúl proposed expanding the beacon block to include commitments that would be expanded by clients before passing to the state transition function, rather than duplicating data. The group debated whether to address this issue now or revisit deposit limits, with Nico noting that current limits are already exceeded at high gas limits. Enrico suggested implementing the solution in the networking layer to minimize impact on other components, while Parithosh raised questions about builders potentially ignoring limits if it affects their profitability.
The team discussed a proposal for handling execution payloads in the gossip layer, with Enrico explaining the technical approach and potential complications. Raúl and Enrico clarified that nodes would need the previous execution payload to build the next beacon block, and agreed that a fallback RPC mechanism could be used for cases where payloads aren’t received in time. Barnabas questioned whether the potential duplication concerns, particularly around 17 bytes in average cases, were worth addressing, to which Enrico suggested the decision could be postponed as it would only require networking changes rather than consensus layer modifications.
The team discussed proposal 5094 regarding data duplication in blocks and agreed to merge it to resolve current issues with checkpoint sync. They decided to proceed with the current solution and potentially revisit optimization changes later. The group also briefly touched on DevNet updates and potential limit adjustments, though specific details were not finalized.
The team discussed several PRs, with a focus on PR 5067 which clarifies Global Genesis questions and needs to be merged before the release. Brechy mentioned they are rebasing the PR due to changes in 5094, which will introduce merge conflicts. The team agreed to handle the PR on Monday, with Justin Traglia targeting to make a release today or tomorrow. The discussion then shifted to the launch timeline for DevNet 4, EPBS DevNet 2, and DevNet Zero, with Barnabas explaining the planned sequence of releases and potential challenges with stability. Terence suggested combining some of the releases due to time constraints, but Barnabas explained the reasoning for keeping them separate, particularly regarding EIP changes and blockable access lists.
The team discussed relaxing the timing for Glenstradam DevNet Zero to allow for a merged approach rather than separate development. Terence noted that the overlapping changes between systems were minimal, while Potuz and others expressed concern about wasting time by keeping them separate. The group agreed to skip EPBS DevNet 2 and instead target DevNet 0 of Glenstradam with the specified versions, allowing for testing with Vaults on the CL side. Barnabas suggested targeting local access list DevNet 4 on Thursday and potentially launching Glenstradam DevNet 0 on Friday, contingent on stability.
The team discussed the implementation of block-level access specifications, with Toni confirming that the necessary PR exists and can be found at blockaccesslist.xyz. The group debated whether to add new EIPs as stretch goals for the interop, with Barnabas proposing options including EIP-8045 (exclusion of slash validators) and EIP-8080 plus 8061 (turn rework and exit via consultation queue). The team ultimately decided to focus on stabilizing Glamsterdam devnet first before adding new features, with Parithosh suggesting staking EIPs could be considered as a stretch goal for interop testing.
The team discussed several EIPs and PRs, including formatting changes and the implementation of partial sales. They decided to merge some changes but deferred discussion on EIP 8045 to the interop meeting, as there were concerns about its potential impact on protocol states. Potuz raised questions about the BL spec changes, clarifying that only payload and engine API changes were needed, with no structural changes on the CL side.
The team discussed implementing changes to the payload response to remove duplicate data, with Barnabas suggesting it should be done now alongside the engine API changes. Nico raised concerns about potential impacts on ELTS handling and suggested consulting with EL developers before proceeding. The group agreed to open a PR for the execution API changes to review with EL developers, though Potuz initially wanted to delay this as a post-interop optimization. The team also briefly discussed and approved a trivial change proposed by Justin in pull request 5113.
Oisin presented an EIP called “correlated downtime penalties” aimed at addressing issues with liveness failures in the network. The proposal suggests penalizing correlated downtime more significantly to incentivize better decentralization and reduce the risk of mass slashing situations. Oisin highlighted that the penalty would spike at the beginning of downtime to prevent larger entities from having an advantage over smaller organizations. The proposal primarily impacts larger operators, with solo stakers and geographically diverse stakers seeing no changes. Stokes suggested creating an early proof of concept implementation to de-risk the scope before including it in Hagoda.
Dima presented EIP-8205, proposing a pre-registration mechanism for validator keys to address the deposit front-run vulnerability in delegated staking. The solution would allow staking protocols to verify that a validator’s withdrawal credentials match expectations before making deposits, providing an optional safeguard against front-running attacks. Barnabas questioned whether the solution was overcomplicating the protocol, suggesting it could be addressed on the application side, while Dima explained the current complexity and costs for protocols like Lido. Maria provided an update on the repricing work, noting that the Lambdsterdam team resolved open issues on EIP-8037 regarding state-related refunds and gas charging.