Deferred payload execution introduced in #5094 made the parent execution requests a required input to the STF. The spec change extended slot N's BeaconBlockBody with the full execution requests of slot N-1, copied from that slot's ExecutionPayloadEnvelope.
But because the BeaconBlockBody data structure is shared between the STF and the gossip layer, this had the side effect of duplicating the execution request bytes in the critical path.
That cost would be unavoidable if the two payloads were independent, but they are not. To process slot N's BeaconBlockBody, the client must have received and validated the parent BeaconBlock and the ExecutionPayloadEnvelope. If not, the gossip validation rules produce a ValidationIgnore outcome, and the client will enqueue the parent for retrieval first.
So in all circumstances, when the client is in good standing to submit a BeaconBlockBody to the STF, it will have the parent execution requests in its possession. Therefore, instead of propagating the data twice, the client can just fill the field in.
This implies decoupling the wire-level and consensus representations of BeaconBlockBody. There are two solutions possible:
- Zeroing out the duplicate field in the
BeaconBlockBody on the publish path, then having the client fill in the blanks in the receive path.
- Introducing a
GossipBeaconBlockBody data structure, identical to BeaconBlockBody modulo the parent_execution_requests.
In either case, the wire format is canonicalized to the STF version for consensus, storage, and Req/Resp.
(1) is the quick but more unsafe solution; (2) is a bit more pedantic, but typesafe and stricter decoupling. From polling Core Devs, it seems like (2) is the preferred path.
I initially thought we'd need a commitment to the parent execution requests, but it doesn't seem to be necessary because the BeaconBlock links to the parent's BeaconBlock, which commits to the ExecutionPayloadBid, which in turn commits to the execution_requests_root. So the cryptographic link already exists.
Deferred payload execution introduced in #5094 made the parent execution requests a required input to the STF. The spec change extended slot N's
BeaconBlockBodywith the full execution requests of slot N-1, copied from that slot'sExecutionPayloadEnvelope.But because the
BeaconBlockBodydata structure is shared between the STF and the gossip layer, this had the side effect of duplicating the execution request bytes in the critical path.That cost would be unavoidable if the two payloads were independent, but they are not. To process slot N's
BeaconBlockBody, the client must have received and validated the parentBeaconBlockand theExecutionPayloadEnvelope. If not, the gossip validation rules produce aValidationIgnoreoutcome, and the client will enqueue the parent for retrieval first.So in all circumstances, when the client is in good standing to submit a
BeaconBlockBodyto the STF, it will have the parent execution requests in its possession. Therefore, instead of propagating the data twice, the client can just fill the field in.This implies decoupling the wire-level and consensus representations of
BeaconBlockBody. There are two solutions possible:BeaconBlockBodyon the publish path, then having the client fill in the blanks in the receive path.GossipBeaconBlockBodydata structure, identical toBeaconBlockBodymodulo theparent_execution_requests.In either case, the wire format is canonicalized to the STF version for consensus, storage, and Req/Resp.
(1) is the quick but more unsafe solution; (2) is a bit more pedantic, but typesafe and stricter decoupling. From polling Core Devs, it seems like (2) is the preferred path.
I initially thought we'd need a commitment to the parent execution requests, but it doesn't seem to be necessary because the
BeaconBlocklinks to the parent'sBeaconBlock, which commits to theExecutionPayloadBid, which in turn commits to theexecution_requests_root. So the cryptographic link already exists.