SSZ Engine API #002
Transcript
Ask about this call
Answered from this call's summary and transcript only.
AI-generated — verify against the recording.
Call summary
Targets
- •Next SSZ Engine API call in 2 weeks (approx. July 24, 2026); top-up sync and namespace scoping documents to be circulated beforehand — 00:51:29
Decisions
- •Agreed SSZ Engine API must specify which ETH-namespace endpoints are available on the engine port, consistent with Beacon API encoding conventions — 00:43:54
- •ETH-namespace method list for SSZ Engine API should be as minimal as possible; no automatic carry-over from JSON-RPC engine spec — 00:49:50
Highlights
- Testing Updates:
- ·SSZ support from project ZKEVM being integrated into EELS Amsterdam branch; reference vectors and REST abstraction to follow — 00:05:05
- ·EELS planned to eventually serve engine requests as a temporary EL for CL testing; FastAPI/OpenRPC targeted short-term — 00:05:36
- Ssz Engine Api Design:
- ·Jacek (Nimbus) proposes REST path alignment with Beacon API namespace for coexistence on same port; especially relevant for unified clients — 00:07:46
- ·Top-up sync gap identified: current Engine API has no reliable way for a CL to determine where to begin backfilling to an out-of-sync EL head — 00:08:56
- ·Proposal: expose ETH get-latest-canonical-block (FCU-marked head) on engine port to enable CL-driven top-up sync without EL p2p — 00:36:30
- ·SSZ REST Engine API currently lacks equivalents for ETH-namespace methods (chainID, syncing, etc.) that existing JSON-RPC engine spec guarantees; needs explicit scoping — 00:43:54
Action Items
- •Marius Van Der Wijden — Prepare document explaining current ETH-namespace method list on engine port, rationale, and candidates for removal; bring to ACDE and ACDC for broader input — 00:49:11
- •Tamaghna Chourdhuri / Dustin — Publish public document on top-up sync design (incorporating Jacek's HackMD and chain-following mechanism) to gather input from absent clients — 00:50:08
Meeting chat35
- Soubhik
gm
- Justin Traglia
Gm
- Tamaghna Chourdhuri
Gmgm!
- Tamaghna Chourdhuri
Lets start in 5 min
- Jun Song
gm
- Sameer Agarwal
gm
- Łukasz Rozmej
and me
- Marius Van Der Wijden (M)
And you :D
- Dustin
yes, sure (re Nimbus/Jacek comments)
- Tamaghna Chourdhuri
https://github.com/ethereum/pm/issues/2145#issuecomment-4934505945 https://hackmd.io/siEIwl9QTlODSZ6DYH3iqg
- Marius Van Der Wijden (M)
How would 1 port work for non-unified clients?
- FLCL
1 port for both jsonrpc + rest?
- FLCL
Two different services, not sure if need to be united
- FLCL
A reverse proxy thing can do this
- FLCL
It sounds like we just should not prohibit it and that's it
- Dustin
https://discord.com/channels/595666850260713488/1295427781722898505/1525091128867557427
- FLCL
Move p2p and tx gossip from el to cl?
- Łukasz Rozmej
who is the child of who again? ;)
- FLCL
we need to store meta about most recent beacon inserted block with state and return it to you?
- FLCL
but you can also hold it on cl side?
- FLCL
unless you have db reset
- FLCL
what if you are on diff chain
- FLCL
how pivot can help if we have no state for it?
- Marius Van Der Wijden (M)
"We previously got an fcu for it"
- FLCL
final block sounds safer, maybe less efficient
- FLCL
maybe both head+final in case of having state
- FLCL
if we restify get block, we can return blocks/head, blocks/final or so
- Dustin
- Dustin
Jacek wrote a hackmd on it
- Dustin
on "top-up sync"
- Tamaghna Chourdhuri
https://hackmd.io/siEIwl9QTlODSZ6DYH3iqg This one right:)
- Dustin
yeah
- Marius Van Der Wijden (M)
Early call lets goo
- Justin Traglia
Reacted to "Early call lets goo" with 👍
- Tamaghna Chourdhuri
Lmao And I was thinking this might end in half an hour
Key decisions
Agreed SSZ Engine API must specify which ETH-namespace endpoints are available on the engine port, consistent with Beacon API encoding conventions
ETH-namespace method list for SSZ Engine API should be as minimal as possible; no automatic carry-over from JSON-RPC engine spec