Closed terencechain closed 1 year ago
You can just check against the withdrawals root of the expected withdrawals: https://github.com/ethereum/consensus-specs/pull/3092
are we talking about CLs doing what validations they can against a given SignedBuilderBid
or are we talking about directions for builders of blocks (and by extension relay validation)?
we already do this in lodestar while generating/processing for post state :slightly_smiling_face: :
are we talking about CLs doing what validations they can against a given SignedBuilderBid or are we talking about directions for builders of blocks (and by extension relay validation)?
We're talking about building the beacon block around the execution payload header recieved in the builder bid. We need to calculate the state_root
, of the post-state after the block is applied to the head state. We find the post-state with process_block
which has an equivalence check of the full expected withdrawals and the block's full withdrawals. We get around this in the builder flow by comparing withdrawals roots
ok I think I'm following -- this is more of an implementation concern than a spec-level issue.
it sounds like clients are using the same pathways to build blocks regardless of the payload being "blinded" or not, and in that case the typical state transition (to calc state roots) would fail bc as written it wants the full withdrawals list.
this code can be modified to just check withdrawals root equivalence which is what it sounds like everyone is doing...
I'll close this issue as it sounds like there is a way forward and I'm not sure this type of thing should live in the builder-specs
although my disposition here could change as I separately want to understand better the validations clients do and there could be value in standardizing those... if anything I'll follow up separately and open a new issue if warranted
To compute the state root for Capella blind block, a full withdrawal list will be required in state transaction. Currently, a blind block contains a header that only contains a withdrawal root, not a list. That information is not sufficient to construct state root. One solution is client can utilize
get_exepcted_withdrawal
from the parent state and use the expected withdrawal and callprocess_withdrawals
. I think we might want to clarify this in the builder specs