mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-07-08 07:47:21 +00:00
Robert Habermeier
151d73af5b
* introduce candidatedescriptor type * add PoVDistribution message type * loosen bound on PoV Distribution to account for equivocations * re-export some types from the messages module * begin PoV Distribution subsystem * remove redundant index from PoV distribution * define state machine for pov distribution * handle overseer signals * set up control flow * remove `ValidatorStatement` section * implement PoV fetching * implement distribution logic * add missing ` * implement some network bridge event handlers * stub for message processing, handle our view change * control flow for handling messages * handle `awaiting` message * handle any incoming PoVs and redistribute * actually provide a subsystem implementation * remove set-builder notation * begin testing PoV distribution * test that we send awaiting messages only to peers with same view * ensure we distribute awaited PoVs to peers on view changes * test that peers can complete fetch and are rewarded * test some reporting logic * ensure peer is reported for flooding * test punishing peers diverging from awaited protocol * test that we eagerly complete peers' awaited PoVs based on what we receive * test that we prune the awaited set after receiving * expand pov-distribution in guide to match a change I made * remove unneeded import
Node Architecture
Design Goals
- Modularity: Components of the system should be as self-contained as possible. Communication boundaries between components should be well-defined and mockable. This is key to creating testable, easily reviewable code.
- Minimizing side effects: Components of the system should aim to minimize side effects and to communicate with other components via message-passing.
- Operational Safety: The software will be managing signing keys where conflicting messages can lead to large amounts of value to be slashed. Care should be taken to ensure that no messages are signed incorrectly or in conflict with each other.
The architecture of the node-side behavior aims to embody the Rust principles of ownership and message-passing to create clean, isolatable code. Each resource should have a single owner, with minimal sharing where unavoidable.
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.