-
Notifications
You must be signed in to change notification settings - Fork 780
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
[Merged by Bors] - Update to spec v1.0.0-rc.0 and BLSv4 #1765
Conversation
Likely need to delete the Altona, Medalla and Zinken configs from this branch, or else attempt some backwards-compatibility measures (that's why the tests are failing currently) |
Would the incompatibilities cause a consensus split or are they just regarding our configs? |
I've thought about this some more and I think we would need to make an The only risk then would be that using BLSv4 on Medalla creates a chain split, because it is stricter about infinity pubkeys and signatures. As far as I understand it would be trivial for someone to create a pair of secret keys If that is the case, I think the separate branch for Medalla compatibility makes sense, or maybe a feature flag... |
Yep it would be very trivial to cause a consensus split on Medalla if we update since we previously allowed As a result it would be trivial to make a deposit for the public key = infinity and old version would accept the deposit and new ones reject it. P.s.
This use case is still valid. We still need to accept |
This should also solve #1707 |
dd34bec
to
083db9c
Compare
* Update blst and milagro_bls subgroup checking Signed-off-by: Kirk Baird <[email protected]> * cargo fmt Signed-off-by: Kirk Baird <[email protected]>
I'm comandeering this PR! With @michaelsproul's permission, of course. |
083db9c
to
e3096c2
Compare
All ready! I can't select you as a reviewer though @michaelsproul 😕 |
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.
Looks good on the whole @paulhauner! Thanks for taking this over and getting it over the line.
I just have a few stylistic suggestions that should be addressed, then we can merge!
Thanks! All comments addressed. I've been jigging around in my Could you please double check I set the proportional_slashing_multiplier correctly in the YAML configs, please? :) |
Yep! All good! And my Medalla node is happy with them too |
Merge at will! |
bors r+ |
## Issue Addressed Closes #1504 Closes #1505 Replaces #1703 Closes #1707 ## Proposed Changes * Update BLST and Milagro to versions compatible with BLSv4 spec * Update Lighthouse to spec v1.0.0-rc.0, and update EF test vectors * Use the v1.0.0 constants for `MainnetEthSpec`. * Rename `InteropEthSpec` -> `V012LegacyEthSpec` * Change all constants to suit the mainnet `v0.12.3` specification (i.e., Medalla). * Deprecate the `--spec` flag for the `lighthouse` binary * This value is now obtained from the `config_name` field of the `YamlConfig`. * Built in testnet YAML files have been updated. * Ignore the `--spec` value, if supplied, log a warning that it will be deprecated * `lcli` still has the spec flag, that's fine because it's dev tooling. * Remove the `E: EthSpec` from `YamlConfig` * This means we need to deser the genesis `BeaconState` on-demand, but this is fine. * Swap the old "minimal", "mainnet" strings over to the new `EthSpecId` enum. * Always require a `CONFIG_NAME` field in `YamlConfig` (it used to have a default). ## Additional Info Lots of breaking changes, do not merge! ~~We will likely need a Lighthouse v0.4.0 branch, and possibly a long-term v0.3.0 branch to keep Medalla alive~~. Co-authored-by: Kirk Baird <[email protected]> Co-authored-by: Paul Hauner <[email protected]>
bors r- |
Canceled. |
I had to merge #1836 into this to fix a merge conflict. |
bors r+ |
## Issue Addressed Closes #1504 Closes #1505 Replaces #1703 Closes #1707 ## Proposed Changes * Update BLST and Milagro to versions compatible with BLSv4 spec * Update Lighthouse to spec v1.0.0-rc.0, and update EF test vectors * Use the v1.0.0 constants for `MainnetEthSpec`. * Rename `InteropEthSpec` -> `V012LegacyEthSpec` * Change all constants to suit the mainnet `v0.12.3` specification (i.e., Medalla). * Deprecate the `--spec` flag for the `lighthouse` binary * This value is now obtained from the `config_name` field of the `YamlConfig`. * Built in testnet YAML files have been updated. * Ignore the `--spec` value, if supplied, log a warning that it will be deprecated * `lcli` still has the spec flag, that's fine because it's dev tooling. * Remove the `E: EthSpec` from `YamlConfig` * This means we need to deser the genesis `BeaconState` on-demand, but this is fine. * Swap the old "minimal", "mainnet" strings over to the new `EthSpecId` enum. * Always require a `CONFIG_NAME` field in `YamlConfig` (it used to have a default). ## Additional Info Lots of breaking changes, do not merge! ~~We will likely need a Lighthouse v0.4.0 branch, and possibly a long-term v0.3.0 branch to keep Medalla alive~~. Co-authored-by: Kirk Baird <[email protected]> Co-authored-by: Paul Hauner <[email protected]>
Pull request successfully merged into master. Build succeeded: |
Issue Addressed
Closes #1504
Closes #1505
Replaces #1703
Closes #1707
Proposed Changes
MainnetEthSpec
.InteropEthSpec
->V012LegacyEthSpec
v0.12.3
specification (i.e., Medalla).--spec
flag for thelighthouse
binaryconfig_name
field of theYamlConfig
.--spec
value, if supplied, log a warning that it will be deprecatedlcli
still has the spec flag, that's fine because it's dev tooling.E: EthSpec
fromYamlConfig
BeaconState
on-demand, but this is fine.EthSpecId
enum.CONFIG_NAME
field inYamlConfig
(it used to have a default).Additional Info
Lots of breaking changes, do not merge!
We will likely need a Lighthouse v0.4.0 branch, and possibly a long-term v0.3.0 branch to keep Medalla alive.