Skip to content

feat(l1): engine REST/SSZ API#6770

Draft
iovoid wants to merge 1 commit into
mainfrom
feat/engine-rest-ssz-793
Draft

feat(l1): engine REST/SSZ API#6770
iovoid wants to merge 1 commit into
mainfrom
feat/engine-rest-ssz-793

Conversation

@iovoid
Copy link
Copy Markdown
Contributor

@iovoid iovoid commented Jun 1, 2026

Motivation

We want to reduce the overhead of JSON serialization/deserialization for the large objects handled by the engine API. One of the proposals to do so is ethereum/execution-apis#793

Description

Most of the PR consists of boilerplate: defining RPC objects, route handlers and serialization/deserialization logic.

Prototype implementation of the REST + SSZ engine API proposed in
ethereum/execution-apis PR #793. Coexists with the existing JSON-RPC
engine API on the same authrpc port (:8551) — JSON-RPC behavior is
unchanged.

Surface (all forks Paris → Amsterdam):
  GET  /identity                     ClientVersionV1 array (JSON)
  GET  /capabilities                 supported_forks + endpoint limits (JSON)
  POST /{fork}/payloads              newPayload over SSZ
  GET  /{fork}/payloads/{id}         poll built payload (SSZ envelope)
  POST /{fork}/forkchoice            forkchoice update + optional build trigger
  POST /{fork}/bodies/hash           bodies by hash (per-fork shape)
  GET  /{fork}/bodies?from=&count=   bodies by range
  POST /blobs/v{1..4}                blob + cell-proof retrieval

Reuses the existing handle_new_payload_v* / handle_forkchoice helpers;
SSZ handlers convert to internal Block + dispatch through the same
business logic the JSON-RPC handlers use. Amsterdam BAL is regenerated
via Blockchain::generate_bal_for_block (mirrors JSON-RPC V2 path).

Measurement (tooling/engine_bench + crates/networking/rpc/benches):
microbenches and an end-to-end harness compare JSON-RPC vs REST/SSZ
encode/decode and end-to-end latency for newPayload, getPayload,
blobs, bodies. SSZ wire size ~50% of JSON; SSZ encode ~250× faster.

Known limitations (documented inline):
- Amsterdam /blobs/v4 returns empty cell bytes (mempool lacks per-cell
  storage); proofs are populated where available.
- blobs/v2 vs blobs/v3 all-or-nothing vs partial semantics share the
  same code path today (mempool lacks Osaka-aware partial state).
- handle_new_payload_v3's expected_blob_versioned_hashes parameter was
  made Option<Vec<H256>>; JSON-RPC callers wrap in Some(_), REST
  callers pass None (the EL recomputes from txs per spec).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant