Polkabeat: Measuring the decentralization of Parachains
Introducing Polkabeat
How decentralized is your parachain?
Web3 is all about decentralization. Polkadot has laid the groundwork for creating the next-generation of blockchains that are scalable, customizable, and most importantly decentralized. While the Polkadot relay chain set the standard for launching a blockchain and decentralizing it before users are at risk of centralization, not all parachains on Polkadot have followed this standard. Polkabeat helps users understand the risks associated with using each parachain on Polkadot.
There are risks in using blockchains that have points of centralization. If a blockchain has a point in its tech stack that allows a privileged few to control it, there are many ways users are forced to trust the network they are using. Centralization causes risks to users of a blockchain, including, but not limited to:
- Tokens being frozen
- Tokens being forcibly moved
- Users being censored
- Token supply being manipulated
- The chain being halted
- and many more…
Centralization also creates risk for those who control the blockchain, allowing them to be targets of extortion and law enforcement actions.
Polkabeat is here to highlight the points of centralization of each parachain on Polkadot so that users of these blockchains are aware and can encourage these chains to decentralize.
How Polkadot measures decentralization
There are three major points of centralization common to parachains, namely that of the sudo pallet, the council (if it has one), and the collator set.
The sudo pallet gives complete upgrade control to a single account or set of accounts. Having total control over upgrades gives a select, centralized group “god-mode” control over the blockchain, allowing them to do anything imaginable to it without any notice to users. This pallet is meant to be used during the launch process for quick-upgrades and should be removed from the parachain runtime altogether.
Each parachain may have a council. Councils are given special voting powers and vary from parachain to parachain. Councils routinely have the ability to vote on upgrades without the participation of the public token holders and in many ways, are a distributed sudo account if they are not elected by the token holders. A centralized council is less of a risk than having a sudo account due to a typical enactment delay of one to four weeks per upgrade, however this can be usurped by also having a technical committee that greatly speeds up this period, making it extraordinarily difficult for users to exit the token if they disagree with an upgrade.
Finally, the collators of a parachain are those that produce blocks. Having a centralized collator set allows this group to censor and reorder transactions for their own benefit and should be avoided.
What else?
These points of centralization also rest on two very important factors: a tradable token and an open-source client.
If a token is NOT tradable, then the parachain is considered still in the launch process and users are NOT at risk of being on a parachain with any of the points of centralization listed above. So we should cut these chains some slack as they finish up coding their blockchain and properly launching it. We should, however, encourage that these chains decentralize BEFORE launching their token on exchanges.
If a parachain team has not released the code to their client, it is a major risk to use the parachain as no code can be verified and users must trust the team to accurately describe every transaction/extrinsic as doing what it is supposed to. It is NOT recommended to use any blockchain that does not have an open source client.
Final thoughts/Next Steps
We have tried our best to make sure the information on this site is accurate, but this site is still under review by the community and should be considered in “beta” mode right now. Feel free to contact us using the form on the main page to let us know if there are any inaccuracies. Future plans may include expansion to Kusama parachains, creating an open-source database in a shareable format such as JSON, and using a better hosting service with capabilities for better user interaction.
We are also looking for contributors to the site. As you can tell, we need a designer. Use the contact form to let us know how you’d like to help!
Any tips or donations can be given to this address: 5Co5ujUEA6bErhcbRKNTjUuPV6ZTWzD1JXBF4DPP13a1orvZ
We are looking from feedback from the community to see if this project warrants support from the treasury in some way. Perhaps a tip is best for this?
So far we have spent around 340 EUR for yearly hosting and domain fees. Needless to say, there were hours of work that went into manually researching all parachains too.
Comments (2)
How decentralised are the relay and system chains?
Seems this would be a useful thing to understand as part of the project, since parachains rely on the relay and therefore their survivals are bound tightly together.
One parameter we are considering changing is the "democratically elected council." After receiving numerous messages about how this column is problematic for chains who don't follow a standard V1 governance model, we are considering changing it to "decentralized governance" where, in order to have a green checkmark for "decentralized governance," there must not be a governance body like a council that is selected by the founding team. If there is no council, a parachain would only get a ✅ if every body of governance is elected by token holders OR if the centralized body has powers to change the enactment period, which is common for many technical councils, including the Polkadot relay chain itself.