Optional randao verification when producing blocks #222
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
michaelsproul
force-pushed
the
verify-randao
branch
2 times, most recently
from
4edba50
to
f7e6584
Compare
|
CI seems to be failing on an unrelated error in the blinded_blocks API, weirdly it doesn't occur locally for me with spectral 6.3.0 |
michaelsproul
force-pushed
the
verify-randao
branch
from
f7e6584
to
f89ade3
Compare
djrtwo
reviewed
Jul 18, 2022
|
Since Teku isn't validating the randao reveal when creating blocks now so it would be nice if we could just ignore this param and not need to make any changes. As such I'd have a mild preference for It would also mean that |
|
Thanks for the feedback @ajsutton, @djrtwo 🙏 How does this sound moving forward?
|
|
Yep that works for me. |
|
Alternatively we could use a value-less |
|
Can you rebase with master? |
michaelsproul
force-pushed
the
verify-randao
branch
2 times, most recently
from
ab72517
to
b39d248
Compare
|
Done! |
djrtwo
approved these changes
Jul 26, 2022
|
looks like we're good to merge @djrtwo! thanks! |
arnetheduck
approved these changes
Aug 9, 2022
mpetrunic
force-pushed
the
verify-randao
branch
from
b39d248
to
cd71d99
Compare
bors bot
pushed a commit
to sigp/lighthouse
that referenced
this pull request
Sep 19, 2022
…3540) ## Issue Addressed ethereum/beacon-APIs#222 ## Proposed Changes Update Lighthouse's randao verification API to match the `beacon-APIs` spec. We implemented the API before spec stabilisation, and it changed slightly in the course of review. Rather than a flag `verify_randao` taking a boolean value, the new API uses a `skip_randao_verification` flag which takes no argument. The new spec also requires the randao reveal to be present and equal to the point-at-infinity when `skip_randao_verification` is set. I've also updated the `POST /lighthouse/analysis/block_rewards` API to take blinded blocks as input, as the execution payload is irrelevant and we may want to assess blocks produced by builders. ## Additional Info This is technically a breaking change, but seeing as I suspect I'm the only one using these parameters/APIs, I think we're OK to include this in a patch release.
bors bot
pushed a commit
to sigp/lighthouse
that referenced
this pull request
Sep 19, 2022
…3540) ## Issue Addressed ethereum/beacon-APIs#222 ## Proposed Changes Update Lighthouse's randao verification API to match the `beacon-APIs` spec. We implemented the API before spec stabilisation, and it changed slightly in the course of review. Rather than a flag `verify_randao` taking a boolean value, the new API uses a `skip_randao_verification` flag which takes no argument. The new spec also requires the randao reveal to be present and equal to the point-at-infinity when `skip_randao_verification` is set. I've also updated the `POST /lighthouse/analysis/block_rewards` API to take blinded blocks as input, as the execution payload is irrelevant and we may want to assess blocks produced by builders. ## Additional Info This is technically a breaking change, but seeing as I suspect I'm the only one using these parameters/APIs, I think we're OK to include this in a patch release.
Woodpile37
pushed a commit
to Woodpile37/lighthouse
that referenced
this pull request
Jan 6, 2024
…igp#3540) ## Issue Addressed ethereum/beacon-APIs#222 ## Proposed Changes Update Lighthouse's randao verification API to match the `beacon-APIs` spec. We implemented the API before spec stabilisation, and it changed slightly in the course of review. Rather than a flag `verify_randao` taking a boolean value, the new API uses a `skip_randao_verification` flag which takes no argument. The new spec also requires the randao reveal to be present and equal to the point-at-infinity when `skip_randao_verification` is set. I've also updated the `POST /lighthouse/analysis/block_rewards` API to take blinded blocks as input, as the execution payload is irrelevant and we may want to assess blocks produced by builders. ## Additional Info This is technically a breaking change, but seeing as I suspect I'm the only one using these parameters/APIs, I think we're OK to include this in a patch release.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Recently I've been speculatively creating blocks using the
/eth/v2/validator/blocks/{slot}endpoint, polling the endpoint live at every slot.Some beacon node implementations verify the
randao_revealsignature when this endpoint is used, which causes speculative block proposal to fail (because the private key for the trueproposer_indexis not known).A few months ago I added an optional
verify_randaoparameter to disable the verification in Lighthouse: sigp/lighthouse#3116. Recently I've discovered that Nimbus have started to verify therandao_revealby default too, so I'd like to implore them to adopt the same parameter.As far as I know the other clients (Teku/Prysm/Lodestar) don't verify the
randao_revealcurrently, so I think it would be acceptable for them to delay implementing theverify_randaoparameter until they decide to. Alternatively they could maintain the same semantics and acceptverify_randao=false/null, and error ifverify_randao=true. I would like to impose the minimum burden on implementers, given that this is a relatively niche use case.More background: