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

Don't request block components until having block #5774

Merged
merged 4 commits into from
May 14, 2024

Conversation

dapplion
Copy link
Collaborator

Issue Addressed

Current stable when creating a new block lookup for block_root will:

  • Request block
  • Request all possible blobs for block_root before knowing if the block has blobs and how many

This optimistic / blind request forces us to handle the case where we have processed blobs + blocks and turns out that the blob peer did not return enough blobs.

By delaying fetching blobs until we get the block we can be sure to:

  • request blobs only when block has data
  • know exactly how many blobs we expect and penalize the peer immediately if it returns less blobs than expected

Proposed Changes

  • Update ActiveBlobsByRootRequest to expect peer to return exactly the number of requested blobs. Else error with NotEnoughResponsesReturned
  • If AvailabilityProcessingStatus::MissingComponents && both_components_processed == true hard error as an internal error. The condition above should ensure that this never happens
  • To cover the case of single_block_response_then_too_many_blobs_response_attestation the sync network context can produce multiple return values for a single request. In the test case it produces: (1) Some(blobs), (2) Err(TooManyResponses). However block lookup mod expects a single result, so we track if the request has been resolved (= a result value has been returned). If resolved, downscore but do not forward the result

@dapplion dapplion requested a review from realbigsean May 13, 2024 21:02
.block_missing_components() // blobs not yet imported
.blobs_response_was_valid()
.blob_imported(); // now blobs resolve as imported
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Blobs can't be returned first

.expect_penalty("NoResponseReturned")
.expect_block_request()
.expect_no_blobs_request();
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Scenario already covered by empty_block_is_retried

.expect_no_block_request()
.expect_no_blobs_request()
.block_response_triggering_process()
.missing_components_from_block_request();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Scenario already covered by empty_block_is_retried

.blobs_response() // blobs are not sent until the block is processed
.expect_no_penalty_and_no_requests()
.block_response_triggering_process();
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Can't respond blobs first, same for too_many_blobs_response_then_block_response_attestation

@realbigsean
Copy link
Member

@mergify queue

Copy link

mergify bot commented May 14, 2024

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at 683d9df

mergify bot added a commit that referenced this pull request May 14, 2024
@mergify mergify bot merged commit 683d9df into sigp:unstable May 14, 2024
27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants