With the current document, we aim to specify the Polkadot Host part of the Polkadot protocol as a replicated state machine. After defining the different types of hosts in Chapter 1, we proceed to specify the representation of a valid state of the Protocol in Chapter 2. We also identify the protocol states by explaining the Polkadot state transition and discussing the detail based on which the Polkadot Host interacts with the state transition function, i.e., Runtime, in the same chapter. Following, we specify the input messages triggering the state transition and the system behavior. In Chapter 4, we specify the communication protocols and network messages required for the Polkadot Host to communicate with other nodes in the network, such as exchanging blocks and consensus messages. In Chapter 5 and Chapter 6, we specify the consensus protocol, which is responsible for keeping all the replicas in the same state. Finally, the initial state of the machine is identified and discussed in Section A.3.3.. A Polkadot Host implementation that conforms with this part of the specification should successfully be able to sync its states with the Polkadot network.
📄️ 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.
📄️ 2. States and Transitions
📄️ 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.
📄️ 4. Networking
This chapter, in its current form, is incomplete and considered work in progress. Authors appreciate receiving requests for clarification or any reports regarding deviation from the current Polkadot network protocol. This can be done by filing an issue in Polkadot Specification repository.
📄️ 5. Block Production
📄️ 6. Finality
📄️ 7. Light Clients
7.1. Requirements for Light Clients
📄️ 8. Availability & Validity
Polkadot serves as a replicated shared-state machine designed to resolve scalability issues and interoperability among blockchains. The validators of Polkadot execute transactions and participate in the consensus of Polkadots primary chain, the so-called relay chain. Parachains are independent networks that maintain their own state and are connected to the relay chain. Those parachains can take advantage of the relay chain consensus mechanism, including sending and receiving messages to and from other parachains. Parachain nodes that send parachain blocks, known as candidates, to the validators in order to be included in relay chain are referred to as collators.