Skip to content
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] - Disallow attesting to optimistic head #3140

Closed
wants to merge 11 commits into from

Conversation

paulhauner
Copy link
Member

@paulhauner paulhauner commented Apr 4, 2022

Issue Addressed

NA

Proposed Changes

Disallow the production of attestations and retrieval of unaggregated attestations when they reference an optimistic head. Add tests to this end.

I also moved BeaconChain::produce_unaggregated_attestation_for_block to the BeaconChainHarness. It was only being used during tests, so it's nice to stop pretending it's production code. I also needed something that could produce attestations to optimistic blocks in order to simulate scenarios where the justified checkpoint is determined invalid (if no one would attest to an optimistic block, we could never justify it and then flip it to invalid).

Additional Info

@paulhauner paulhauner added blocked work-in-progress PR is a work-in-progress bellatrix Required to support the Bellatrix Upgrade labels Apr 4, 2022
@paulhauner paulhauner added ready-for-review The code is ready for review and removed work-in-progress PR is a work-in-progress labels Apr 6, 2022
@paulhauner paulhauner marked this pull request as ready for review April 6, 2022 06:31
Copy link
Member

@realbigsean realbigsean left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just had one comment, looking good though!

.get_block_execution_status(&beacon_block_root)
.map_or(true, |execution_status| execution_status.is_not_verified())
{
None
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sort of thinking we should handle errors here like in produce_unaggregated_attestation, otherwise the HTTP API will return "missing aggregate" which would be a bit misleading

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great point, I've added that. I also jigged around with the naming too. All the meaningful changes are in bc8f220.

@paulhauner paulhauner added work-in-progress PR is a work-in-progress and removed ready-for-review The code is ready for review labels Apr 7, 2022
@paulhauner paulhauner added ready-for-review The code is ready for review and removed work-in-progress PR is a work-in-progress labels Apr 7, 2022
@paulhauner
Copy link
Member Author

All comments addressed, thanks @realbigsean. I will merge after an approval (or change request) :)

/// Returns `true` if the block:
///
/// - Has execution enabled, AND
/// - Hash a valid payload
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// - Hash a valid payload
/// - Has a valid payload

@@ -127,6 +127,17 @@ pub enum PayloadVerificationStatus {
Irrelevant,
}

impl PayloadVerificationStatus {
/// Returns `true` if the payload was optimistically imported.
pub fn is_optimistic(&self) -> bool {
Copy link
Member

@realbigsean realbigsean Apr 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if PayloadVerificationStatus::NotVerified should be renamed to PayloadVerificationStatus::Optimistic as well to make this mapping very clear. I could understand if we want to keep the concept of "optimism" constrained to fork choice though. What are your thoughts?

This method can also be used in block_verification.rs L1168 by the way

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great suggestions, will do both.

Comment on lines 2141 to 2145
.map_err(|_e| {
warp_utils::reject::custom_bad_request(
"unable to fetch aggregate".to_string(),
)
})?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error's swallowed

Suggested change
.map_err(|_e| {
warp_utils::reject::custom_bad_request(
"unable to fetch aggregate".to_string(),
)
})?
.map_err(|e| {
warp_utils::reject::custom_bad_request(format!(
"unable to fetch aggregate: {e:?}"
))
})?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, thank you!

@realbigsean realbigsean added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Apr 7, 2022
@paulhauner
Copy link
Member Author

Thanks for the comments, apologies for the sloppy mistakes!

I've addressed all comments and fixed the merge conflict :)

Copy link
Member

@realbigsean realbigsean left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! LGTM

@realbigsean realbigsean added ready-for-merge This PR is ready to merge. and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Apr 8, 2022
@paulhauner
Copy link
Member Author

I'm blocking this on the v2.2.1 release (#3149)

@paulhauner
Copy link
Member Author

bors r+

bors bot pushed a commit that referenced this pull request Apr 13, 2022
## Issue Addressed

NA

## Proposed Changes

Disallow the production of attestations and retrieval of unaggregated attestations when they reference an optimistic head. Add tests to this end.

I also moved `BeaconChain::produce_unaggregated_attestation_for_block` to the `BeaconChainHarness`. It was only being used during tests, so it's nice to stop pretending it's production code. I also needed something that could produce attestations to optimistic blocks in order to simulate scenarios where the justified checkpoint is determined invalid (if no one would attest to an optimistic block, we could never justify it and then flip it to invalid).

## Additional Info

- ~~Blocked on #3126~~
@bors bors bot changed the title Disallow attesting to optimistic head [Merged by Bors] - Disallow attesting to optimistic head Apr 13, 2022
@bors bors bot closed this Apr 13, 2022
paulhauner added a commit to paulhauner/lighthouse that referenced this pull request May 6, 2022
## Issue Addressed

NA

## Proposed Changes

Disallow the production of attestations and retrieval of unaggregated attestations when they reference an optimistic head. Add tests to this end.

I also moved `BeaconChain::produce_unaggregated_attestation_for_block` to the `BeaconChainHarness`. It was only being used during tests, so it's nice to stop pretending it's production code. I also needed something that could produce attestations to optimistic blocks in order to simulate scenarios where the justified checkpoint is determined invalid (if no one would attest to an optimistic block, we could never justify it and then flip it to invalid).

## Additional Info

- ~~Blocked on sigp#3126~~
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bellatrix Required to support the Bellatrix Upgrade ready-for-merge This PR is ready to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants