Skip to main content

1. Overview

The Polkadot Protocol differentiates between different classes of Polkadot Hosts. Each class differs in its trust roots and how active or passively they interact with the network.

1.1. Light Client​

The light client is a mostly passive participant in the protocol. Light clients are designed to work in resource-constrained environments like browsers, mobile devices, or even on-chain. Its main objective is to follow the chain, make queries to the full node on specific information on the recent state of the blockchain, and add extrinsics (transactions). It does not maintain the full state but rather queries the full node on the latest finalized state and verifies the authenticity of the responses trustlessly. Details of specifications focused on Light Clients can be found in Chapter 7.

1.2. Full Node​

While the full node is still a mostly passive participant of the protocol, they follow the chain by receiving and verifying every block in the chain. It maintains a full state of the blockchain by executing the extrinsics in blocks. Their role in the consensus mechanism is limited to following the chain and not producing the blocks.

  • Functional Requirements:

    1. The node must populate the state storage with the official genesis state, elaborated further in Section A.3.3..

    2. The node should maintain a set of around 50 active peers at any time. New peers can be found using the discovery protocols (Section 4.4.)

    3. The node should open and maintain the various required streams (Section 4.7.) with each of its active peers.

    4. Furthermore, the node should send block requests (Section 4.8.3.) to these peers to receive all blocks in the chain and execute each of them.

    5. The node should exchange neighbor packets (Section 4.8.7.1.).

1.3. Authoring Node​

The authoring node covers all the features of the full node, but instead of just passively following the protocol, it is an active participant, producing blocks and voting in Grandpa.

  • Functional Requirements:

    1. Verify that the Host’s session key is included in the current Epoch’s authority set (Section 3.3.1.).

    2. Run the BABE lottery (Chapter 5) and wait for the next assigned slot in order to produce a block.

    3. Gossip any produced blocks to all connected peers (Section 4.8.2.).

    4. Run the catch-up protocol (Section 6.6.1.) to make sure that the node is participating in the current round and not a past round.

    5. Run the GRANDPA rounds protocol (Chapter 6).

1.4. Relaying Node​

The relaying node covers all the features of the authoring node but also participants in the availability and validity process to process new parachain blocks as described in Chapter 8.