Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Brad implementers guide revisions 2 #6239

Merged
merged 5 commits into from
Nov 11, 2022
Merged

Brad implementers guide revisions 2 #6239

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
07f413b
Add disputes subsystems fix
BradleyOlson64 Oct 18, 2022
6d28b3c
Updated dispute approval vote import reasoning
BradleyOlson64 Nov 6, 2022
e325f1d
Improved wording of my changes
BradleyOlson64 Nov 6, 2022
00eb4d0
Resolving issues brought up in comments
BradleyOlson64 Nov 11, 2022
ee4787b
Merge branch 'master' of https://github.com/paritytech/polkadot into …
BradleyOlson64 Nov 11, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Updated dispute approval vote import reasoning
  • Loading branch information
@BradleyOlson64
BradleyOlson64 committed Nov 6, 2022
commit 6d28b3c1fedbf38d9c2c81c252e7cdae8f817b6f
41 changes: 22 additions & 19 deletions roadmap/implementers-guide/src/node/disputes/dispute-coordinator.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ 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
- Ensuring lazy approval votes will be recorded, so nodes can get slashed
mrcnski marked this conversation as resolved.
Show resolved Hide resolved
properly.
- Coordinating actual participation in a dispute, ensuring that the node
participates in any justified dispute in a way that ensures resolution of
Expand Down Expand Up @@ -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 was decided sufficient to 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
Expand Down Expand Up @@ -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
Expand All @@ -199,11 +202,11 @@ 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. Again approval votes prove to be our weak spot here, but
also backing votes might get missed.
Copy link
Member

Choose a reason for hiding this comment

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

Nice @BradleyOlson64 ! Thanks! One thing to maybe highlight some more: As the only reason why we want to slash approval checkers is to give a strong incentive to actually do the checking, we just have to make it likely for them to get caught. We don't have to assume that they are willing to go through sophisticated attacks to avoid their vote to be recorded on some edge cases, as going through this trouble is not sensible: You are not lazy if you are going through a lot of trouble - it defeats the point. Paying engineers and infrastructure, devops, maintaining a fork, .. to pull off such an attack will never be cheaper than just doing the validation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Welcome! I think I've addressed your concern now, but feel free to make sure.


Dispute distribution will make sure all explicit dispute votes get distributed
among nodes which includes current block producers (current authority set) which
Expand Down