mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-05-01 06:37:56 +00:00
Implementer's guide: Approval Voting Subsystem (#1691)
* add storage for approvals module * basics of approval logic * fix links * Session info module * create an approvals_inherent module * integrate approvals module with inclusion * Remove approvals runtime * tweak mentions of on-chain logic * add note on finality-grandpa voting rule * elaborate on node-side components * stub for availability recovery * add another note on voting rule * Beginnings of approval subsystems * flesh out approval voting now * logic for checking assignment certs * initial scheduler logic * scheduler logic * adjst tranche taking logic * approval voting import * approval work (voting side) * amend some TODOs * mark some TODOs * describe `ApprovedAncestor` * reference protocol-approval.md * clarity on bitfield * remove approvals_inherent * tweak session_info module according to review * formatting & nits Co-authored-by: Robert Habermeier <robert@Roberts-MacBook-Pro.local>
This commit is contained in:
committed by
GitHub
parent
d8b85dc3be
commit
43be64f2f7
@@ -10,7 +10,14 @@ The architecture of the node-side behavior aims to embody the Rust principles of
|
||||
|
||||
Many operations that need to be carried out involve the network, which is asynchronous. This asynchrony affects all core subsystems that rely on the network as well. The approach of hierarchical state machines is well-suited to this kind of environment.
|
||||
|
||||
We introduce a hierarchy of state machines consisting of an overseer supervising subsystems, where Subsystems can contain their own internal hierarchy of jobs. This is elaborated on in the next section on Subsystems.
|
||||
We introduce
|
||||
|
||||
## Components
|
||||
|
||||
The node architecture consists of the following components:
|
||||
* The Overseer (and subsystems): A hierarchy of state machines where an overseer supervises subsystems. Subsystems can contain their own internal hierarchy of jobs. This is elaborated on in the next section on Subsystems.
|
||||
* A block proposer: Logic triggered by the consensus algorithm of the chain when the node should author a block.
|
||||
* A GRANDPA voting rule: A strategy for selecting chains to vote on in the GRANDPA algorithm to ensure that only valid parachain candidates appear in finalized relay-chain blocks.
|
||||
|
||||
## Assumptions
|
||||
|
||||
|
||||
Reference in New Issue
Block a user