**Date:** 2026 / 04 / 29
**Hosts:** Raul / Potuz / Jacek
**Time:** 10:00

**Topic:** EL/CL Sync Architecture — Short-term (Glamsterdam) decisions and long-term direction

---

## 1. Meeting Goals

The session aimed to produce actionable decisions on:
1. **Short-term:** EIP-8237 (Potuz's proposal) — go/no-go for Glamsterdam
2. **Long-term:** Future of node architecture and EL/CL interaction model

Format chosen: "sandwich" — short-term scope first, surface architectural blockers, dive into long-term, then return.

---

## 2. Background: How Sync Works Today (per Potuz)

- Node starts → checkpoint sync → FCU sent to EL → EL syncs autonomously
- CL downloads blocks **with payloads**; validates block hash to keep CL/EL state-transition functions in sync (parent block roots, timestamps, withdrawals, deposits, execution requests)
- Block hash check can be done by the CL directly (via RLP) or delegated to the EL via `newPayload`
- EL replies "valid" or "syncing — block hash OK" → CL proceeds optimistically
- Both sides eventually converge; live operation continues via gossip

**Why the dual validation matters:** If CL and EL validate independently without a shared check, both can be locally valid but **out of sync** (different withdrawals, execution requests, block hashes), invalidating the chain.

---

## 3. EIP-8237 (Potuz's Proposal)

### Core Idea
With Gloas, the CL no longer needs the execution payload to perform its state transition. The proposal:
- **Remove range-sync of payloads on the CL entirely**
- Keep gossip, EL sync, and CL sync **unchanged**
- Add an **accumulator on the block header** so that when CL and EL converge, both can verify their independent chains agree on all shared fields

### Trade-offs
- ✅ Minimal change to CL sync logic — Potuz: "I don't need to change one line of code"
- ✅ Avoids downloading payload data twice
- ❌ Adds a header accumulator (new consensus field)
- ❌ Forecloses the longer-term architecture of moving payload distribution fully to the CL network

### Storage Reality Check (Polled)
| Client | Stores Execution Payloads? |
|---|---|
| Nimbus | Yes (full historical) |
| Erigon (Caplin) | Yes |
| Prysm | No (delegates to EL via engine API) |
| Lighthouse | No (blinded) |
| Lodestar | No (blinded) |
| Teku | No (blinded) |

---

## 4. Alternative: Jacek's "Top-Up Sync" Proposal

Documented in a HackMD posted that morning. Architecture already used by **Nimbus** and **Erigon (Caplin)**:

- CL drives the EL as a **deterministic block-execution library**
- CL fetches historical execution payloads on the **CL p2p network**
- CL queries EL head, then feeds missing payloads one-by-one (batchable later)
- Removes the need for execution clients to serve historical blocks on devp2p
- **Preconditions:** Both layers must be able to checkpoint/snap sync within the weak subjectivity period (~5 months); SSZ-based engine API; mempool networking eventually moved to CL

### Block Hash Verification Options under Top-Up Sync
1. Lockstep CL/EL sync (slow)
2. Optimistic CL with RLP verification on CL side (Lighthouse, Nimbus do this)
3. **Use Potuz's accumulator** — removes RLP requirement from CL
4. Hard-code RLP encoding into spec as opaque bytes (analogous to SSZ-on-EL)

---

## 5. The Three Possible Futures

| Path | Description |
|---|---|
| **A** | Adopt EIP-8237 fully → remove CL payload sync, mandate accumulator |
| **B** | Adopt top-up sync fully → deprecate EL devp2p block sync |
| **C** | Status quo middle ground → both protocols available, free-for-all |

Jacek's position: B is the long-term direction; preserving the CL payload-by-range RPC during Gloas keeps B reachable. Fully adopting A closes the door on B.

---

## 6. Key Disagreement: Sync Complexity

**Potuz:** Implementing range-sync of separated blocks + payloads is genuinely hard — Prysm is currently downscoring peers due to incompatible block/payload pairings. Requires interleaving, peer-attribution logic for bad data, etc.

**Jacek/Lion/Lodestar:** Already implemented; not dramatically complex. Lodestar specifically has implemented the new sync and would resist removing it.

**Critical correction during meeting:** Geth (and apparently other ELs, "since 2–3 months ago") now accept FCU **without** a payload to initiate snap sync. This was historically a blocker and changes the choreography options significantly.

---

## 7. Room Position on EIP-8237

Effectively rejected for Glamsterdam:
- **Against (for Glamsterdam):** Lighthouse, Lodestar, Nimbus
- **For:** Prysm (Potuz)
- **Partially supportive:** Jacek wants only the accumulator portion; Geth dev sees it as the only realistic option for non-merged clients but agrees direction is top-up sync

**Decision:** Do **not** include EIP-8237 in Glamsterdam. Revisit in H-fork or later.

---

## 8. Decisions Reached

1. ❌ **EIP-8237 dropped from Glamsterdam**
2. ✅ **Preserve `execution_payload_by_range` RPC on CL libp2p** (keeps top-up sync future open)
3. ✅ **Pursue a small, tight "choreography EIP"** that:
- Normalizes FCU / `newPayload` / `getPayload` sequencing
- Specifies snap-sync initiation handshake (FCU-only path now viable)
- Defines error codes for "EL has no state" condition (`eth_syncing` insufficient — needs precision)
- Tightens valid/invalid consistency between `newPayload` and FCU responses
- Requires EL dev participation
4. ✅ **Future work tracks:**
- SSZ-based execution API (already proposed for ZK/witness work)
- Batched engine API calls (e.g., 100 blocks at once)
- Move blob and possibly receipt distribution to CL network (post-Glamsterdam)
5. ✅ **Light-client–driven head discovery** (Nimbus pattern) noted as desirable optimization

---

## 9. Execution Requests Deduplication (Secondary Topic)

**Context:** Prysm draft PR removes the `execution_requests_root` field from the beacon block, since the relationship can be established through bid → payload → block parentage.

**Mikhail's pushback + Potuz's clarification:**
- The root must be **kept on the bid** (needed for checkpoint sync — historical reason for the EIP-7594-era split)
- Better to **keep the root on the beacon block** too, so SSZ hashing remains consistent
- Change is **gossip-only**; RPC (`by_range`, `by_root`) still returns the expanded form
- Approach: separate gossip object (decoupled), not a zero-filled blinded variant

**Decision:**
- Keep root on both bid and beacon block
- Implement as decoupled gossip schema
- **Not** for DevNet 1 (chain currently broken on fork choice — focus on correctness)
- Target DevNet 2; compulsory but deferred
- Consensus-spec change, no separate EIP number

---

## 10. Side Topic: Joint vs. Separated Client Cost Asymmetry

Potuz raised that any API choice imposes different costs on modular clients (Prysm + external EL) vs. integrated clients (Nimbus, Erigon/Caplin):

- Modular CLs can't avoid double-storage if they don't store payloads themselves (must blind/unblind, serialize, reassemble for serving)
- Integrated clients can store once and avoid the engine API round-trip

**Counter (Jacek, Erigon dev):** A well-designed binary, streaming, SSZ-based execution API minimizes this gap. Erigon dev: "We ought to just give you a block that you can stream — you shouldn't need to do any translation."

---

## 11. Meeting Outstanding / Tabled Items

- Receipts handling under top-up sync (still needed for Glamsterdam — out of scope for this meeting)
- Blob distribution consolidation
- Mempool migration to CL network
- Block-number ↔ slot mapping pain points (mostly resolved by slot field on payload in Gloas)
- ZK-future state distribution (precondition: snap sync exists; out of scope here)
- Disc v5 / ENR encoding issues affecting Nimbus peer connectivity (briefly mentioned)

---

## 12. Action Items

| Owner | Action |
|---|---|
| Jacek | HackMD on top-up sync posted in EVPS Discord; soliciting EL-dev review to convert into EIP |
| Raul | Update Prysm draft PR to retain execution_requests_root on beacon block; circulate for CL review |
| All CLs | Review execution-requests gossip-schema proposal |
| Small group | Convene to draft choreography EIP (FCU/newPayload sequencing, snap-sync initiation) — needs EL dev representation |
| Maintainers | Update DevNet page with current EIP list and inclusion status |
| Prysm team | Continue debugging payload-by-range sync downscoring issues |

---

## 13. Bottom Line

The meeting consolidated around a **layered strategy**: keep current sync mechanics for Glamsterdam (no EIP-8237), preserve the optionality to migrate fully to CL-driven sync in a future fork, and use the intervening time to (a) define a precise choreography spec, (b) modernize the engine API toward SSZ + batching, and (c) let the integrated-client implementations (Nimbus, Erigon/Caplin) prove out the top-up architecture in production.