I’m starting this as a new thread, but it’s mostly a response to this question in “Substrate Ecology v0.1”:
Current communication of what is / isn’t a Common Good Parachain - is unclear. This is to expected, but the impacts of these emerging definitions has real impact, on historic development and moving forward and so a definitive effort to share the current thinking of those definitions is vital.
Starting a new thread because (a) I think it’s a topic that deserves more discussion on its own, and (b) it’s related to other discussions, like the Snowbridge funding proposal.
A Bit of History
As far as I recall, the idea of common good chains was first presented by Gav at the same time as parathreads, at DOTcon in 2019. Fast forward about 18 months, I wrote an article that roughly divided these common good chains into two buckets: system level and public utility.
In both Gav’s presentation and my article, the idea of CGPs was still mostly an idea. There were no parachains at all on Kusama or Polkadot, so we hadn’t seen how the chains would function in practice technically or in relation to the auction system of the networks.
As expected, we all learn when turning theory into practice. The two I will address here are:
-
Opinionation spectrum
-
Opinionated territoty
Opinionation Spectrum
I originally thought of chains fitting cleanly into a “system” or “public utility” bucket. However, sometimes it’s natural to group functionality that may be related into one chain, but that falls under different categories.
For example, take Statemint. The fungible assets and NFT functionality clearly falls more on the “utility” side. NFTs are just not part of the core Polkadot protocol that makes the network function. However, balances are, and Statemint supports holding and transacting in DOT (at much lower existential deposit and transaction fees than the Relay Chain). In the future, the goal is to use this chain to lock balances that would be used in staking, governance, &c. So it is difficult to put Statemint into a bucket, but we can certainly put these subsystems into buckets.
I think of this functionality being on an opinionation spectrum.
(Thanks to @shawntabrizi for a graphic that’s not drawn with colored pencils.)
Unopinionated System
On one end, one can consider “pure” unopinionated functionality. This end is quite clearly defined: There can only be one. This functionality simply must exist for Polkadot to be Polkadot. Whether these subsystems are in the Relay Chain or parachains is purely architectural. Some examples:
- Balances: There is some fixed amount of DOT in the network at any given time.
- Staking: Having multiple staking pallets distribute stake to different sets of validators defeats a primary purpose of the staking system: knowing who the validators are at a given time.
- Governance: Likewise, we don’t want multiple governance systems to access the
Rootorigin; having them would just be more avenues of access for malicious proposals. - Para Leases: Polkadot should have a single, common way to permissionlessly register a parachain and acquire a lease.
For clarity, there may be many ways to participate in or access these subsystems. For example, users can run a validator themselves, nominate directly, or create or join a pool. Likewise parachains could become a parathread, bid directly in an auction, run a crowdloan, &c. These participation/access means should not necessarily be limited to one, but the network needs canonical info for these low level systems.
Core Protocol
As we move to the right, we run into functionality that is core to the network, and therefore part of the Polkadot protocol, but where multiple implementations can actually complement each other.
- Treasury: Perhaps this should go with “unopinionated system” because the ability for governance to spend for various initiatives is singular. I think the general ability is essential to the system, but it could be split into smaller treasuries with specific mandates and spending processes (e.g. paying contributors with Fellowship evaluation vs. funding ecosystem events).
- Bridges: A fundamental assumption behind Polkadot is that many blockchains will exist in the future, and it’s a naive assumption to think they will all be in Polkadot. Just like there are Windows, Mac, Android, Linux, &c. operating systems, there will be other consensus systems. Bridges are in the Polkadot Whitepaper as a core part of the network and will be important to keep Polkadot relevant in the future. That said, it’s possible to have more than one bridge. Unlike staking, there’s nothing technically wrong with multiple bridges to other networks.
- Collectives: This one is why I call it a “spectrum” and not “buckets”. I’d consider the ability to create on-chain collectives as part of the core protocol, but there could exist many means of doing so.However, there are some collectives where only one makes sense, e.g. the Technical Fellowship. Having multiple technical fellowships distracts from their purpose of being a body of expert contributors to the core protocol. But there could be many generic DAO-creation chains.
- Crowdloans: Although Polkadot has one auction system, there can be many ways to participate in those auctions, including many ways to let individuals organize and participate in the auction as a unitary body. Polkadot does include a Crowdloan pallet, but it’s by no means the only way to implement the functionality. Polkadot could include a default implementation in a common good chain, but that doesn’t stop other implementations from popping up.
If you are thinking, “Hey, guy! There were already lots of alternative {‘liquid crowdloans’, ‘Bridges’, ‘DAOs’} on Polkadot.” Yes, hold that thought, I’m getting there.
Utility
Now we are in major opinionationland. Things like asset registration, NFT functionality, reputation systems, certifications, &c. In this area, the functionality is less about “core Polkadot protocol” and more “accessibility using the DOT token”. We might consider these non-essential to the pure ability of Polkadot to validate state transitions of its parachains, but more-or-less essential to be relevant as a foundational system in Web3.
Without going into detail on these, a few would be:
- Fungible asset registries (e.g. Statemint): Perhaps this is closer to core protocol. Again, spectrum.
- Non-fungible asset registries (also Statemint)
- Smart contracts (Perhaps also closer to core protocol)
- Reputation, identity services (e.g. Encointer)
- Certification/attestation services
- Random oracles
- Large and/or encrypted file storage
- Domain registries
This area tends to get controversial quite fast. On one hand, one of the great things about Polkadot is that end-users don’t actually have to know about Polkadot or parachains or DOT. They might use some application built on many parachains without any knowledge of the underlying consensus provider.
On the other, when application builders come into the Polkadot ecosystem, it can be an extra step to go from learning about Polkadot to then choosing a parachain to build on.
My utopic vision for the role of common good chains of this type is that they are stepping stones. “Can Polkadot do NFTs?” → “Yes! Dive right in on Statemint.” Then, once someone sees that it’s easy to get started, they might realize that one of the other “free market parachains” has NFT functionality that’s more appropriate/interesting to them, so they migrate to RMRK, BitCountry, Phala, Unique Network, Efinity, or {insert those I forgot}. To me, this means that any of these chains, if being built as a common good, must be built in close collaboration with the community and with migration paths to other chains.
We are early, and I realize we have a lot of progress to make to get to that state. But at least in my own efforts, that’s the direction in which I am trying to go.
Functionality Over Chains
All the bullet points above were subsystems, not chains. It’s expected that one chain could include a few of those subsystems from different points on the spectrum. Let’s say we make an “execution core allocation” parachain that allocates leases to parachains via auction, assigns certain execution cores for parachains, parathreads, dynamic scheduling, boost capacity, &c. It would be reasonable to include the Auctions pallet (pure system) and the Crowdloan pallet (core protocol) in the same chain. You can’t really put the entire chain into a bucket anymore.
This does not mean, however, that other crowdloan systems cannot exist. As we have seen in the auctions on Polkadot, several “liquid crowdloan” protocols came up from other teams. That’s cool, and we should encourage that. Polkadot can provide the Crowdloan pallet in a common good parachain, and others can develop more featureful crowdloans with different trust models and different rewarding, bidding, refunding, locking, &c. strategies. Parachains and contributors can choose the systems that they think give them the best chance of winning.
Opinionated Territory
So, why does one Crowdloan pallet get to be the “default” and be part of the Polkadot protocol? Similarly, why would one bridge be included in a common good chain while another not?
That is ultimately up to governance to decide. But as a common good, a feature is part of the Polkadot core protocol. As discussed, many of these features can have more than one implementation. Besides being accessible using only the token of the core protocol (DOT), features that are part of the core protocol should abide by the core principles of the network. Primarily, these would be prioritization of trust minimization and unstoppability above all else.
That means no trusted accounts (including multisigs), no sudo-privileged councils, respect of the network’s governance for privileged operations (like upgrades, choosing collectives’ membership), and acceptance of the DOT token for economic security.
Teams going the “free market” route have the additional hurdle of acquiring funding for their lease, but much more freedom in technical, social, and economic design spaces. We’ve already seen that freedom exercised in many ways on Polkadot. Parachains often launch with sudo to control their upgrade/launch process. Many of the liquid crowdloan protocols have multisigs that control contributors’ tokens. Many of the bridges deployed on parachains have multisig authorities. And of course, many parachains have their own tokens and economic incentives. These all allow those protocol developers to innovate fast, build their own communities (that may not even be interested in Polkadot), and try new things at a pace not supported by Polkadot’s governance processes.
None of that is to say that that kind of innovation isn’t valuable or welcome. It’s just a design tradeoff. To have a large design freedom, projects need to build their own community and convince investors or crowdloan participants to back them enough to win a slot. To become a common good, you need to convince the DOT stakeholders that your subsystem is safe and aligns with the entire network’s interests.
This Polkassembly comment makes my point perfectly:
Since the inception of beefy, teams have been waiting to implement the usage but have gone the centralized bridge route.
Yes, which they had every right to do. They have built communities, won parachain slots in auction, and launched those bridges, because they saw a market opportunity and their users trust them to operate a centralized bridge.
But centralized bridges are not part of the Polkadot protocol.
I think there is a misconception that teams who go the common good route have taken a shortcut and are skipping a major hurdle to get on Polkadot. In my opinion, getting a common good lease should be more difficult, because you are held to the standards of all DOT holders to deliver trust-free, mission critical core components. We have seen some teams (e.g. Interlay) start with the intention of launching as a common good later decide to compete in an auction because the common good route was too restrictive.
I also don’t mean to suggest that going the auction route is easy. It’s not, and I hope that with the development of more dynamic scheduling mechanisms like parathreads, the barrier to launch a chain on Polkadot will come down greatly.
Wrapping Up
Back to this: “Current communication of what is / isn’t a Common Good Parachain - is unclear.”
First, the only entity that can communicate this is the Polkadot network via on-chain referendum.
Polkadot is an amazing technology for scaling Web3. The act of putting core functionality into a parachain is an instance of Polkadot using its own technology, not “taking” a lease that would otherwise go to an auction. This is not a zero-sum game. Moving core functionality to parachains will actually make more parachain execution cores available.
My opinion is that anything in a common good parachain is part of the Polkadot protocol, so the primary question that DOT holders should evaluate when considering common good parachain funding and leases is: “Should this functionality be part of the Polkadot protocol?” That question may become political. But if the outcome is “yes, it is part of the Polkadot protocol”, then whether that protocol is hosted on the Relay Chain or in a parachain is an architectural, not political, decision.