-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
skip eth1data voting after electra #14835
Conversation
beacon-chain/core/helpers/legacy.go
Outdated
} | ||
|
||
// Should not happen, but if the canonicalEth1Data is nil | ||
// default to legacy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be impossible, I don't think this is the right approach
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for legacy.go
! I've also considered to move the function into common util while working on #14829.
// post eth1 deposits, the Eth 1 data will then be frozen | ||
if !helpers.IsLegacyDepositProcessPeriod(beaconState, vs.HeadFetcher.HeadETH1Data()) { | ||
return vs.HeadFetcher.HeadETH1Data(), nil | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First, I'm not quite sure that eth1_data
will be frozen after the transition period, as it's up to each client team how to handle Eth1 polling after Electra.
Second, if we decided to freeze eth1_data
, isn't it fine to simply fetch from beaconState
, like beaconState.Eth1Data()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thats's a good point should just do it from beacon state. there is an update to the spec here
ethereum/consensus-specs#4106
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DepositRequestHaveStarted
seems much better to read, and more aligned with the latest spec. I will use this for my work also!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i should rename to Requests oops
beacon-chain/core/helpers/legacy.go
Outdated
} | ||
|
||
//canonicalEth1Data should never be nil | ||
eth1DepositIndexLimit := math.Min(canonicalEth1Data.DepositCount, requestsStartIndex) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Jun Song <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
What type of PR is this?
Feature
What does this PR do? Why is it needed?
https://eips.ethereum.org/EIPS/eip-6110
mentions the following
Eth 1 voting should stop post electra and the eth1 transition period. This PR adds a check that has already been added in deposit packing by @syjn99 in #14697
Which issues(s) does this PR fix?
Fixes #
Other notes for review
Acknowledgements