Meeting Summary:
The team reviewed updates on DevNet 1 and discussed plans for DevNet 2, including optimizations and spec clarifications, with a target launch date of next Wednesday. Performance testing and benchmarking efforts were discussed, focusing on gas limits, state roots, and batch I/O, with the team agreeing to start shadow forks and test parallel execution. The group also addressed potential vulnerabilities related to block-level access lists and state locations, exploring solutions and discussing updates to Engine API methods and metrics for benchmarking across clients.
Click to expand detailed summary
The team discussed updates on DevNet 1 and DevNet 2. Stefan reported that DevNet 1 went well, with most clients agreeing and fewer forks, despite some syncing issues. DevNet 2 is planned for next week, with a focus on optimizations and spec clarifications. The team also touched on EIP 7778, which recently had a change reverting it to its original state. The exact launch date for DevNet 2 was not specified, but it was noted that EIP 7928 is not blocking the launch.
The team discussed the launch of DevNet 2, aiming for next Wednesday with a gas limit of 150 million to support reasonable state growth. Toni noted that Geth and Besu clients are ready for optimizations like parallel execution and state root computation, while Marc reported progress on Nethermind’s parallel transaction execution and state recomputation. Jochem explained plans for benchmarking on a mainnet shadow fork to test the impact of BloT and optimizations, with Toni suggesting a focus on consensus-related tests and new changes in DevNet 2, such as the BAL payload and PoW EL block separation.
The team discussed performance testing and benchmarking efforts, focusing on gas limits, state roots, and batch I/O. They agreed to start a shadow fork and a fork of BloT to test parallel execution and batch I/O. Toni emphasized the need to clarify with clients about higher gas limits and potential RLP size limits. The group also discussed the interplay between read I/O and execution, noting that state root calculations could compete for CPU resources. They decided to compare performance with and without batch I/O enabled, using realistic state sizes and higher gas limits. Finally, they briefly touched on updates to the Engine API methods, with Mikhail’s comments still under review.
The team discussed the handling of Block Access List (BAL) data between CL and EL clients, particularly focusing on whether BAL should be an optional field in the payload call. Mikhail and Toni debated the merits of making BAL optional versus requiring its inclusion, with Toni expressing concerns about the complexity of optional fields and the need for EL clients to fetch missing BAL data asynchronously. The team agreed to maintain the current approach of requiring BAL inclusion and implementing the two new Engine API methods defined in the PR, while acknowledging that this might be revisited in the future. They also briefly touched on the topic of access clarification, noting that Felipe and Rahul had created tests for edge cases and clients had been passing them.
The team discussed a proposal about gas handling and block access lists, where Jared explained that the current specification is acceptable to prevent potential attack vectors. Stefan presented a document on standardized DAO traces using OpenTelemetry, which is not a requirement for devnet 2 but would help in benchmarking and visualizing metrics across clients. The team agreed to review and implement the metrics in a way that allows for benchmarking and testing optimizations, with a focus on having consistent results across clients.
The meeting focused on discussing potential vulnerabilities and inefficiencies related to block-level access lists (BALs) and state locations in Ethereum. Toni presented a scenario where malicious proposers could exploit the lack of mapping between state locations and transaction indices, leading to invalid blocks that waste resources through batch I/O and computation. The group explored three possible solutions: doing nothing, removing state locations from the BAL, or adding first-access indices to the BAL, with the latter being the most elegant but potentially increasing block size slightly. The team agreed to further investigate this issue, particularly for Ethereum 2.0, and to consider adding malicious block scenarios to their test framework. Additionally, Jared raised a separate issue regarding the lack of receipts in test fixtures, which is blocking Geth’s progress towards DevNet 2, and Felipe sought consensus on recent updates to self-destruct and self-transactions, which the group appeared to agree on.
Next Steps:
- Stefan: Launch DevNet 2 by next Wednesday and test clients regularly before launch
- Toni: Clarify on ACDE or ACDT with clients if they’re ready for higher gas limits to avoid RLP size limits or other issues
- jochem-brouwer: Start shadow fork of mainnet and possibly BloTNet for benchmarking once DevNet 2 is running
- jochem-brouwer: Conduct benchmarks comparing parallel execution with and without batch I.O. enabled to determine if state locations in BAL are needed
- Marc : Continue work on parallel transaction execution and state recomputation
- Toni: Incorporate Jochem’s comment into the “what access means” PR that was merged
- Stefan: Get clients to implement OpenTelemetry traces or standardized metrics for BAL performance testing, particularly for prefetching and parallel execution
- All clients: Review Stefan’s document on standardized DAO traces and provide feedback
- All clients: Think about how to invalidate malicious blocks with incorrect BALs as early as possible in the execution process
- All clients: Consider the malicious block scenario when setting up test frameworks for DevNet 3
- felipe: Add receipts to test fixtures to help with debugging, particularly for receipt root mismatches
- felipe: Get consensus and ensure all clients agree on self-destruct and call-to-self log emission rules for DevNet 2
Recording Access: