The Polkadot protocol can be broken down into three parts: the consensus mechanism, the relay-chain with the parachains, and interchain transaction routing.

The Relay Chain

The relay-chain, similar to Ethereum, will provide accounting for which identity possesses what amount of stake in the system. However, there will be notable differences such as contracts cannot be deployed through transactions and compute resource usage is not accounted. Special functionality is supported for listed contracts that allows for auto-execution and network message outputs. The relay-chain will likely have a VM based around the EVM or a WebAssembly backend.

source: Polkadot Litepaper

Consensus Mechanism

There are a number of small pieces of functionality required for administrating the consensus mechanism, validator set, validation mechanism, and parachains. These could be implemented together under a monolithic protocol, but for reasons of modularity, they are described as “contracts” of the relay-chain.

The Staking Contract maintains the validator set, managing which accounts are currently validators and which have placed stake to become validators.

The Nominator Contract manages the nomination process, allowing accounts to nominate which accounts they want to be validators.

The Bonding Contract manages the bonding and unbonding of stake.

The Parachain Registry holds information about each chain, including the chain index, validation protocol identity, and aspects of the transaction routing system. Parachains can be added through full referendum voting, and can be suspended or removed under certain circumstances.

Sealing relay blocks is another crucial aspect of the protocol, as it involves the collection of signed statements from validators over the validity, availability and canonicality of a particular relay-chain block and the parachain blocks that it represents.

However, this sealing method does not scale out particularly well, as every parachain’s key information must have its availability guaranteed by over one-third of all validators. As a result, we will discuss improvements for sealing relay blocks and ways to mitigate the overhead placed on validator nodes. These include introducing latency, public participation, and availability guarantors.

It’s worth noting that as the system grows, the bandwidth required and latency until availability is known across the network increases with its square. This is a substantial growth factor and may turn out to be a notable road blocker and force us into “non-flat” paradigms such as composing several “Polkadotes” into a hierarchy for multi-level routing of posts through a tree of relay-chains.

Interchain Routing

As a reader, it is important to understand the concept of interchain transaction routing in Polkadot. This is the process by which a transaction, or “post,” is transferred from one source parachain to another destination parachain without any trust requirements.

The system uses several first-in-first-out (FIFO) queues, known as the routing base, which can support a certain number of parachains without the need for multi-phase routing. However, there is also a potential for “hyper-routing” to scale the system beyond the initial set of parachains.

The routing system follows several stages, including:

  1. Contacting members of the validators for the current block
  2. Ensuring availability of incoming post data from the last block
  3. Composing a block candidate for the current block
  4. Sending proof information to the validators for the current block
  5. Sending egress information for the next block to the receiving sub-group’s members
  6. Validators pre-connecting with members for the next block
  7. Collating all data ingress for the current block
  8. Accepting candidate proofs and egress data for the current and next block
  9. Voting on block validity and egress availability
  10. Repeating until consensus is reached.

It is important to note that collators, who collect transaction fees based on their blocks becoming canonical, have an incentive to ensure that the egress queues for the next block’s destinations are correct. With the correct understanding of interchain transaction routing, the reader can grasp the importance of this process in maintaining the reliability and security of the Polkadot network.

To be continued…

Leave a Reply