Decentralization is a core tenet of Web3, but is often neglected in order to get to market faster or to achieve higher transaction throughput. Polkadot sets a high bar for decentralization, and we believe we must maintain that standard in our parachain implementation that will live within this ecosystem.
In order to explain our point of view on decentralization, it’s important to first understand the underlying motivations for why we are working on Moonbeam in the first place.
Decentralized Technologies Can Create Positive Change in the World
History shows us that it is very difficult to avoid abuse when you have large power concentrations. We believe that the world already has too many concentrations of power. As the world continues to transition from primarily physical to software-centric forms of interaction, these concentrations of power (if left unchecked) will grow even larger.
Web3-based applications can serve to check and defray these concentrations of power. They can, and will, enable new decentralized forms of coordination, interaction, and collaboration. We believe that the world will be a better place with these decentralized forms in place. These underlying beliefs and ideas have informed much of how we designed Moonbeam.
Polkadot’s Decentralization Was Part of Its Appeal
The decentralization of the Polkadot and Kusama Relay Chains was a major consideration in choosing where Moonbeam was going to be built. The Polkadot and Kusama Relay Chains are highly decentralized systems, and parachains should live up to the standard that they set.
The Moonbeam and Moonriver parachains will strive to maintain the same levels of decentralization when they launch to both the Polkadot and Kusama networks. While Moonbeam and Moonriver inherit some of the decentralization properties of Polkadot and Kusama, some decisions related to decentralization are the responsibility of individual parachains.
Design Tradeoffs in Favor of Decentralization
There is a lot of experimentation right now among base layer blockchains, with many projects exploring different design tradeoffs along a spectrum of different degrees of decentralization.
One popular strategy in the market is to sacrifice decentralization for improved transactions throughout, by having a smaller set of validators or key nodes and putting a lot of infrastructure behind them. It’s true, systems can run really fast when you run them on centralized infrastructure like AWS. It also is much easier to build centralized infrastructure (I did this for years in a previous life). And you can significantly reduce complexity and improve time to market by centralizing certain elements.
Tempting as this approach is, it is extremely difficult to retrofit decentralization into a project after the fact. It needs to be designed into the system from the start.
Some instances in which we favored decentralization when designing Moonbeam and Moonriver include:
- Deployment on Kusama and Polkadot in the first place, and continuing to build upon the decentralized approach taken by these networks.
- Launching as a parachain rather than a standalone chain. This helped us bootstrap directly into a decentralized security service provided by the Relay Chain. This enables us to have 900 validators currently finalizing blocks for Moonriver, just weeks after launch.
- Adoption of a fully onchain governance process from the start for all changes to the protocol, including upgrades.
- Implementation of a custom parachain-staking pallet to enable an open and decentralized set of collators to produce blocks on the network rather than relying on a small set of permissioned collators producing blocks.
- Engaging a broad range of stakeholders as initial token holders in the network.
These choices should provide a solid foundation for further decentralization of Moonbeam and Moonriver, which will happen over time, post-launch. We are working hard at increasing the number of teams and users that are engaged on the networks. At the same time, we expect the Moonbeam Foundation to play a smaller role over time as tokens continue to be distributed to stakeholders via grants and other programs.
Practical Implications for Decentralization
While there are many philosophical reasons for preferring decentralized systems over centralized ones, there are also practical reasons to consider.
I’ve heard the observation lately that “users don’t care about decentralization.” This may be true for some users in the current environment. For these users, decentralization is often seen as a theoretical thing you are supposed to want, but the networks and protocols that have less of it seem to work fine, and in some cases are more performant.
My belief is that the points of centralization that are acceptable or passable today will be tomorrow’s points of weakness and places where networks may (and probably will) be threatened and attacked. This includes centralized protocol infrastructure components, such as the reliance on a small number of node operators. But this also extends to supporting infrastructure like centralized RPC endpoint service providers and perhaps even all the way to wallet providers at the edges of the network.
As Web3 platforms and applications continue to grow in usage, value, and importance, incumbents will be increasingly threatened, and will likely resort to increasingly aggressive tactics to shut down or hamper adoption of these platforms.
In this context, the censorship resistance of Web3 platforms will become paramount. Only platforms that are actually decentralized will be able to adequately withstand these threats. I think we will see less decentralized platforms struggle to survive in the future, potentially more hostile environment.
Building with Substrate provides a great decentralized foundation for Moonbeam and Moonriver. The recently-announced Substrate Connect is a great example of new decentralization features that come to us via advances in the underlying Substrate development framework. Substrate Connect provides the ability to run a network light client directly in the browser, removing the need for centralized RPC services such as Infura. This feature is made possible by the fact that light client support was built into Substrate from the start and also that Substrate is compatible with WASM, which is natively supported in today’s browsers. With Substrate Connect, it will be extremely difficult to prevent users from accessing Substrate-based networks like Moonbeam and Moonriver.
Moonbeam’s Role in the Web3 Story
Moonbeam and Moonriver are developer-oriented infrastructure platforms. These platforms provide open and permissionless infrastructure for builders of Web3-based applications to express themselves and to solve problems in novel ways using Web3 technologies.
While the platforms provide infrastructure, it’s all the developers that are creating novel protocols and deploying to Moonbeam and Moonriver that are actually pushing Web3 forward and onboarding new users to Web3. Moonbeam has an active community and grants program for teams building decentralized applications. The founding team’s goal is to do everything we can to support these developers in their efforts.
If you would like to learn more about Moonbeam and even develop and deploy a Web3 application, please visit the docs site and the Moonbeam Discord.
