Do you know why the noise around Polkadot echoes at its loudest from 2023 onwards, after remaining quiet for a long period of time? Upgrades are to blame! From  agile coretime to  asynchronous backing, Polkadot’s one after another design marvels  have  brought Web 3 projects swarming like bees  to its ecosystem. But, when you are building that beautiful garden to attract the bees, you ought to protect those bees from the bee hunter’s as well. That’s what the Polkadot validator expansion  intends to do. 

What is Polkadot Validator Expansion? 

Polkadot Validator Expansion is an internal agreement as per the referendum 1129 to increase the validator set from 297 to 400 validators in order to scale the Polkadot ecosystem and protect it at the same time. Hence, acting as a protective agent when parachains flood  the Polkadot ecosystem. 

Why Is Polkadot Validator Expansion Necessary  for Protecting Parachains? 

In order to understand why the referendum 1129 proposed to increase the number of validator sets to 400 for parachains, we have to recall how parachains work and why it was  necessary to go for the Polkadot validator expansion. As you know, parachains are like deterministic state machines. So, each of those parachains are executing a long bundle of transactions grouped as a block to the relay chain. However, it is understandable that the parachains have their own state and the Polkadot ecosystem could be construed as a bigger set of all the subsets, which is the parachains. 

So, all the functions that are happening in  the subsets have to be consequently relayed to the main-set, which is the Polkadot Relay Chain for validation. Hence, making the Relay Chain, the state of states of all the parachain. Or, the sum of all the parachains. 

However, the process is not that simple since every parachain must prove to the Relay Chain through its STF or State-Transition Function. Under the STF, every new state transitions are merkelized to the roots and the STF verifies the root functions through a provenance tracking. So, if there’s a single change in the provenance, it will completely change the value of the Merkle Trie. Hence, invalidating the blocks. 

This validation process has to go through the  Relay chain validators. 

And, If the Relay chain validators are not satisfied with the proofs of new state transition of the parachain as per the STF, in that case, it would simply reject all the Proof-of-Verification (PoV) blocks coming from the parachain collators. However, putting up all the loads on a specific number of validators  to verify the (PoVs) will either make the chain centralized or bloated. Both these situations are a double edged sword for the ecosystem.  This is where the  Polkadot validator expansion helps parachains overcome this by solving two grave problems. 

How the Growing Polkadot Validator Expansion Will Help the Parachains?

Imagine we are in the time where there are not just 50+ parachains, but the numbers have breached the 500 mark. In such a situation, if there are supposedly fewer/lesser number of validator nodes validating for the parachain transaction, in that case, what this scenario will trigger. 

Scenario 1: High fees

In the first instance, since there will be a limited number of validators validating for the parachains, it would lead to a ruthless competition for block validation making the ecosystem non sustainable for small projects because they would have to ideally buy parachain slots at a very high price to help validate for their chain. 

Scenario 2: Potential Centralization 

Suppose, a Parachain named X is submitting fraudulent transactions to the relay chain validators. And, the validators are less in numbers. In such a case, it would be possible to easily get to a ⅔ majority  with a limited number of validators to compromise the network. 

On the contrary, if enough validators are there, in that case, it would ideally strike away the chances of guessing who would be validating for the next block and protect the Polkadot ecosystem in the following manner; 

• Prevent Fault Tolerant Defaults: When there are just a handful of validators to validate the transaction which are occurring massively at scale. Either, you end up completely centralizing the system or the network collapses. Both these events are increasingly harmful for the reputation of the ecosystem. Hence, a growing Polkadot’s validators expansion will eliminate the fault tolerance defaults because a higher number of nodes would demand more participation for consensus. Thereby, reducing the chances to corrupt/collude the network. 

• Prevent Collusion Defaults: Another advantage of growing the number of validators for the Polkadot ecosystem would be to keep collusion at bay for the parachains. There’s ideally a higher probability that when there are a handful of validators validating for the parachains, in that case, it can be a double edged sword. Where, though you may get a very low latency and high throughput, you are risking your ecosystem to be a sitting duck for sabotage. All of the validators can conspire to comprise the entire parachain ecosystem. 

• Consensus Defaults: When you have more validators in place to validate for the transactions, in that case, it is possible to move with a very robust consensus structure. It will seemingly strengthen the consensus of the ecosystem to make the parachains robust and secure through Polkadot validator expansion. For example, the recent spike in the validator has pushed the Polkadot’s Nakamoto coefficient to 112 from 93. Ideally, bettering from  other protocols like Near, Polygon, Ethereum, and Solana combined. That means, more trust has been bestowed in the Polkadot ecosystem attracting more parachains to build on top of the Polkadot ecosystem. 

What Benefits Polkadot Validator Expansion Brings  To  50+ and Growing Parachains? 

1. When the number of validators were increased from 300 to 500 in the first phase of the Kusama TestNet trials, it was observed that the CPU usage had dropped significantly. At the same time, the network bandwidth usage of approval voting protocols also shot up by 6x times. So, it has been concluded that the parachains might see at least 1.5x faster approvals on their proposals on the Relay Chain, improving their governance. Thus, making their experience super exciting while getting launched on top of the Polkadot ecosystem as a parachain, where they can enjoy complete sovereignty, scalability, security and decentralization, all occurring at once from hereon due to an increase in Polkadots validator expansion. 

2. Due to low CPU usage. It was possible to achieve  instant finality. However, in the erstwhile set-up, it was not possible.  Referendum 1129 makes way for validators to be assigned to vrf_modulo_samples. As per this, the validators can now initiate a single message/signature instead of one per candidate. So, if there are more than 50 validators to validate for the parachains, in that case, the total core count will be increased by 100. Which means, despite the number of parachains increasing in a linear fashion, from now onwards, the performance of the Polkadot ecosystem hosting n-number of parachains  will not be compromised at any point in time because of the Polkadot Validator expansion. Thereby, making the experience of running parachains reliable, fast and scalable. 

3. With more and more chains increasing, another potential pitfall is interchain communication. However, interchain chain communication in the Polkadot ecosystem is processed through a parachain validation mechanism. Which means that the parachains perform the role of a coprocessor to the Relay chain. 

However, when we are looking at cross-chain communication, in that case, it is ideally required to verify consensus mechanisms, consensus faults, state proofs and state transitions that happen off-chain on the parachains. In this regard,  PLONK, BEEFY Consensus  and The Barretenberg backend help in securing the proofs but these proofs can be accepted only when enough validators are available to validate for the POVs. 

Otherwise, it can seemingly obstruct interchain communication. Polkadot validator expansion ensures that such a thing doesn’t happen. Hence, allowing seamless cross chain communications that  50+ parachains can enjoy at any point in time and the same experience continues as more and more parachains are onboarded. 

These trade-offs that Polkadot validator expansion has granted would not only help build custom parachains but ideally enjoy unlimited scalability at the same time. But when launching your parachain, you need a trusted partner that can help you. 

Launch Your Polkadot Parachain With Perfuse’s managed AppChain Infrastructure 

Zeeve unveils Perfuse that helps you launch your Polkadot Parachain testnet in a few clicks. With its managed nodes, infrastructure components, dev tools, 24/7 monitoring, and dozens of necessary integrations. Perfuse abstracts all the hassles that you have to go through for launching your parachains. 

Visit our webpage for more information about Perfuse Parachain-related services. If you have any further queries, contact our support team, and they will help you deploy your parachain on the Polkadot & Kusama network.