Context
In Gloas (EIP-7732), the execution payload is delivered in a separate SignedExecutionPayloadEnvelope rather than embedded in the beacon block. Caplin currently stores these envelopes only in the fork graph's temporary disk cache, which is pruned ~3 epochs after finalization (fork_graph_disk.go:Prune).
Gap
The P2P handlers (ExecutionPayloadEnvelopesByRoot, ExecutionPayloadEnvelopesByRange) and the Beacon API (GET /eth/v1/beacon/execution_payload_envelope/{block_id}) read envelopes via forkChoiceReader.ReadEnvelopeFromDisk. After pruning, these return nothing — even though the protocol serve range (MIN_EPOCHS_FOR_BLOCK_REQUESTS, ~33k epochs on mainnet) is far larger than the retention window.
The EL side has ExecModule.GetPayloadBodiesByHash/Range (wired into ChainReaderWriterEth1) which returns transactions, withdrawals, and BAL bytes — but not the full envelope. The missing fields are ExecutionRequests, BuilderIndex, BeaconBlockRoot, ParentBeaconBlockRoot, and the builder Signature.
Affected consumers
- P2P:
executionPayloadEnvelopesByRootHandler / executionPayloadEnvelopesByRangeHandler — cannot serve envelopes outside the fork graph retention window
- Beacon API:
GET /eth/v1/beacon/execution_payload_envelope/{block_id} — returns 404 for pruned blocks (relevant for archive nodes)
All other envelope consumers (chain tip sync, forward sync, block production, payload attestation) only need recent data and are unaffected.
Possible direction
Persist only the envelope metadata (~200 bytes–1 KB per block: ExecutionRequests, BuilderIndex, BeaconBlockRoot, ParentBeaconBlockRoot, Signature) in the beacon DB. At serve time, reconstruct the full SignedExecutionPayloadEnvelope by combining persisted metadata with payload body from ExecModule.GetPayloadBodiesByHash. This avoids duplicating the bulk of the data (transactions, withdrawals, BAL) that the EL already stores.
Priority
Not urgent. Gloas is in devnet — node count is small, sync distances are short, and the fork graph cache is sufficient for now. This issue tracks the gap for when testnet/mainnet timelines get closer.
Context
In Gloas (EIP-7732), the execution payload is delivered in a separate
SignedExecutionPayloadEnveloperather than embedded in the beacon block. Caplin currently stores these envelopes only in the fork graph's temporary disk cache, which is pruned ~3 epochs after finalization (fork_graph_disk.go:Prune).Gap
The P2P handlers (
ExecutionPayloadEnvelopesByRoot,ExecutionPayloadEnvelopesByRange) and the Beacon API (GET /eth/v1/beacon/execution_payload_envelope/{block_id}) read envelopes viaforkChoiceReader.ReadEnvelopeFromDisk. After pruning, these return nothing — even though the protocol serve range (MIN_EPOCHS_FOR_BLOCK_REQUESTS, ~33k epochs on mainnet) is far larger than the retention window.The EL side has
ExecModule.GetPayloadBodiesByHash/Range(wired intoChainReaderWriterEth1) which returns transactions, withdrawals, and BAL bytes — but not the full envelope. The missing fields areExecutionRequests,BuilderIndex,BeaconBlockRoot,ParentBeaconBlockRoot, and the builderSignature.Affected consumers
executionPayloadEnvelopesByRootHandler/executionPayloadEnvelopesByRangeHandler— cannot serve envelopes outside the fork graph retention windowGET /eth/v1/beacon/execution_payload_envelope/{block_id}— returns 404 for pruned blocks (relevant for archive nodes)All other envelope consumers (chain tip sync, forward sync, block production, payload attestation) only need recent data and are unaffected.
Possible direction
Persist only the envelope metadata (~200 bytes–1 KB per block:
ExecutionRequests,BuilderIndex,BeaconBlockRoot,ParentBeaconBlockRoot,Signature) in the beacon DB. At serve time, reconstruct the fullSignedExecutionPayloadEnvelopeby combining persisted metadata with payload body fromExecModule.GetPayloadBodiesByHash. This avoids duplicating the bulk of the data (transactions, withdrawals, BAL) that the EL already stores.Priority
Not urgent. Gloas is in devnet — node count is small, sync distances are short, and the fork graph cache is sufficient for now. This issue tracks the gap for when testnet/mainnet timelines get closer.