pezkuwichain/pezkuwi-subxt
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-subxt.git synced 2026-06-17 14:51:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

Extract Assignments and Approval guide text to an Approval informational section (#1638)

Browse Source 
* move validity module to disputes module

* prepare a section on approvals

* extract approval/assignments text to an overview section

* Apply suggestions from code review

Spelling

Co-authored-by: Fedor Sakharov <fedor.sakharov@gmail.com>
This commit is contained in:
Robert Habermeier
2020-08-31 10:57:51 +02:00
committed by GitHub
parent bcafc81d9f
commit d246a2889e
8 changed files with 63 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/runtime/validity.md → polkadot/roadmap/implementers-guide/src/runtime/disputes.md
+1 -1
View File
@@ -1,4 +1,4 @@
# Validity Module
# Disputes Module
After a backed candidate is made available, it is included and proceeds into an acceptance period during which validators are randomly selected to do (secondary) approval checks of the parablock. Any reports disputing the validity of the candidate will cause escalation, where even more validators are requested to check the block, and so on, until either the parablock is determined to be invalid or valid. Those on the wrong side of the dispute are slashed and, if the parablock is deemed invalid, the relay chain is rolled back to a point before that block was included.
polkadot/roadmap/implementers-guide/src/runtime/scheduler.md
+1 -1
View File
@@ -82,7 +82,7 @@ digraph {
## Validator Groups
Validator group assignments do not need to change very quickly. The security benefits of fast rotation is redundant with the challenge mechanism in the [Validity module](validity.md). Because of this, we only divide validators into groups at the beginning of the session and do not shuffle membership during the session. However, we do take steps to ensure that no particular validator group has dominance over a single parachain or parathread-multiplexer for an entire session to provide better guarantees of liveness.
Validator group assignments do not need to change very quickly. The security benefits of fast rotation are redundant with the challenge mechanism in the [Approval process](../approval.md). Because of this, we only divide validators into groups at the beginning of the session and do not shuffle membership during the session. However, we do take steps to ensure that no particular validator group has dominance over a single parachain or parathread-multiplexer for an entire session to provide better guarantees of liveness.
Validator groups rotate across availability cores in a round-robin fashion, with rotation occurring at fixed intervals. The i'th group will be assigned to the `(i+k)%n`'th core at any point in time, where `k` is the number of rotations that have occurred in the session, and `n` is the number of cores. This makes upcoming rotations within the same session predictable.