SSZ Engine Api #2,July 10,2026

Protocol Calls & happenings
1

Agenda

Client and testing updates + progressives decisions

Meeting Time: Friday, July 10, 2026 at 13:00 UTC (60 minutes)

GitHub Issue

2

Meeting Summary:

The meeting focused on discussing Jacek’s comments regarding the Engine API and potential improvements to the REST API structure. Dustin explained Jacek’s two main points: the ability to coexist multiple HTTP paths on the same port for better client compatibility, and the need for a “top-up sync” mechanism to allow CL nodes to determine where to start syncing without relying on the EL’s ability to pull blocks from the network. The discussion revealed that while Geth currently returns zero for block information when states don’t exist, a “latest canonical block” approach could address the syncing challenges. The group also identified that several existing ETH namespace APIs (like ETH syncing and ETH logs) are currently specified in the Engine API but may need to be moved to the REST SSC API for consistency, though they noted the need to review which methods are still useful before making changes.

Click to expand detailed summary

Tamaghna led the SSEC Engine Breakout Room No. 2 meeting and provided updates on testing plans. The team decided to integrate SSE support from project ZKEVM into the EELS Amsterdam branch, followed by adding reference vectors and working on abstract implementation. Tamaghna also mentioned plans to move towards FastAPI OpenRPC in the short term and integrate execution API-related testing into EELS in the longer term.

Dustin represented Jacek in the meeting, discussing two main points regarding the REST API path setup and top-up sync capabilities. He explained that the current Engine API lacks a reliable way for clients to determine where to start backfilling when an EL’s head is behind the chain tip. Dustin also mentioned that having multiple quasi-paths on the same port could benefit unified clients, though it’s not a requirement for non-unified clients.

Dustin and Marius discussed unifying the REST API and CL REST API, with Dustin proposing that both should be treated as internal APIs of similar sensitivity level. Marius raised concerns about specification and implementation across different binaries, particularly regarding proxy requirements. The discussion concluded with Dustin explaining that namespace isolation through the Beacon API provides a systematic approach, using headers for versioning to maintain consistency across client and server implementations.

Dustin explained Jacek’s concept of “top-up sync” where the EL would be treated as a library and rely on CL to handle most gossip traffic, aiming to reduce duplication and improve efficiency. He noted that the current Engine API does not support this approach for optimistic syncing, as it requires the EL to pull blocks from the network, which is not feasible with the existing API. Dustin emphasized that using the current Engine API for this purpose is not viable.

Dustin and Marius discussed the challenges of block synchronization between Execution Layer (EL) and Consensus Layer (CL) nodes. They explored issues around determining the correct block to start syncing from, particularly when nodes have been offline for extended periods. Marius explained that ELs currently report the latest block they have state for, while Dustin argued that this approach isn’t ideal for syncing purposes. The discussion highlighted the need for better ecosystem consistency and a more efficient way to handle block synchronization without requiring full network fetches.

Marius and Dustin discussed improvements to block processing and synchronization, with Marius noting that Geth can now reorganize 90,000 blocks in 30 seconds compared to tens of minutes previously. They explored challenges around handling blocks without state information and discussed potential solutions including using a “trusted pivot” block and implementing a “get latest canonical block” API. Dustin emphasized that the goal is to fill gaps in the specification rather than force everyone to use a specific approach, and suggested using block hash contiguousness to verify chain lineage.

The team discussed implementing canonical block functionality, with Marius explaining that canonical blocks represent the most recent block where the CLL designated it as the head or canonical chain. Dustin raised concerns about whether this feature should be added to the Engine API, noting that while it might work as a JSON-RPC API, it doesn’t directly relate to the Engine API’s core functionality. The discussion highlighted the challenge of defining what constitutes a “full block” and ensuring semantic consistency across different Ethereum Layer 1 implementations, with FLCL suggesting both head and final block options might be needed.

Dustin and Marius discussed the need to standardize and specify various API methods, including those related to ETH syncing and logs, to ensure consistency across different clients and ports. They agreed that these methods should be reviewed to determine their current utility and whether they can be removed or consolidated into a single API. Marius committed to preparing a document explaining the current state and potential changes, which will be shared with the team and discussed in upcoming meetings to gather input from others who were not present. The group also noted the existence of a previous HackMD document by Jacek that covers some of the discussed topics and will be incorporated into the review process.

Next Steps:

  • Marius: Prepare a document explaining the choices to be made regarding REST SSE API, the reasons for past decisions, and what methods could potentially be removed. Share it in the groups and discuss it on ECDC to get opinions from other clients.
  • Tamaghna: Create a public document based on the transcript and discussions, including the explainer on the asset growth and the chain-following mechanism. Share it with the wider community for feedback.
  • Marius: Scope and review the list of current JSON-RPC methods included in the Engine API spec to determine which are still useful and which can be removed, ensuring the REST SSE API remains minimal.
  • Marius: Ensure the discussion points and documents are brought up in both the next call and ECDC for broader visibility and input.

Recording Access:

3

YouTube recording available: https://youtu.be/_i6gjV6kd80