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

Commit 3396396

Browse files
drahnrdrahnr
authored
high altitude description of disputes (#2285)
1 parent def49db commit 3396396

File tree

5 files changed

+212
-2
lines changed

5 files changed

+212
-2
lines changed

‎.config/lingua.dic‎

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -85,4 +85,12 @@ WND/S
8585
XCM/S
8686
XCMP/M
8787
include/BG
88-
isolate/BG
88+
isolate/BG
89+
dispatchable/SM
90+
VMP/SM
91+
HMP/SM
92+
DMP/SM
93+
MQC/SM
94+
VRF/SM
95+
assignee/SM
96+
adversary/SM

‎.config/spellcheck.toml‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,7 @@ extra_dictionaries = ["lingua.dic"]
77
# `Type`'s
88
# 5x
99
# He tagged it as 'TheGreatestOfAllTimes'
10-
transform_regex = ["^'([^\\s])'$", "^[0-9]+(?:\\.[0-9]*)?x$", "^'s$", "^\\+$"]
10+
# Transforms'
11+
transform_regex = ["^'([^\\s])'$", "^[0-9]+(?:\\.[0-9]*)?x$", "^(.*)'$", "^\\+$"]
1112
allow_concatenation = true
1213
allow_dashes = true

‎roadmap/implementers-guide/src/SUMMARY.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,8 @@
55
- [Whence Parachains](whence-parachains.md)
66
- [Protocol Overview](protocol-overview.md)
77
- [Approval Process](protocol-approval.md)
8+
- [Disputes Process](protocol-disputes.md)
9+
- [Dispute Flow](disputes-flow.md)
810
- [Architecture Overview](architecture.md)
911
- [Messaging Overview](messaging.md)
1012
- [Runtime Architecture](runtime/README.md)

‎roadmap/implementers-guide/src/disputes-flow.md‎

Lines changed: 125 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,125 @@
1+
# Disputes Flows
2+
3+
A component-free description in what-if form with addition state graphs of the dispute.
4+
5+
```mermaid
6+
stateDiagram-v2
7+
[*] --> WaitForBackingVote: negative Vote received
8+
[*] --> WaitForDisputeVote: backing Vote received
9+
WaitForBackingVote --> Open: negative Vote received
10+
WaitForDisputeVote --> Open: backing Vote received
11+
Open --> Concluded: Timeout without supermajority
12+
Open --> Concluded: Incoming Vote via Gossip
13+
Open --> Open: No ⅔ supermajority
14+
Open --> [*]
15+
Concluded --> [*]
16+
```
17+
18+
---
19+
20+
```mermaid
21+
stateDiagram-v2
22+
[*] --> Open: First Vote(s) received
23+
Open --> HasPoV : Fetch Availability Store for PoV
24+
25+
HasPoV --> HasCode : Fetch historical Code
26+
HasCode --> VerifyWithRuntime: All Data locally avail
27+
28+
Open --> DisputeAvailabilityDataReceived
29+
DisputeAvailabilityDataReceived --> VerifyWithRuntime: Received Gossip
30+
31+
HasPoV --> RequestDisputeAvailabilityData: nope
32+
HasCode --> RequestDisputeAvailabilityData: nope
33+
RequestDisputeAvailabilityData --> VerifyWithRuntime: Received
34+
RequestDisputeAvailabilityData --> RequestDisputeAvailabilityData: Timed out - pick another peer
35+
36+
VerifyWithRuntime --> CastVoteValid: Block Valid
37+
VerifyWithRuntime --> CastVoteInvalid: Block Invalid
38+
CastVoteInvalid --> GossipVote
39+
CastVoteValid --> GossipVote
40+
GossipVote --> [*]
41+
42+
```
43+
44+
---
45+
46+
Dispute Availability Data
47+
48+
```mermaid
49+
stateDiagram-v2
50+
[*] --> Open: First Vote(s) received
51+
Open --> DisputeDataAvail: somehow the data became available
52+
Open --> RespondUnavailable: Data not available
53+
IncomingRequestDisputeAvailabilityData --> RespondUnavailable
54+
IncomingRequestDisputeAvailabilityData --> DisputeDataAvail
55+
DisputeDataAvail --> RespondWithDisputeAvailabilityData: Send
56+
VoteGossipReceived --> Track: implies source peer has<br />dispute availablity data
57+
```
58+
59+
---
60+
61+
Peer handling
62+
63+
```mermaid
64+
stateDiagram-v2
65+
[*] --> Open: First Vote(s) received
66+
Open --> GossipVotes: for all current peers
67+
Open --> PeerConnected: another
68+
PeerConnected --> GossipVotes: Peer connects
69+
GossipVotes --> [*]
70+
```
71+
72+
## Conditional formulation
73+
74+
The set of validators eligible to vote consists of
75+
the validators that had duty at the time of backing, plus backing votes by the backing validators.
76+
77+
If a validator receives an initial dispute message (a set of votes where there are at least two opposing votes contained), and the PoV or Code are hence not reconstructable from local storage, that validator must request the required data from its peers.
78+
79+
The dispute availability message must contain code, persisted validation data, and the proof of validity.
80+
81+
Only peers that already voted shall be queried for the dispute availability data.
82+
83+
The peer to be queried for disputes data, must be picked at random.
84+
85+
A validator must retain code, persisted validation data and PoV until a block, that contains the dispute resolution, is finalized - plus an additional 24h.
86+
87+
Dispute availability gossip must continue beyond the dispute resolution, until the post resolution timeout expired (equiv to the timeout until which additional late votes are accepted).
88+
89+
Remote disputes are disputes that are in relation to a chain that is not part of the local validators active heads.
90+
91+
All incoming votes must be persisted.
92+
93+
Persisted votes stay persisted for `N` sessions, and are cleaned up on a per session basis.
94+
95+
Votes must be queryable by a particular validator, identified by its signing key.
96+
97+
Votes must be queryable by a particular validator, identified by a session index and the validator index valid in that session.
98+
99+
If there exists a negative and a positive fork for a particular block, a dispute is detected.
100+
101+
If a dispute is detected, all currently available votes for that block must be gossiped.
102+
103+
If an incoming dispute vote is detected, a validator must cast their own vote. The vote is determined by validating the PoV with the Code at the time of backing the block in question.
104+
105+
If the validator was also a backer of the block, validation and casting an additional vote should be skipped.
106+
107+
If the count of votes pro or cons regarding the disputed block, reaches the required ⅔ supermajority (including the backing votes), the conclusion must be recorded on chain and the voters on the loosing and no-shows being slashed appropriately.
108+
109+
If a block is found invalid by a dispute resolution, it must be blacklisted to avoid resync or further build on that chain if other chains are available (to be detailed in the grandpa fork choice rule).
110+
111+
A dispute accepts Votes after the dispute is resolved, for 1d.
112+
113+
If a vote is received, after the dispute is resolved, the vote shall still be recorded in the state root, albeit yielding less reward.
114+
115+
Recording in the state root might happen batched, at timeout expiry.
116+
117+
If a new active head/chain appears, and the dispute resolution was not recorded on that chain yet, the dispute resolution or open dispute must be recorded / transplanted to that chain as well, since the disputes must be present on all chains to make sure the offender is punished.
118+
119+
If a validator votes in two opposing ways, this composes of a double vote like in other cases (backing, approval voting).
120+
121+
If a dispute is not resolved within due time, all validators are to be slashed for a small amount.
122+
123+
If a dispute is not resolved within due time, governance mode shall be entered for manual resolution.
124+
125+
If a validator unexpectedly restarts, the dispute shall be continued with the state based on votes being cast and being present in persistent storage.

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

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# Disputes
2+
3+
Fast forward to [more detailed disputes requirments](./disputes-flow.md).
4+
5+
## Motivation
6+
7+
All blocks that end up on chain should be valid.
8+
9+
To ensure attempts, successful or not, of including
10+
a block that is invalid in respect to the validation code, must therefore be handled in some way with the offenders being punished and the whistle blowers being rewarded. Disputes and their resolution are the formal process to resolve these situations.
11+
12+
At some point a validator claims that the `PoV` (proof of validity) - which was distributed with candidate block - for a certain block is invalid.
13+
14+
Now the dispute can be happening quite some time later than the inclusion, but also right during backing. As such the block is stored or more so its Reed-Solomon encoded erasure chunks, from which the
15+
PoV can be reconstructed.
16+
17+
A reconstructed PoV can be verified with the defined verification code, that is valid during the session the block was included or backed.
18+
If the block is invalid and there exists at least one backing vote and one validity challenging vote, a dispute exists.
19+
The existence of a dispute is detected by a backing checker
20+
or, if the block made it through backing stage, by an approval checker.
21+
In either case, the validator casts and distributes its vote via means of gossip.
22+
23+
At this point the set of backing validators can not be trusted (since they voted for the block despite something being
24+
fishy at the very least). On the other hand, one must also consider, the validator that blew the whistle has ulterior motives
25+
to do so (i.e. it is controlled by a third party and wants to incur damage to itself).
26+
In either way, there are malicious validators around.
27+
As a consequence, all validators at the time of block backing, are being notified via broadcast of
28+
the first pair of backing and challenging vote.
29+
Validators that backed the candidate implicitly count as votes. Those validators are allowed to cast
30+
a regular vote (a non-backing vote) as well, but it is generally not in their interest to vote both sides, since that would
31+
advance the progress towards supermajority either way and have their bonds slashed.
32+
If both votes lean in the same direction, i.e. both positive they are only counted as one.
33+
Two opposing votes by the same validator would be equal to an attempted double vote and would be slashed accordingly.
34+
35+
All validators at block inclusion time are eligible to (and should) cast their Vote. The backing votes of backing checkers
36+
are counted as votes as well.
37+
38+
## Initiation
39+
40+
A dispute is initiated by one approval checker creating and gossiping a vote, that challenges another vote.
41+
42+
After a backing or approval checker challenged a block, all validators that received the gossiped vote, reconstruct the block
43+
from availability erasure code chunks and check the block's PoV themselves via the validation code.
44+
The result of that check is converted into a vote, and distributed via the same mechanics as the first one.
45+
46+
Once a receiver receives ⅔ supermajority in one or the other direction, the
47+
vote is concluded.
48+
Conclusion implies that the result for this block can not be altered anymore, valid or invalid is fixed now.
49+
50+
In order to ensure, the dispute result is not forgotten or intentionally side stepped, it has to be recorded on chain.
51+
This on chain recording mechanic must be vigilant, in a sense, that new emerging forks
52+
must also receive the dispute resolution recorded (transplantation) irrespectively of the disputed block being included in that chain or not.
53+
54+
If the disputed block was already finalized, the chain must be put in governance mode to be resolved by human interaction
55+
(i.e. sudo or motion or other mechanics that are available ).
56+
57+
As such the validator has to keep track of all votes irrespective if the disputed block is already known or not.
58+
All backing votes should be either kept in storage as well, or be queried on demand, since they are a kind of vote
59+
as well.
60+
61+
## Late votes
62+
63+
Late votes, after the dispute already reached a ⅔ supermajority, must be rewarded (albeit a smaller amount) as well.
64+
These ones must be attached to the votes after a defined period of time after the result has reached
65+
the required ⅔ supermajority.
66+
67+
## Chain Selection / Grandpa
68+
69+
Chain selection should be influenced by the chance of picking a chain that does not even include the disputed block.
70+
Hence removing the need to include the dispute resolution itself.
71+
This is only possible though, if the set of active heads contains such a fork.
72+
In Grandpa the Voting rule should be used to avoid finalizing chains that contain an open or negative shut (shut with supermajority that marks the block as invalid) dispute.
73+
In case all possible chains contains such a dispute, a metric must be used to decide which fork to use or avoid finalization until one dispute resolves positive (the
74+
block is valid).

0 commit comments

Comments
 (0)