Meeting Summary:
The team explored various technical improvements to transaction processing and block access lists, including the potential benefits of incorporating gas usage information and read operations to optimize transaction scheduling and parallel execution. They discussed concerns about gas exhaustion and early reversion issues, while also addressing the status of devnet testing across different client implementations and ongoing specification changes. The conversation ended with discussions about read location features in block access lists, performance benchmarking results, and the importance of including full block access information in debug logs for troubleshooting purposes.
Click to expand detailed summary
The team discussed including gas used values in block type access lists to improve transaction parallelization. Toni explained the motivation behind this change, aiming to avoid worst-case scenarios where transactions are unevenly distributed across cores. The group considered the potential benefits of including gas used information, with Karim asking about the inclusion of read operations. Toni noted that the default would be not including this information, but the team should consider its potential benefits.
The team discussed the potential benefits of including gas usage in block access lists to optimize transaction scheduling. Dragan argued that the improvements would be minimal compared to the complexity of implementation, as parallel execution could already achieve significant speedups in worst-case scenarios. Toni agreed, suggesting that the current approach might be sufficient, and the team decided to revisit the topic during the DevConnect event. Mark introduced a new consideration, noting that parallel execution in Ethereum could lead to gas exhaustion issues, which could be mitigated by using separate gas ports for each transaction.
The team discussed a gas usage calculation issue where transactions that revert early can appear to use more gas than expected, potentially causing blocks to run out of gas prematurely. Mark explained that while this could be a concern for full blocks, the computational cost of verifying gas usage at the end of block processing is relatively low, making it a “nice-to-have” feature rather than a critical security concern. The group agreed to revisit this topic during future DevConnect and Breakout calls without making a final decision at this meeting.
The team discussed the status of devnet testing and client implementations. Several clients reported issues with old fork tests, with Geth, Besu, and Nethermind indicating they were ready for devnet testing despite some test failures. Felipe explained that there were ongoing spec changes affecting all forks, particularly around block access lists and gas charging, which were causing test failures. The team agreed to connect Chome with Felipe and Rahul to clarify whether the test failures were due to implementation issues or testnet problems, while Toni suggested that the devnet could proceed once the client teams confirmed their readiness.
Toni and Felipe discussed their PRs related to gas charging and state tracking, with Felipe emphasizing the need for stable tests and targeting Amsterdam release first. They agreed to focus on refactoring specifications for gas charging after the Amsterdam release. Stefan requested clients to run the EVM-fuzz scenario for spam tests in their Klaytn testnets. The conversation ended with a discussion on whether to include reads with REITs, with Gary’s recent benchmarks to be considered.
The team discussed the inclusion of read location in the BAL (Block Access List) and its potential benefits for optimizing block execution and increasing network limits. Gary presented benchmarks showing significant performance improvements (8-10x faster) with read-heavy scenarios, though Toni noted the need for more data points across different clients and state sizes. The group agreed to keep the read location feature in the EIP for now, while planning to compare implementations with and without it in real-world testing. They also discussed the importance of including full BAL in debug logs for easier troubleshooting of mismatches between clients.
Next Steps:
- Toni: Review Felipe’s gas-charge split PR and remove overlapping changes from own PR, keeping only the state tracker refactoring
- Felipe: Release a patch for tests with spec changes needed for Block Access Lists, focusing on Amsterdam first before addressing all forks
- Client teams : Run the EVM fuzz scenario from the Spammer tool
- Client teams : Reproduce Gary’s benchmark analysis individually to provide more data points on read location performance
- Client teams : Test benchmarks with double the state size to validate performance impact
- Chome : Contact Felipe and Rahul regarding Hive test failures to determine if issues are client-side, devnet, testnet, or hive-related
- Stefan: Share an example of the debug endpoint implementation in the research channel, including the curl request format
- Client teams : Consider implementing the debug endpoint that dumps block and generated block access list on errors for easier comparison
- Toni: Work on scheduling and announcing the in-person meetup at DevConnect, ensuring remote participation options via Zoom or similar
- Toni: Keep everyone updated on DevConnect meetup details and timing
Recording Access: