Meeting Summary:
This was the final recurring breakout session for Fast Confirmation Rule (FCR) implementation, where Mikhail led client updates and technical discussions with team members including Boma, Nazar, Jun, Dmitrii, Roberto, and others. The team reviewed progress on client implementations, with Boma reporting test case updates and PR readiness, Nazar sharing integration work and spec test improvements, Jun confirming FCR branch passing nightly tests with some test generation bugs fixed, and Dmitrii continuing feature FCR merge in smaller chunks over the next two to three weeks. The group discussed several technical topics including client comparison using the FCR simulator, backend tests addressing gloss issues with safe execution block hash handling, and potential fuzzing of client implementations for security testing. A significant portion of the discussion focused on whether to change the safe block hash from justified to finalized when FCR is disabled, with participants debating the safety implications and potential user impact, particularly regarding RPC providers and Arbitrum’s previous use of safe block hash for deposits. The team also explored handling scenarios when CL nodes are down or restarting, discussing how implementations cache confirmed routes and the algorithmic fallback to finalized blocks after two epochs. The conversation ended with a discussion about post-loss fast confirmation challenges in GLOAS, particularly around confirming payloads from previous slots, where participants determined using PTC would be complex and potentially unsafe due to execution delays and reorg guarantees.
Click to expand detailed summary
Mikhail announced that this would be the last recurring breakout session for Fast Confirmation topics, as significant progress has been made in the area. The meeting was scheduled to begin with client updates, starting with Grentin, though the full discussion was not captured in the transcript.
Boma updated on test case progress and PR readiness, noting that switching to the Glamsterdam Debit Server branch was needed. Mikhail inquired about running the implementation on mainnet, suggesting it as a smoke test, and Nazar reported working on integration spec tests with some minor issues identified but resolved. Jun confirmed that the FCR branch passes the latest spec tests but noted the need for more thorough review of the implementation before running it on mainnet or DevNet.
Dmitrii reported that the FCR range merge to master is ongoing in smaller chunks and will take another two to three weeks, with a few bugs found during the process. He agreed to recheck the Lighthouse comparison failure issue today, as recent fixes might have addressed the problem. Mikhail mentioned the possibility of using the FCR simulator from EF VandaOps for comparisons, but Jun had not tried it yet. The team discussed ongoing DevNet testing, waiting for implementations from Prisma and Teku, and planned to run client comparison simulations once all implementations are ready. Backend tests and PRs were reviewed, addressing issues like the safe execution block hash and Fast Confirmation Test fixes. The group also considered implementing fuzzing for client implementations, with interest expressed but no final decision made.
Justin suggested asking the security team to implement agent swarm testing on FCR implementations as an alternative to fuzzing. Mikhail expressed interest in fuzzing but noted it depends on team capacity and bandwidth, and mentioned plans for client comparison testing on mainnet historical data to identify anomalies and bugs. The team also discussed a proposal to change the SafeBlock hash behavior when fast confirmation is disabled, with Justin explaining the rationale for using finalized instead of justified block hashes for safety reasons.
The team discussed whether to implement changes related to justified block hashes, with Mikhail expressing doubt about the necessity of the change due to uncertainty about current usage. Potuz provided a data point that Arbitrum previously used saved block hashes for deposits, though it’s unclear if they’ve since switched to finalized blocks. The discussion also covered potential issues with RPC providers and clients using the Fast Confirmation Rule, with potuz noting that while there might be some surface area for bugs with saved block hashes, the risk appears manageable given current implementation practices.
The team discussed the use of safe block cache and fast confirmation rules (FCR) in their system. They determined that using cached confirmed routes is generally safe as long as they are not older than two epochs, as the algorithm will automatically reset to finalized blocks if needed. The group also explored potential improvements to handle post-loss confirmation, but concluded that relying on PTC (Proof of The Correctness) for this purpose would be tricky and potentially unsafe due to execution delays and reorgs. The team noted that decoupled consensus will eventually deprecate the current FCR, making additional improvements to the existing system less practical at this time.
Next Steps:
- Boma: Wait for the particular release/version to pass the updated test cases, and have Pavel review the PR.
- Nazar: Update spec tests and CI once the latest release for spec tests is done.
- Dmitrii: Rerun the comparison tests with Lighthouse to check for the comparison failure issue.
- Justin: Reach out to Nikos from the security team to discuss spinning up their agent swarm on FCR implementations.
- Mikhail: Follow up asynchronously with PandaOps to run client comparison simulations once Prism and Teku are ready.
- All participants: Post any thoughts or further discussion on fuzzing client implementations in the Telegram group.
Recording Access: