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

add a brief description of goals of the GRANDPA voting rule (#2053)

Browse Source
This commit is contained in:
Robert Habermeier
2020-12-07 17:23:44 -06:00
committed by GitHub
parent c74537fefd
commit 48746afd6a
2 changed files with 13 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
polkadot/roadmap/implementers-guide/src/SUMMARY.md
+2 -1
View File
@@ -32,7 +32,8 @@
- [Node Architecture](node/README.md) - [Node Architecture](node/README.md)
- [Subsystems and Jobs](node/subsystems-and-jobs.md) - [Subsystems and Jobs](node/subsystems-and-jobs.md)
- [Overseer](node/overseer.md) - [Overseer](node/overseer.md)
- [Collators](node/collators/README.md) - [GRANDPA Voting Rule](node/grandpa-voting-rule.md)
- [Collator Subsystems](node/collators/README.md)
- [Collation Generation](node/collators/collation-generation.md) - [Collation Generation](node/collators/collation-generation.md)
- [Collator Protocol](node/collators/collator-protocol.md) - [Collator Protocol](node/collators/collator-protocol.md)
- [Backing Subsystems](node/backing/README.md) - [Backing Subsystems](node/backing/README.md)
polkadot/roadmap/implementers-guide/src/node/grandpa-voting-rule.md
+11
View File
@@ -0,0 +1,11 @@
# GRANDPA Voting Rule
[GRANDPA](https://w3f-research.readthedocs.io/en/latest/polkadot/finality.html) is the finality engine of Polkadot.
One broad goal of finality, which applies across many different blockchains, is that there should exist only one finalized block at each height in the finalized chain. Before a block at a given height is finalized, it may compete with other forks.
GRANDPA's regular voting rule is for each validator to select the longest chain they are aware of. GRANDPA proceeds in rounds, collecting information from all online validators and determines the blocks that a supermajority of validators all have in common with each other.
For parachains, we extend the security guarantee of finality to be such that no invalid parachain candidate may be included in a finalized block. Candidates may be included in some fork of the relay chain with only a few backing votes behind them. After that point, we run the [Approvals Protocol](../protocol-approval.md), which is implemented as the [Approval Voting](approval/approval-voting.md) subsystem. This system involves validators self-selecting to re-check candidates included in all observed forks of the relay chain as well as an algorithm for observing validators' statements about assignment and approval in order to determine which candidates, and thus blocks, are with high probability valid. The highest approved ancestor of a given block can be determined by querying the Approval Voting subsystem via the [`ApprovalVotingMessage::ApprovedAncestor`](../types/overseer-protocol.md#approval-voting) message.
Lastly, we refuse to finalize any block including a candidate for which we are aware of an ongoing dispute or of a dispute resolving against the candidate. The exact means of doing this has not been determined yet.