Meeting Summary:
The meeting focused on discussing the implementation of the Fast Confirmation Rule (FCR), which aims to reduce confirmation time from 13 minutes to 13 seconds, with plans for client testing by March end and production use in Q2. The team reviewed various pull requests and technical issues related to execution APIs, including discussions about method implementations, API organization, and concerns about specific PRs and technical complexities. The conversation ended with plans to address version topics in future discussions and decisions about deferring certain consensus-related changes to relevant representatives.
Click to expand detailed summary
Julian presented the Fast Confirmation Rule (FCR), a new Ethereum Foundation rule that reduces confirmation time from 13 minutes to 13 seconds, providing a strong layer 1 confirmation within 13 seconds. He explained that FCR offers benefits for exchanges, L2s, and bridges, with implementation requiring only a flag enablement in clients and no additional work for RPC providers. The first clients are expected to be ready for testing by the end of March, with production use anticipated in Q2. Julian noted that while different clients may return different safe blocks during the transition, the Ethereum Foundation is supporting RPC providers in informing customers about the change.
The meeting focused on discussing the implementation of the Fast Confirmation Rule (FCR) and its integration with the JSON RPC API served by execution clients. Julian explained that while the FCR is a consensus layer rule, it can be queried via execution layer clients by repurposing the safe block tag, replacing the current justified block mechanism with a fast-confirm block mechanism. JVN asked about the removal of justification and finalization concepts, to which Julian clarified that FCR offers a different latency trade-off while maintaining safety through a built-in safety net that prevents reorders in most cases. The conversation ended with plans to discuss specific GitHub pull requests related to execution-apis.
The team discussed the merging of a pull request for the “Testing Build Block” method and considered next steps. Felix and Chase agreed that this method should be implemented by execution clients but noted it’s not required for all clients. They also discussed the need to develop a mechanism for creating different spec profiles to better organize and categorize API methods, particularly to distinguish between methods required by execution clients and those used between the consensus and execution layers.
The team discussed merging a feature that is already implemented in several clients including Geth and Reth, with Chase working on a PR for Nethermind. They agreed to proceed with merging the change since most clients already have it implemented, with the exception of Nethermind which will be addressed separately. Mercy raised concerns about PR #297, noting that only two clients (Losta and Nimbus) responded, and there was no clear consensus on how to proceed, though Lotas indicated they didn’t mind agreeing with Nimbus’s approach.
The team discussed two technical issues. Regarding the first issue (297JW2 secret), Mercy reported bringing it up to SCDC last Thursday, but received mixed responses from Lasta and Nimbus, with some complexity concerns about 302 or 297. Felix determined that since there was limited engagement and the issue was old, the appropriate action would be to close it. For the second issue (pull request 771 regarding get transaction by Nance), Felix explained that while the idea was not bad, the implementation would require significant engineering work including updating transaction indexing and managing indexes, making it unlikely to be implemented soon.
The team discussed several pull requests and issues related to the execution APIs. Felix expressed concerns about the need for a new RPC endpoint to retrieve transaction hashes by sender, questioning whether it was necessary given that transaction hashes can typically be derived from the input data. The group agreed that this feature would require additional indexing and might have limitations on the time window for which transaction data is available. They decided to defer discussion of engine API changes to Mikhail and noted that consensus-related changes would require input from consensus client representatives. The conversation ended with plans to address the version topic in the next meeting.
Next Steps:
- Julian: Put Telegram contact in chat for FCR questions
- RPC providers: Inform customers about the fast confirmation rule change and safe block tag repurposing
- Simsonraj: Start working on RPC test channel and actual tests for error code spec
- Mercy: Make announcement to clients about the merged error code spec
- Chase: Fix conflicts in testing build block PR after morning merges
- Chase: Push PR to Nethermind for get storage values implementation
- Felix: Merge get storage values spec (PR 756)
- Mercy: Inform Nico about decision to close PR 297
- Felix: Review the use cases and discussion in the get transaction by nonce issue when time permits
- Mikhail: Review and merge engine init PR 753
- Mercy: Determine appropriate forum for discussing ZKVM REST endpoint PR 773
Recording Access: