ethereum / builder-specs

Specification for the external block builders.
https://ethereum.github.io/builder-specs/
Creative Commons Zero v1.0 Universal
177 stars 60 forks source link

Validator compute state root requires full withdrawal list #69

Closed terencechain closed 1 year ago

terencechain commented 1 year ago

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 call process_withdrawals. I think we might want to clarify this in the builder specs

ethDreamer commented 1 year ago

You can just check against the withdrawals root of the expected withdrawals: https://github.com/ethereum/consensus-specs/pull/3092

ralexstokes commented 1 year ago

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)?

g11tech commented 1 year ago

we already do this in lodestar while generating/processing for post state :slightly_smiling_face: :

https://github.com/ChainSafe/lodestar/blob/unstable/packages/state-transition/src/block/processWithdrawals.ts#L19:L25

realbigsean commented 1 year ago

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

ralexstokes commented 1 year ago

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