Stricter match of BlockError in sync #6321

dapplion · 2024-08-28T13:38:26Z

Issue Addressed

Builds on

Attribute invalid column proof error to correct peer #6377

I split the original scope of the PR into

Specific peer attributability -> Attribute invalid column proof error to correct peer #6377
Stricter match of BlockError in sync -> this PR, so we can keep @pawanjay176 's review

Proposed Changes

Sync needs act on an error and decide:

Should I penalize a peer for this error?
Which peer should I penalize?
Should I re-download this block component?

The title of this PR points to 1+2, but 3 is an important decision that should be handled in the same mega-match statement. Currently sync has catch-all match statements on errors which leave ample space for ambiguity and issues like this when functionality expands. I think it's better to have an explicit and long match statement that answers 1+2+3 in a single place, and sync is more "dumb".

⚠️ 🫱 please help me make sure that I mapping each error variant correctly.

dapplion · 2024-08-28T13:40:57Z

beacon_node/network/src/sync/block_lookups/mod.rs

+                                for peer in peer_group.of_index(index) {
+                                    cx.report_peer(
+                                        *peer,
+                                        PeerAction::MidToleranceError,


I think we should up this to LowToleranceError

dapplion · 2024-08-28T13:42:08Z

beacon_node/network/src/sync/block_lookups/mod.rs

-                            );
+                        let recoverable = match other.rpc_scoring() {
+                            ErrorCategory::Internal { recoverable } => {
+                                if matches!(other, BlockError::ExecutionPayloadError(_)) {


I kept this extra condition from the original match as I imagine that when EL goes offline the node would spam non-actionable errors

dapplion · 2024-08-28T13:45:16Z

beacon_node/beacon_chain/src/block_verification.rs

+            // The peer has nothing to do with this error, do not penalize them.
+            ExecutionPayloadError::RequestFailed(_) => ErrorCategory::internal_recoverable(),
+            // Execution payload is invalid
+            ExecutionPayloadError::RejectedByExecutionEngine { .. }


If EL says the payload is invalid we MUST downscore this peer if fetched from RPC right?

Yes, the peer has already imported the block into fork choice if we are fetching it over rpc

dapplion · 2024-08-28T13:46:10Z

beacon_node/beacon_chain/src/block_verification.rs

@@ -428,6 +472,30 @@ impl ExecutionPayloadError {
            ExecutionPayloadError::UnverifiedNonOptimisticCandidate => false,
        }
    }
+
+    pub fn penalize_rpc_peer(&self) -> ErrorCategory {


Should this match statements be in beacon_chain on in sync / network?

Considering that we are using this specifically to recover from errors in block_lookups, I think it should be in block lookups, but can be convinced either way

pawanjay176 · 2024-09-05T18:49:11Z

beacon_node/network/src/network_beacon_processor/sync_methods.rs

@@ -778,7 +778,7 @@ impl<T: BeaconChainTypes> NetworkBeaconProcessor<T> {
                })
            }
            ref err @ BlockError::ExecutionPayloadError(ref epe) => {
-                if !epe.penalize_peer() {
+                if !epe.penalize_gossip_peer() {


Suggested change

if !epe.penalize_gossip_peer() {

if !epe.penalize_rpc_peer() {

pawanjay176 · 2024-09-05T23:14:10Z

beacon_node/beacon_chain/src/data_availability_checker/error.rs

+            Error::KzgNotInitialized => ErrorCategory::internal_non_recoverable(),
+            Error::SszTypes(_) => ErrorCategory::internal_non_recoverable(),
+            // A ChainSegment RpcBlock does not include the expected blobs or columns
+            Error::MissingBlobs | Error::MissingCustodyColumns => {


Wouldn't these be malicious? A peer sent us a response to a rpc request which has missing blobs for the same block they sent

pawanjay176 · 2024-09-05T23:18:16Z

beacon_node/beacon_chain/src/data_availability_checker/error.rs

+                ErrorCategory::internal_recoverable()
+            }
+            // Assume these errors to be recoverable
+            Error::StoreError(_)
            | Error::DecodeError(_)


Maybe decode errors are malicious too? I couldn't track down the exact place where we would return this error but seems like a peer issue

pawanjay176 · 2024-09-05T23:19:54Z

beacon_node/beacon_chain/src/data_availability_checker/error.rs

+                ErrorCategory::internal_recoverable()
+            }
+            // Assume these errors to be recoverable
+            Error::StoreError(_)
            | Error::DecodeError(_)
            | Error::Unexpected
            | Error::ParentStateMissing(_)
            | Error::BlockReplayError(_)
            | Error::UnableToDetermineImportRequirement


Seems like this variant isn't used anywhere, can delete

pawanjay176 · 2024-09-05T23:55:11Z

beacon_node/network/src/sync/network_context.rs

@@ -137,6 +137,15 @@ impl PeerGroup {
    pub fn all(&self) -> impl Iterator<Item = &PeerId> + '_ {
        self.peers.keys()
    }
+    pub fn of_index(&self, index: usize) -> impl Iterator<Item = &PeerId> + '_ {


Not completely sure why we need an iterator here. Would there be a scenario where you get > 1 peer responsible for a single index here?

Harder to model with the type here, should we just return the first match? Or enforce uniqueness on the reverse index -> peer mapping?

First match seems good to me

pawanjay176 · 2024-09-06T20:09:09Z

beacon_node/beacon_chain/src/block_verification.rs

+            Self::BlockIsNotLaterThanParent { .. } => ErrorCategory::malicious_non_recoverable(),
+            // TODO: Not clear what to set here
+            Self::NonLinearParentRoots => ErrorCategory::malicious_recoverable(),
+            Self::NonLinearSlots => ErrorCategory::malicious_recoverable(),


same as above

pawanjay176 · 2024-09-06T20:12:07Z

beacon_node/beacon_chain/src/block_verification.rs

+            Self::NonLinearSlots => ErrorCategory::malicious_recoverable(),
+            // TODO: Ensure the proposer signature is not part of this error set
+            Self::PerBlockProcessingError(_) => ErrorCategory::malicious_non_recoverable(),
+            // TODO: Are we sure all BeaconChainError are internal?


I think that is a fair assumption

pawanjay176 · 2024-09-06T20:15:14Z

beacon_node/beacon_chain/src/block_verification.rs

+                ErrorCategory::malicious_non_recoverable()
+            }
+            // TODO: Check if correct
+            Self::Slashable => ErrorCategory::malicious_non_recoverable(),


This is a proposer making a slashable block, neither the peer's fault nor is it our fault. Maybe needs a special case

pawanjay176 · 2024-09-06T20:23:46Z

beacon_node/beacon_chain/src/block_verification.rs

+            // The peer has nothing to do with this error, do not penalize them.
+            ExecutionPayloadError::RequestFailed(_) => ErrorCategory::internal_recoverable(),
+            // Execution payload is invalid
+            ExecutionPayloadError::RejectedByExecutionEngine { .. }


Yes, the peer has already imported the block into fork choice if we are fetching it over rpc

pawanjay176 · 2024-09-06T20:24:27Z

beacon_node/beacon_chain/src/data_availability_checker.rs

@@ -199,9 +199,11 @@ impl<T: BeaconChainTypes> DataAvailabilityChecker<T> {
            .now_duration()
            .ok_or(AvailabilityCheckError::SlotClockError)?;

+        // Note: currenlty not reporting which specific blob is invalid because we fetch all blobs


Suggested change

// Note: currenlty not reporting which specific blob is invalid because we fetch all blobs

// Note: currently not reporting which specific blob is invalid because we fetch all blobs

dapplion commented Aug 28, 2024

View reviewed changes

Attribute invalid column proof error to correct peer

5a69a7b

dapplion force-pushed the peerdas-peergroup-scoring branch from a2ffbd2 to 5a69a7b Compare August 28, 2024 13:46

dapplion requested review from jimmygchen, pawanjay176 and realbigsean August 28, 2024 13:47

pawanjay176 added the under-review A reviewer has only partially completed a review. label Aug 29, 2024

pawanjay176 reviewed Sep 6, 2024

View reviewed changes

dapplion changed the base branch from unstable to peerdas-peergroup-scoring-only September 9, 2024 11:55

dapplion changed the title ~~Attribute invalid column proof error to correct peer~~ Stricter match of BlockError in sync Sep 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stricter match of BlockError in sync #6321

Stricter match of BlockError in sync #6321

dapplion commented Aug 28, 2024 •

edited

Loading

dapplion Aug 28, 2024

dapplion Aug 28, 2024

dapplion Aug 28, 2024 •

edited

Loading

pawanjay176 Sep 6, 2024

dapplion Aug 28, 2024

pawanjay176 Sep 6, 2024

pawanjay176 Sep 5, 2024

pawanjay176 Sep 5, 2024

pawanjay176 Sep 5, 2024

pawanjay176 Sep 5, 2024

pawanjay176 Sep 5, 2024

dapplion Sep 9, 2024

pawanjay176 Sep 9, 2024

pawanjay176 Sep 6, 2024

pawanjay176 Sep 6, 2024

pawanjay176 Sep 6, 2024

pawanjay176 Sep 6, 2024

pawanjay176 Sep 6, 2024

	if !epe.penalize_gossip_peer() {
	if !epe.penalize_rpc_peer() {

	// Note: currenlty not reporting which specific blob is invalid because we fetch all blobs
	// Note: currently not reporting which specific blob is invalid because we fetch all blobs

Stricter match of BlockError in sync #6321

Are you sure you want to change the base?

Stricter match of BlockError in sync #6321

Conversation

dapplion commented Aug 28, 2024 • edited Loading

Issue Addressed

Proposed Changes

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dapplion Aug 28, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dapplion commented Aug 28, 2024 •

edited

Loading

dapplion Aug 28, 2024 •

edited

Loading