Skip to main content

3. Synchronization

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 interested 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 implementations to quickly retrieve the required information, different types of synchronization protocols are available, respectively 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.5.) only downloads the block headers where authority set changes occurred, so-called fragments (Definition 46), and by verifying the GRANDPA justifications (Definition 50). This protocol 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 authority 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.4.). Once this process has been completed, the node will automatically switch to a full sync.

3.3. Full Sync​

The full sync protocol 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.2.) 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 implementation 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 B{B} for consensus engine C{C} noted as AuthC(B)\text{Auth}_{{C}}{\left({B}\right)} is an array that contains the following pair of types for each of its authorities A∈AuthC(B){A}\in\text{Auth}_{{C}}{\left({B}\right)}:

(pkA,wA){\left({p}{k}_{{A}},{w}_{{A}}\right)}

pkA{p}{k}_{{A}} is the session public key (Definition 190) of authority A{A}. And wA{w}_{{A}} is an unsigned 64-bit integer indicating the authority weight. The value of AuthC(B)\text{Auth}_{{C}}{\left({B}\right)} is part of the Polkadot state. The value for AuthC(B0)\text{Auth}_{{C}}{\left({B}_{{0}}\right)} is set in the genesis state (Section A.3.3.) and can be retrieved using a runtime entrypoint corresponding to consensus engine C{C}.

The authorities and their corresponding weights can be retrieved from the Runtime (Section C.10.1.).

info

In Polkadot, the authorities are unweighted, i.e., the weights for all authorities are set to 1. The proportionality in terms of stakes is managed by the NPOS (Nominated Proof-of-Stake) algorithm in Polkadot. Once validators are elected for an era using the NPOS algorithm, they are considered equal in the BABE and GRANDPA consensus algorithms.

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 B{B} 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 they 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.3.) 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 produced 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​
\begin{algorithm}
\caption{Import-and-Validate-Block}
\begin{algorithmic}
    \require $B, \text{Just}(B)$
    \state \call{Set-Storage-State-At}{$P(B)$}
    \if{$\text{Just}(B) \neq \emptyset$}
        \state \call{Verify-Block-Justification}{$B, \text{Just}(B)$}
        \if{$B~\textbf{is}~\text{Finalized}~\textbf{and}~P(B)~\textbf{is not}~\text{Finalized}$}
            \state \call{Mark-as-Final}{$P(B)$}
        \endif
    \endif
    \if{$H_p(B) \notin PBT$}
        \return
    \endif
    \state \call{Verify-Authorship-Right}{$\text{Head}(B)$}
    \state $B \leftarrow$ \call{Remove-Seal}{$B$}
    \state $R \leftarrow$ \call{Call-Runtime-Entry}{$\texttt{Core\_execute\_block}, B$}
    \state $B \leftarrow$ \call{Add-Seal}{$B$}
    \if{$R =$ \textsc{True}}
        \state \call{Persist-State}{}
    \endif
\end{algorithmic}
\end{algorithm}

where

  • Remove-Seal\text{Remove-Seal} removes the Seal digest from the block (Definition 11) before submitting it to the Runtime.

  • Add-Seal\text{Add-Seal} adds the Seal digest back to the block (Definition 11) for later propagation.

  • Persist-State\text{Persist-State} implies the persistence of any state changes created by Core_execute_block{\mathtt{\text{Core\_execute\_block}}} (Section C.4.2.) on successful execution.

  • PBT\text{PBT} is the pruned block tree (Definition 4).

  • Verify-Authorship-Right\text{Verify-Authorship-Right} is part of the block production consensus protocol and is described in Verify-Authorship-Right.

  • Finalized block and finality are defined in Chapter 6.