ExecutionRequests.EncodingSizeSSZ (cl/cltypes/execution_requests.go) returns
return e.Deposits.EncodingSizeSSZ() + e.Withdrawals.EncodingSizeSSZ() + e.Consolidations.EncodingSizeSSZ()
The type is a dynamic SSZ container (Static() == false) with three variable-size fields, so its encoding is three 4-byte offsets plus the list contents — the method under-reports the encoded length by exactly 12 bytes. For a filled SignedExecutionPayloadEnvelope the chain reports 981 while the actual encoding is 993; everything else in that size chain is exact, so the discrepancy is exactly the missing offsets.
Where it flows: the signed-container size helper (sizeSigned), BeaconBody.EncodingSizeSSZ, and BlindedBeaconBody.EncodingSizeSSZ all add ExecutionRequests.EncodingSizeSSZ() into their totals. These values are used as len(buf) < size decode floors, so the impact is a slightly loose floor rather than an over-read (ssz2 does its own bounds checking) — low severity, but wrong, and the same bug class as the BlindedBeaconBody.EncodingSizeSSZ fix in #22165.
Found while pinning SSZ goldens for #22176; the golden test there pins today's under-reported value on purpose (signed_ssz_golden_test.go, SignedExecutionPayloadEnvelope case), so the fix must update that one pinned EncodingSizeSSZ golden — the encode bytes and hash roots are unaffected.
Suggested fix (red test first, per the TDD guidelines): assert len(EncodeSSZ(nil)) == EncodingSizeSSZ() for a filled ExecutionRequests, then add the three offset bytes (+ 4*3, or derive from the field count).
ExecutionRequests.EncodingSizeSSZ(cl/cltypes/execution_requests.go) returnsThe type is a dynamic SSZ container (
Static() == false) with three variable-size fields, so its encoding is three 4-byte offsets plus the list contents — the method under-reports the encoded length by exactly 12 bytes. For a filledSignedExecutionPayloadEnvelopethe chain reports 981 while the actual encoding is 993; everything else in that size chain is exact, so the discrepancy is exactly the missing offsets.Where it flows: the signed-container size helper (
sizeSigned),BeaconBody.EncodingSizeSSZ, andBlindedBeaconBody.EncodingSizeSSZall addExecutionRequests.EncodingSizeSSZ()into their totals. These values are used aslen(buf) < sizedecode floors, so the impact is a slightly loose floor rather than an over-read (ssz2does its own bounds checking) — low severity, but wrong, and the same bug class as theBlindedBeaconBody.EncodingSizeSSZfix in #22165.Found while pinning SSZ goldens for #22176; the golden test there pins today's under-reported value on purpose (
signed_ssz_golden_test.go,SignedExecutionPayloadEnvelopecase), so the fix must update that one pinnedEncodingSizeSSZgolden — the encode bytes and hash roots are unaffected.Suggested fix (red test first, per the TDD guidelines): assert
len(EncodeSSZ(nil)) == EncodingSizeSSZ()for a filledExecutionRequests, then add the three offset bytes (+ 4*3, or derive from the field count).