Meeting Summary:
This was the first ever SSID Engine API breakout kickoff meeting led by Tamaghna, focusing on reviewing specifications, discussing implementations, and planning testing for the new API. The team discussed moving the fork from URL parameters to headers, with Łukasz suggesting they could ship it before Glamsterdam and make it mandatory between that and the next fork. They debated versioning options between Engine V1 and V2, with consensus leaning toward Engine V2, and discussed keeping both JSON-RPC and SSZ channels open during a transition period. The group reviewed payload retrieval methods and unifying new payloads with witnesses, with Developer explaining the proposed path would be more compatible with the rest of the SSN specification. Jun from Prism reported that their implementation was mostly ready and working well with Aragon, while Dustin noted that Euthrex and Nethermind were also ready. The team decided to keep using current types rather than implementing 7688 stable containers for simplicity, and Justin suggested moving from weekly to bi-weekly breakout calls.
Click to expand detailed summary
The meeting began with technical difficulties regarding audio quality, which were resolved. Tamaghna confirmed that Marius would not be attending due to personal reasons but had left comments in the issue discussion for review.
Tamaghna led the first SSID Engine API breakout session to discuss specifications, implementations, and testing. The team discussed moving the fork from the URL to headers, with some members like Iván confirming they had reviewed the spec and implemented it. The group also debated versioning, with Jun supporting /eth/v1/engine/XYZ, and discussed whether to maintain both JSON and SSZ channels simultaneously.
The team discussed implementing SSZ and JSON-RPC protocols, with Łukasz suggesting a flexible approach allowing clients to adopt the new capabilities on their own schedule. Jun mentioned that Prism already has a fallback mechanism to JSON-RPC when capabilities calls fail, and recommended having a transition window for both SSZ and JSON-RPC engines to coexist. Dustin raised concerns about the reliability of optional endpoints and suggested making the new protocol mandatory in a future hard fork, which Łukasz and Jun supported, agreeing that a transition window should be implemented between the go-fork and hard fork.
Łukasz proposed shipping something before Glamsterdam to allow for a transition period, suggesting it would be mandatory by design. The team discussed the timing of implementation between different fork schedules. Tamaghna then shifted the discussion to repeated retrievals of payloads via get payload and time to live comments, referencing a GitHub pull request for further review.
The team discussed a proposal to change the path for the new pillar with weakness to make it more compatible with the rest of the SSA specification. They reviewed a GitHub comment from Lucas that outlined the suggested path: engine V1 or V2, then fork, then payload, then witness. Jun asked about specifying the payload ID, and Łukasz clarified that it should be a POST call rather than a query parameter. Tamaghna proposed making this version the default and discussed rolling it out as a client flag before making it mandatory post-Tegota or post-iStart, noting that client implementation timelines and updates still need to be addressed.
Łukasz reported that most implementation work is complete except for the witnessing part which needs improvement and requires adjustments based on ongoing spec changes. Tamaghna discussed progress on writing tests for containers, including randomization features, and mentioned waiting for reviews from the SEAL team before proceeding with further development. Tamaghna also invited other client teams to share their progress on the implementation work.
The team discussed the readiness status of various clients for the upcoming launch. Jun reported that Prism is mostly ready with only minor fixes remaining, while Ivan confirmed they are also ready with micro benchmarks running on mainnet. The group agreed that a dedicated DevNet is not necessary for this launch and can be added to existing Glam devnets once clients are ready. The team also discussed the potential implementation of stable containers using the 7688 specification, with Jun noting that it would be an opt-in feature for Prysm, though it would take a few days to merge into the devnet branch.
The team discussed whether to implement progressive lists using 7688, with Tamaghna initially suggesting it would be beneficial but agreeing to proceed with the current approach for simplicity. Barnabas requested clarification on the benefits of progressive lists, and Dustin explained that it would avoid having to calibrate container sizes and potentially redefine types later. The group ultimately decided to keep the current implementation for now and consider transitioning to 7688 in the future, with Justin noting that speed improvements would primarily come from SSN rather than this specific change.
The team discussed updating PR793 as a priority to serve as a single source of truth, with Jun identifying this as the main blocker. Dustin mentioned that Jacek’s comments about top-up sync and specific semantic changes should be discussed separately. The group agreed to transition from weekly to bi-weekly breakout calls, with Justin taking responsibility for making this change.
Next Steps:
- Tamaghna: Refine and complete the SSZ static tests for the containers, including adding more randomization (possibly with Hypothesis), and get reviews from the SEAL teams to merge the code.
- Tamaghna: Provide an update on the testing status, including the use of Hypothesis and integration with Hive/consumer side, in the next call.
- Jun: Apply the fixes from this call to the Prism implementation, such as excluding the fork from the endpoint.
- Łukasz: Adjust the Nethermind implementation to any final spec changes discussed in this call.
- Justin: Change the frequency of the breakout call to bi-weekly.
- All Client Teams: Update PR793 as soon as possible to serve as the single source of truth for the spec.
- Dustin/Jacek: Discuss Jacek’s comments on the top up sync and the specific semantic changes he wants from the Engine API, as described in PR793.
Recording Access: