fix: use parent block slot for attestation payload availability - #9731
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
|
need |
|
merged into |
| : computeBlockAttestationRewardAltair( | ||
| config, | ||
| block as altair.BeaconBlock, | ||
| preState as CachedBeaconStateAltair, |
There was a problem hiding this comment.
we don't apply parent execution payload for preState so executionPayloadAvailability passed in is not correct
but I'd resolve it in a different PR
There was a problem hiding this comment.
not sure I follow correctly, maybe you can make a proposal for that, if you are looking into that right now, can target my branch, I am not sure how to merge this unless we skip a lot of spec tests
|
@twoeths we need a spec release to merge this, I could ignore failing spec tests, but it require to skip 59 tests |
| // only the pyspec BLS stub accepts. Lodestar verifies the deposit proof of possession | ||
| // inside processPendingDeposits, so the validator is never onboarded and the state root | ||
| // diverges once the pending deposit is applied. | ||
| name.includes("is_one_confirmed_passes_with_new_validator_activated_in_head_state"), |
There was a problem hiding this comment.
@nazarhussain this might be an issue with the test harness? in any case, I would like to keep this out of this PR, so skipping for now
| // TODO-GLOAS: re-enable after the gloas should_apply_proposer_boost rule is implemented. | ||
| // New test suite added in v1.7.0-alpha.13 (consensus-specs #5441); Lodestar still applies | ||
| // the pre-gloas proposer boost, so the head weight differs by the boost amount. | ||
| /^gloas\/fork_choice\/should_apply_proposer_boost\/.*$/, |
There was a problem hiding this comment.
@ensi321 looks like we are failing the new tests you added in ethereum/consensus-specs#5441
| - get_weight#gloas | ||
| - has_compounding_withdrawal_credential#gloas | ||
| - is_ancestor#gloas | ||
| - is_bid_compatible_with_head#gloas |
There was a problem hiding this comment.
well we do have this, but it's in a different pr here #9739 and not approved, so no way I can fix this now
v1.7.0-alpha.13