Focus

Scoping project #5 (Execution Layer Integration for the Lean Chain) by testing an alternative architecture and probing the current spec state.

Done this week

Built a working PoC: a lean-style consensus client driving an UNMODIFIED execution client over the standard Engine API (fcU/getPayload/newPayload + JWT), instead of embedding reth as a library + ExEx (the approach in PR #1392). The same driver drives reth v2.3.0 and geth v1.17.3 (stock upstream Docker images) to: produce blocks, include a real tx, finalize it. Verified from the EL's own RPC.
Did the real integration - the actual ream binary (real 3SF, XMSS, PQ aggregation) drives unmodified reth over the standard Engine API via Ream's own new service (LeanExecutionService) reading real lean head/finalized from the fork-choice

There is no lean execution-payload spec. Verified against canonical leanEthereum/leanSpec - BlockBody is attestation-only, State has no execution field, no execution module exists. The lean block has no defined way to carry or commit to an execution payload. Execution is deliberately out of scope of the current consensus-only devnets.
Distinction that matters: the CL->EL control interface (today's Engine API) exists and is what the PoC reuses; there is no lean/PQ-specific version of it. The undefined piece is the lean-block <-> execution-payload binding.

Standard Engine API gives EL client diversity "for free" (demonstrated with 2 clients), but that win is time-limited: it holds only while lean execution stays EVM-shaped. Several Engine API fields become genuine semantic conflicts under PQ/EVM-2.0 (prevRandao vs XMSS RANDAO, KZG blob commitments, withdrawals, EIP-1559 fee fields).
Decisive unknown, unspecified in all current sources: will lean execution reuse an EVM-shaped payload (favors standard Engine API) or a new RISC-V VM (favors a purpose-built interface)?
The undefined lean-block <-> payload binding is the contribution opening: propose the binding, backed by the working Engine-API prototype.