Concept: Remove post-Deneb Payload
variants
#7841
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 fieldexecution_requests
was added in Electra but no changes to the actualExecutionPayload
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 thefork_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 losemap_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-1ForkName
-> 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 inAttestation
where we do not have the intermediate variants betweenAttestationBase
andAttestationElectra
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)