Brad implementers guide revisions 2 (#6239)

* Add disputes subsystems fix * Updated dispute approval vote import reasoning * Improved wording of my changes * Resolving issues brought up in comments
paritytech · ordian · Feb 1, 2023 · Oct 24, 2022 · Nov 7, 2022 · Nov 7, 2022
commit d7bd141cb64f27c9c6ac6502e54779613410c329
diff --git a/roadmap/implementers-guide/src/node/disputes/README.md b/roadmap/implementers-guide/src/node/disputes/README.md
@@ -5,7 +5,7 @@ This section is for the node-side subsystems that lead to participation in dispu
     * Participation. Participate in active disputes. When a node becomes aware of a dispute, it should recover the data for the disputed block, check the validity of the parablock, and issue a statement regarding the validity of the parablock.
     * Distribution. Validators should notify each other of active disputes and relevant statements over the network.
     * Submission. When authoring a block, a validator should inspect the state of the parent block and provide any information about disputes that the chain needs as part of the `ParaInherent`. This should initialize new disputes on-chain as necessary.
-    * Fork-choice and Finality. When observing a block issuing a `DisputeRollback` digest in the header, that branch of the relay chain should be abandoned all the way back to the indicated block. When voting on chains in GRANDPA, no chains that contain blocks that are or have been disputed should be voted on.
+    * Fork-choice and Finality. When observing a block issuing a `DisputeRollback` digest in the header, that branch of the relay chain should be abandoned all the way back to the indicated block. When voting on chains in GRANDPA, no chains that contain blocks with active disputes or disputes that concluded invalid should be voted on.
 
 ## Components
 

diff --git a/roadmap/implementers-guide/src/node/disputes/dispute-coordinator.md b/roadmap/implementers-guide/src/node/disputes/dispute-coordinator.md
@@ -9,8 +9,8 @@ In particular the dispute-coordinator is responsible for:
 
 - Ensuring that the node is able to raise a dispute in case an invalid candidate
   is found during approval checking.
-- Ensuring malicious approval votes will be recorded, so nodes can get slashed
-  properly.
+- Ensuring lazy approval votes (votes given without running the parachain 
+  validation function) will be recorded, so lazy nodes can get slashed properly.
 - Coordinating actual participation in a dispute, ensuring that the node
   participates in any justified dispute in a way that ensures resolution of
   disputes on the network even in the case of many disputes raised (flood/DoS
@@ -76,24 +76,27 @@ inefficient process. (Quadratic complexity adds up, with 35 votes in total per c
 Approval votes are very relevant nonetheless as we are going to see in the next
 section.
 
-## Ensuring Malicious Approval Votes Will Be Recorded
+## Ensuring Lazy Approval Votes Will Be Recorded
 
 ### Ensuring Recording
 
 While there is no need to record approval votes in the dispute coordinator
 preemptively, we do need to make sure they are recorded when a dispute
 actually happens. This is because only votes recorded by the dispute
-coordinator will be considered for slashing. While the backing group always gets
-slashed, a serious attack attempt will likely also consist of malicious approval
-checkers which will cast approval votes, although the candidate is invalid. If
-we did not import those votes, those nodes would likely cast an `invalid` explicit
-vote as part of the dispute in addition to their approval vote and thus avoid a
-slash. With the 2/3rd honest assumption it seems unrealistic that malicious
-actors will keep sending approval votes once they became aware of a raised
-dispute. Hence the most crucial approval votes to import are the early ones
-(tranche 0), to take into account network latencies and such we still want to
-import approval votes at a later point in time as well (in particular we need to
-make sure the dispute can conclude, but more on that later).
+coordinator will be considered for slashing. It is sufficient for our
+threat model that malicious backers are slashed as opposed to both backers and 
+approval checkers. However, we still must import approval votes from the approvals 
+process into the disputes process to ensure that lazy approval checkers 
+actually run the parachain validation function. Slashing lazy approval checkers is necessary, else we risk a useless approvals process where every approval 
+checker blindly votes valid for every candidate. If we did not import approval 
+votes, lazy nodes would likely cast a properly checked explicit vote as part 
+of the dispute in addition to their blind approval vote and thus avoid a slash. 
+With the 2/3rd honest assumption it seems unrealistic that lazy approval voters 
+will keep sending unchecked approval votes once they became aware of a raised 
+dispute. Hence the most crucial approval votes to import are the early ones 
+(tranche 0), to take into account network latencies and such we still want to 
+import approval votes at a later point in time as well (in particular we need 
+to make sure the dispute can conclude, but more on that later).
 
 As mentioned already previously, importing votes is most efficient when batched.
 At the same time approval voting and disputes are running concurrently so
@@ -173,7 +176,7 @@ There are two potential caveats with this though:
    voting. By distributing our own approval vote we make sure the dispute can
    conclude regardless how the race ended (we either participate explicitly
    anyway or we sent our already present approval vote). By importing all
-   approval votes we make it possible to slash malicious approval voters, even
+   approval votes we make it possible to slash lazy approval voters, even
    if they also cast an invalid explicit vote.
 
 Conclusion: As long as we make sure, if our own approval vote gets imported
@@ -199,11 +202,12 @@ time participation is faster than approval, a node would do double work.
 ### Ensuring Chain Import
 
 While in the previous section we discussed means for nodes to ensure relevant
-votes are recorded so attackers get slashed properly, it is crucial to also
-discuss the actual chain import. Only if we guarantee that recorded votes will
-also get imported on chain (on all potential chains really) we will succeed in
-executing slashes. Again approval votes prove to be our weak spot here, but also
-backing votes might get missed.
+votes are recorded so lazy approval checkers get slashed properly, it is crucial 
+to also discuss the actual chain import. Only if we guarantee that recorded votes 
+will also get imported on chain (on all potential chains really) we will succeed 
+in executing slashes. Particularly we need to make sure backing votes end up on 
+chain consistantly. In contrast recording and slashing lazy approval voters only 
+needs to be likely, not certain.
 
 Dispute distribution will make sure all explicit dispute votes get distributed
 among nodes which includes current block producers (current authority set) which
@@ -223,14 +227,14 @@ production in the current set - they might only exist on an already abandoned
 fork. This means a block producer that just joined the set, might not have seen
 any of them.
 
-For approvals it is even more tricky: Approval voting together with finalization
-is a completely off-chain process therefore those protocols don't care about
-block production at all. Approval votes only have a guarantee of being
-propagated between the nodes that are responsible for finalizing the concerned
-blocks. This implies that on an era change the current authority set, will not
-necessarily get informed about any approval votes for the previous era. Hence
-even if all validators of the previous era successfully recorded all approval
-votes in the dispute coordinator, they won't get a chance to put them on chain,
+For approvals it is even more tricky and less necessary: Approval voting together 
+with finalization is a completely off-chain process therefore those protocols 
+don't care about block production at all. Approval votes only have a guarantee of 
+being propagated between the nodes that are responsible for finalizing the 
+concerned blocks. This implies that on an era change the current authority set, 
+will not necessarily get informed about any approval votes for the previous era. 
+Hence even if all validators of the previous era successfully recorded all approval 
+votes in the dispute coordinator, they won't get a chance to put them on chain, 
 hence they won't be considered for slashing.
 
 It is important to note, that the essential properties of the system still hold: