Prune finalized gloas envelopes

[pawanjay176]

Currently, finalized Gloas payload envelopes are never pruned. prune_finalized_payloads in the background migrator only emits DeleteExecutionPayload for canonical finalized blocks. There is no corresponding DeletePayloadEnvelope. DeletePayloadEnvelope is only emitted today for non-canonical blocks that are being purged.

As a result, full SignedExecutionPayloadEnvelopes persist on disk indefinitely for canonical finalized blocks.

The spec only requires serving envelopes over [current_epoch - compute_min_epochs_for_block_requests(), current_epoch] (the WS window), so anything beyond that can be dropped. Within the WS window, a blinded representation is likely sufficient.
To serve the payloads until the WS period, we need to be able to reconstruct the full SignedExecutionPayloadEnvelope. We get the actual payload from the EL with the engine_getPayloadBodies,

The blinded representation could be something like

pub struct ExecutionPayloadEnvelopeBlinded<E: EthSpec> {
    pub payload_hash: Hash256,
    pub execution_requests: ExecutionRequests<E>,
    #[serde(with = "serde_utils::quoted_u64")]
    pub builder_index: u64,
    pub beacon_block_root: Hash256,
    pub parent_beacon_block_root: Hash256,
}

and be able to convert from an blinded envelope to a full envelope if the payload is provided. I would prefer not to go through the AbstractExecPayload path if possible since I find it very confusing.

[0u-Y]

Hi @pawanjay176 , I'd like to work on this!

[pawanjay176]

Hey @0u-Y , Sorry I think this one is a major task and I'd prefer someone internal work on this one.

[0u-Y]

@pawanjay176 No problem, thanks for letting me know!

[michaelsproul]

Yeah let's avoid AbstractExecPayload 💯

I think the blinded design is nice, and it gels with my idea about storing ExecutionPayloads for the non-finalized part of the chain indexed by their block_hash.

So for a non-finalized envelope you can do:

1. Load blinded envelope from disk by block_root
2. Read payload_hash (or I would call it payload_block_hash?) from blinded envelope
3. Load payload from disk by payload_block_hash

This could help avoid some of the hacks in:

• Gloas ensure we emit payload attributes SSE event #9348

Pruning becomes a bit more subtle though (need to only prune block hashes once they are referenced by 0 beacon blocks).

[eserilev]

Outside of #9348 is there any reason to key by block hash? it seems like we're going to remove the parent block number stuff anyways

I think we should just do whatever is most compatible with the payload envelope streamer as thats really going to be the only use case for actually loading payloads from the db/EL

and also whatever makes it easiest to prune at finalization

[michaelsproul]

Design 1

Just revisiting this with @hopinheimer, some notes:

I think we need the signature in the blinded "header" (call it a summary, as it is a DB object):

/// All fields of SignedExecutionPayloadEnvelope except the Payload itself.
///
/// The fields are "flattened" into one struct here, but could be nested mirroring SignedExecutionPayloadEnvelope itself (i.e. have a subfield called message with all the data).
struct SignedExecutionPayloadEnvelopeSummary {
    pub payload_hash: Hash256,
    pub execution_requests: ExecutionRequests<E>,
    #[serde(with = "serde_utils::quoted_u64")]
    pub builder_index: u64,
    pub beacon_block_root: Hash256,
    pub parent_beacon_block_root: Hash256,
    pub signature: Signature,
}

• Blinded design is probably still good. We want to just store the SignedExecutionPayloadEnvelopeSummary in Lighthouse's DB for the period between the WS period and the finalized checkpoint. For envelopes in this period, we should load the payload body from the EL and then fuse this with our stored SignedExecutionPayloadEnvelopeSummary in order to produce the full payload envelope. This operation is only required to serve peers (so it doesn't need to be absolutely blazing fast)
• We don't need to key envelopes (or blinded envelopes) on block hash, using block root is fine until proven otherwise 😅

Schema:

• For payloads newer than finalization, store 2 parts: a blinded summary (SignedExecutionPayloadEnvelopeSummary) & a full body (ExecutionPayload). Use two different DBColumns, both indexed by block_root.
• For payloads older than finalization, store just the blinded summary (SignedExecutionPayloadEnvelopeSummary), and load the full body from the EL.

DBColumn::PayloadSummary -> block_root -> SignedExecutionPayloadEnvelopeSummary
DBColumn::PayloadEnvelope -> block_root -> ExecutionPayload

Implies:

• Pruning: delete SignedExecutionPayloadEnvelopeSummary and ExecutionPayload for all non-canonical envelopes.
• Migration: delete just ExecutionPayload for canonical envelopes that have been newly finalized (their payloads will be reconstructed from the EL).
• Optional: prune SignedExecutionPayloadEnvelopeSummary for payloads older than the block retention window. But this is not really necessary for V1 (related to: Prune historic blocks #3209).

[eserilev]

we need this before the sepolia testnet. if that's not feasible maybe we can spin up a quick PR just to prune non-canonical envelopes at finalization. but ideally we should have this full feature ready for sepolia