pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-20 11:41:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Brad implementers guide revisions 2 (#6239)

Browse Source 
* Add disputes subsystems fix

* Updated dispute approval vote import reasoning

* Improved wording of my changes

* Resolving issues brought up in comments
This commit is contained in:
Bradley Olson
2022-11-11 11:24:40 -08:00
committed by GitHub
parent 79d9ea4f62
commit 0cea4eedce
2 changed files with 33 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/node/disputes/README.md
+1 -1
View File
@@ -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. * 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. * 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. * 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 ## Components
polkadot/roadmap/implementers-guide/src/node/disputes/dispute-coordinator.md
+29 -25
View File
@@ -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 - Ensuring that the node is able to raise a dispute in case an invalid candidate
is found during approval checking. is found during approval checking.
- Ensuring malicious approval votes will be recorded, so nodes can get slashed - Ensuring lazy approval votes (votes given without running the parachain
properly. validation function) will be recorded, so lazy nodes can get slashed properly.
- Coordinating actual participation in a dispute, ensuring that the node - Coordinating actual participation in a dispute, ensuring that the node
participates in any justified dispute in a way that ensures resolution of 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 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 Approval votes are very relevant nonetheless as we are going to see in the next
section. section.
## Ensuring Malicious Approval Votes Will Be Recorded ## Ensuring Lazy Approval Votes Will Be Recorded
### Ensuring Recording ### Ensuring Recording
While there is no need to record approval votes in the dispute coordinator 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 preemptively, we do need to make sure they are recorded when a dispute
actually happens. This is because only votes recorded by the dispute actually happens. This is because only votes recorded by the dispute
coordinator will be considered for slashing. While the backing group always gets coordinator will be considered for slashing. It is sufficient for our
slashed, a serious attack attempt will likely also consist of malicious approval threat model that malicious backers are slashed as opposed to both backers and
checkers which will cast approval votes, although the candidate is invalid. If approval checkers. However, we still must import approval votes from the approvals
we did not import those votes, those nodes would likely cast an `invalid` explicit process into the disputes process to ensure that lazy approval checkers
vote as part of the dispute in addition to their approval vote and thus avoid a actually run the parachain validation function. Slashing lazy approval checkers is necessary, else we risk a useless approvals process where every approval
slash. With the 2/3rd honest assumption it seems unrealistic that malicious checker blindly votes valid for every candidate. If we did not import approval
actors will keep sending approval votes once they became aware of a raised 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 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 (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 import approval votes at a later point in time as well (in particular we need
make sure the dispute can conclude, but more on that later). to make sure the dispute can conclude, but more on that later).
As mentioned already previously, importing votes is most efficient when batched. As mentioned already previously, importing votes is most efficient when batched.
At the same time approval voting and disputes are running concurrently so 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 voting. By distributing our own approval vote we make sure the dispute can
conclude regardless how the race ended (we either participate explicitly conclude regardless how the race ended (we either participate explicitly
anyway or we sent our already present approval vote). By importing all 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. if they also cast an invalid explicit vote.
Conclusion: As long as we make sure, if our own approval vote gets imported 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 ### Ensuring Chain Import
While in the previous section we discussed means for nodes to ensure relevant 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 votes are recorded so lazy approval checkers get slashed properly, it is crucial
discuss the actual chain import. Only if we guarantee that recorded votes will to also discuss the actual chain import. Only if we guarantee that recorded votes
also get imported on chain (on all potential chains really) we will succeed in will also get imported on chain (on all potential chains really) we will succeed
executing slashes. Again approval votes prove to be our weak spot here, but also in executing slashes. Particularly we need to make sure backing votes end up on
backing votes might get missed. 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 Dispute distribution will make sure all explicit dispute votes get distributed
among nodes which includes current block producers (current authority set) which among nodes which includes current block producers (current authority set) which
@@ -223,13 +227,13 @@ 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 fork. This means a block producer that just joined the set, might not have seen
any of them. any of them.
For approvals it is even more tricky: Approval voting together with finalization For approvals it is even more tricky and less necessary: Approval voting together
is a completely off-chain process therefore those protocols don't care about with finalization is a completely off-chain process therefore those protocols
block production at all. Approval votes only have a guarantee of being don't care about block production at all. Approval votes only have a guarantee of
propagated between the nodes that are responsible for finalizing the concerned being propagated between the nodes that are responsible for finalizing the
blocks. This implies that on an era change the current authority set, will not concerned blocks. This implies that on an era change the current authority set,
necessarily get informed about any approval votes for the previous era. Hence will not necessarily get informed about any approval votes for the previous era.
even if all validators of the previous era successfully recorded all approval 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, votes in the dispute coordinator, they won't get a chance to put them on chain,
hence they won't be considered for slashing. hence they won't be considered for slashing.