Skip to content

Conversation

macladson
Copy link
Member

@macladson macladson commented Aug 7, 2025

Issue Addressed

While working on #7728 I noticed that there actually is no necessary reason why ExecutionPayloadElectra, and other Electra/Fulu-variants of the payload types, have to exist as no new fields have been added since Deneb. These were added as part of the Electra/Fulu boilerplate but actually were not required.

Note that the PayloadRequest types do require an Electra variant since the new field execution_requests was added in Electra but no changes to the actual ExecutionPayload occured.

Proposed Changes

Removes the post-Deneb variants of the various Payload types and tidied up the engine API to handle Deneb payloads where required.

Considerations

Downsides

  • We may actually want to keep the post-Deneb variants as this creates a nice 1-to-1 mapping between all the various types. For example, without these types, we can know longer immediately know which Fork a Payload has come from (we lose the fork_name() function). We would need to query other sources, such as timestamp, block variant, etc.

  • There also is a nice synergy with the PayloadResponse types that we lose (We lose map_get_payload_response_into_execution_payload for example).

  • Additionally, it becomes more difficult to reason about certain code paths which match on ForkName since there is no longer the 1-to-1 ForkName -> payload variant mapping.

Upsides

  • It becomes more clear which fork variants actually add new fields/information and which types are functionally equivalent to each other.

  • We become consistent with other uses of superstruct such as in Attestation where we do not have the intermediate variants between AttestationBase and AttestationElectra

  • It reduces the amount of boilerplate required for each fork, since we no longer need to add new variants which are identical to the old ones. (This cuts both ways though, because if a new variant is actually required, then the boilerplate is no longer immediately present which places more burden on the Dev implementing the feature)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant