Explicitly Handling ProvisionableData Cases

node/core/backing/src/lib.rs

@@ -774,7 +774,7 @@ async fn validate_and_make_available(
 			Err(candidate)
 		},
 		ValidationResult::Invalid(reason) => {
-			gum::debug!(
+			gum::warn!(
 				target: LOG_TARGET,
 				candidate_hash = ?candidate.hash(),
 				reason = ?reason,

node/core/provisioner/src/lib.rs

@@ -324,7 +324,23 @@ fn note_provisionable_data(
 				.with_para_id(backed_candidate.descriptor().para_id);
 			per_relay_parent.backed_candidates.push(backed_candidate)
 		},
-		_ => {},
+		// We choose to do nothing with misbehavior at this stage
+		ProvisionableData::MisbehaviorReport(_, _, _) => {},
+		// We wait and do nothing here, preferring to initiate a dispute after the 
+		// parablock candidate is included for the following reasons:
+		//
+		// 1. A dispute for a candidate triggered at any point before the candidate 
+		// has been made available, including the backing stage, can't be 
+		// guaranteed to conclude. Non-concluding disputes are unacceptable.
+		// 2. Candidates which haven't been made available don't pose a security 
+		// risk as they can not be included, approved, or finalized.  
+		//
+		// Currently we rely on approval checkers to trigger disputes for bad 
+		// parablocks once they are included. But we can do slightly better by 
+		// allowing disagreeing backers to record their disagreement and initiate a 
+		// dispute once the parablock in question has been included. This potential 
+		// change is tracked by: https://github.com/paritytech/polkadot/issues/3232
+		ProvisionableData::Dispute(_, _) => {},
 	}
 }
 

roadmap/implementers-guide/src/protocol-disputes.md

@@ -13,11 +13,15 @@ Disputes differ from backing and approval process (and can not be part of those)
 
 Every dispute stems from a disagreement among two or more validators. If a bad actor creates a bad block, but the bad actor never distributes it to honest validators, then nobody will dispute it. Of course, such a situation is not even an attack on the network, so we don't need to worry about defending against it.
 
-From most to least important, here are the attack scenarios we are interested in identifying and deterring:
+We are interested in identifying and deterring the following attack scenario:
   * A parablock included on a branch of the relay chain is bad
+
+We are also interested in identifying these additional scenarios:
   * A parablock backed on a branch of the relay chain is bad
   * A parablock seconded, but not backed on any branch of the relay chain, is bad.
 
+Punishing misbehavior in the latter two scenarios doesn't effect our security guarantees and introduces substantial technical challenges as described in the `No Disputes for Non Included Candidates` section of [Dispute Coordinator](./node/disputes/dispute-coordinator.md). We therefore choose to punt on disputes in these cases, instead favoring the protocol simplicity resulting from only punishing in the first scenario.
+
 As covered in the [protocol overview](./protocol-overview.md), checking a parachain block requires 3 pieces of data: the parachain validation code, the [`AvailableData`](types/availability.md), and the [`CandidateReceipt`](types/candidate.md). The validation code is available on-chain, and published ahead of time, so that no two branches of the relay chain have diverging views of the validation code for a given parachain. Note that only for the first scenario, where the parablock has been included on a branch of the relay chain, is the data necessarily available. Thus, dispute processes should begin with an availability process to ensure availability of the `AvailableData`. This availability process will conclude quickly if the data is already available. If the data is not already available, then the initiator of the dispute must make it available.
 
 Disputes have both an on-chain and an off-chain component. Slashing and punishment is handled on-chain, so votes by validators on either side of the dispute must be placed on-chain. Furthermore, a dispute on one branch of the relay chain should be transposed to all other active branches of the relay chain. The fact that slashing occurs _in all histories_ is crucial for deterring attempts to attack the network. The attacker should not be able to escape with their funds because the network has moved on to another branch of the relay chain where no attack was attempted.