Many applications that interact with the Polkadot network to some extent must be able to retrieve certain information about the network. Depending on the utility, this includes validators that interact with Polkadot’s consensus and need access to the full state, either from the past or just the most up-to-date state, or light clients that are only interest in the minimum information required in order to verify some claims about the state of the network, such as the balance of a specific account. To allow implemenations to quickly retrieve the required information, different types of synchronization protocols are available, respectivel Full, Fast and Warp sync suited for different needs.
The associated network messages are specified in Section 4.8..
3.1. Warp Sync
Warp sync (Section 4.8.4.) only downloads the block headers where authority set changes occurred, so called fragments (Definition 41), and by verifying the GRANDPA justifications (Definition 45). This protocols allows nodes to arrive at the desired state much faster than fast sync.
3.2. Fast Sync
Fast sync works by downloading the block header history and validating the auhtority set changes (Section 3.3.1.) in order to arrive at a specific (usually the most recent) header. After the desired header has been reached and verified, the state can be downloaded and imported (Section 4.8.3.). Once this process has been completed, the node can proceed with a full sync.
3.3. Full Sync
The full sync protocols is the "default" protocol that’s suited for many types of implementations, such as archive nodes (nodes that store everything), validators that participate in Polkadots consensus and light clients that only verify claims about the state of the network. Full sync works by listening to announced blocks (Section 4.8.1.) and requesting the blocks from the announcing peers, or just the block headers in case of light clients.
The full sync protocol usually downloads the entire chain, but no such requirements must be met. If an implemenation only wants the latest, finalized state, it can combine it with protocols such as fast sync (Section 3.2.) and/or warp sync (Section 3.1.) to make synchronization as fast as possible.
3.3.1. Consensus Authority Set
Because Polkadot is a proof-of-stake protocol, each of its consensus engines has its own set of nodes represented by known public keys, which have the authority to influence the protocol in pre-defined ways explained in this Section. To verify the validity of each block, the Polkadot node must track the current list of authorities (Definition 33) for that block.
Definition 33. Authority List
The authority list of block for consensus engine noted as is an array that contains the following pair of types for each of its authorities :
is the session public key (Definition 180) of authority . And is an unsigned 64-bit integer indicating the authority weight. The value of is part of the Polkadot state. The value for is set in the genesis state (Section A.3.) and can be retrieved using a runtime entrypoint corresponding to consensus engine .
The authorities and their corresponding weights can be retrieved from the Runtime (Section C.10.1.).
3.3.2. Runtime-to-Consensus Engine Message
The authority list (Definition 33) is part of the Polkadot state and the Runtime has the authority to update this list in the course of any state transitions. The Runtime informs the corresponding consensus engine about the changes in the authority set by adding the appropriate consensus message in the form of a digest item (Definition 11) to the block header of block which caused the transition in the authority set.
The Polkadot Host must inspect the digest header of each block and delegate consensus messages to their consensus engines. The BABE and GRANDPA consensus engine must react based on the type of consensus messages it receives. The active GRANDPA authorities can only vote for blocks that occurred after the finalized block in which they were selected. Any votes for blocks before the came into effect would get rejected.
3.4. Importing and Validating Block
Block validation is the process by which a node asserts that a block is fit to be added to the blockchain. This means that the block is consistent with the current state of the system and transitions to a new valid state.
New blocks can be received by the Polkadot Host via other peers (Section 4.8.2.) or from the Host’s own consensus engine (Chapter 5). Both the Runtime and the Polkadot Host then need to work together to assure block validity. A block is deemed valid if the block author had authorship rights for the slot in which the block was produce as well as if the transactions in the block constitute a valid transition of states. The former criterion is validated by the Polkadot Host according to the block production consensus protocol. The latter can be verified by the Polkadot Host invoking entry into the Runtime as (Section C.4.2.) as a part of the validation process. Any state changes created by this function on successful execution are persisted.
The Polkadot Host implements Import-and-Validate-Block to assure the validity of the block.
Algorithm 5. Import-and-Validate-Block
removes the Seal digest from the block (Definition 11) before submitting it to the Runtime.
adds the Seal digest back to the block (Definition 11) for later propagation.
implies the persistence of any state changes created by (Section C.4.2.) on successful execution.
is the pruned block tree (Definition 4).
is part of the block production consensus protocol and is described in Verify-Authorship-Right.
Finalized block and finality are defined in Chapter 6.