Proposal for Common Good Parachains

Just over one year ago, Statemine became fully operational on Kusama, allowing anyone to create fungible and non-fungible asset classes. Since then, Statemine has opened five bi-directional HRMP (aka XCMP-Lite) channels with other parachains and had two assets deemed “sufficient” by the Kusama stakeholders. Its cousin Statemint has become a parachain on Polkadot, and several applications, block explorers, development tools, and custodians have added support for assets on both networks.

Although as a live network, Statemint is the most visible, the team at Parity has been working to prepare for the launch of several more chains it plans to propose as common good parachains. On the technical side, this work has involved making runtime changes that allow more expressive interaction over XCM and developing testing and release processes that scale to several runtimes.

The community has also provided valuable feedback on XCM uses, the general role of common good parachains (especially when it comes to adding new functionality), and the most desired new features. This feedback has shaped a lot of our internal roadmap for the coming six months.

Collectives

The team at Parity has been busy testing a new parachain for collectives and plans to make a governance proposal to connect it to Polkadot. For those who pay close attention to testnets, you may have already noticed a new parachain on Westend since late July, and that is where some of the final testing is happening.

The name “collectives” may not evoke much meaning, but Polkadot and Kusama already have collectives, each operating with a Council and Technical Committee. Although these particular collectives will retire with the proposed next generation of Polkadot governance, the ability to organize and act as a group (without needing to trust third parties like lawyers and jurisdictional courts) remains an important element of Web3.

The new proposal for Polkadot governance introduces a new collective, the Fellowship, which allows a ranked group of experts to express its opinion on sensitive or highly privileged proposals. This collective succeeds the Technical Committee, but with much broader membership to represent more of the technical contributors to the Polkadot protocol. Rather than fast tracking referendum voting and enactment schedules, the Fellowship expresses its opinion that certain proposals are safe and of technical importance to the advancement or functioning of the network. Although the Fellowship and its logic will incubate on Kusama, it should eventually migrate to Polkadot and serve both networks via stakeholder-approved referenda.

Another collective in development is the Polkadot Alliance. The Alliance is already deployed on the Westend test parachain and will likely be the first one on Polkadot. Several community teams banded together about two years ago and came up with the idea for the Alliance, primarily to fight misuse of the Polkadot brand and unattributed code. If approved by the network, the Alliance would be an on-chain industry collective that sets a code of ethics regarding brand use, scam activities, and harmful behavior, but also provides recognition to teams who do make positive contributions to the growth and success of the Polkadot network.

Although the Alliance would exist on-chain, and publish its findings of unscrupulous websites and accounts on-chain, it will not have any governance powers. You can think of it like an airline alliance (e.g. Star Alliance), where members could have an Alliance badge on their website or product UIs that give users more confidence that certain standards of quality will be upheld. Likewise, wallets could warn users when connecting to websites or interacting with accounts that the Alliance has flagged.

The collectives parachain will connect only to Polkadot; there are no plans for a Kusama counterpart. In fact, for some collectives, like the Alliance, the Kusama network could actually join the collective as a member. That is, networks themselves can act as collectives and express their legislative voices as single opinions within other networks.

How this works in practice leads to the next parachain in the works: a bridge hub.

Bridge Hub

Polkadot always included plans for bridges to other networks, like Ethereum. And plans for a bridge between Polkadot and Kusama predate the launch of Kusama itself. As highlighted by recent exploits, building secure bridge primitives is a considerable undertaking. But the engineering team at Parity (in close collaboration with Snowfork and the researchers at Web3 Foundation) have made enough progress to begin testing for the launch process.

Before Kusama and Polkadot supported their first parachains, the only way to design a bridge was to put the bridge logic into the Relay Chain itself. But with both networks supporting parachains, it makes sense to have a parachain on each network dedicated to bridges. Because of the execution isolation provided by parachains, the activity on a parachain does not affect the Relay Chain or other parachains. So a bridge hub can support bridges to many other consensus systems. The team has been working on adding a runtime to Cumulus, and has been prototyping bridge parachains on local testnets with plans to move to Rococo (bridged to its sinister sounding cousin, Wococo).

A bridge hub would of course be a hub, and support more bridges than just one between Polkadot and Kusama. Parity is also working with Snowfork on an Ethereum bridge to launch on the same hub. But this does not exclude other bridges from existence; teams who have built a bridge that does not fit under the common goods umbrella can still operate as parachains and offer their bridge services to the network.

Bridges require an understanding of finality of their interlocutor complemented with a message format and delivery service. The more technically minded readers may be familiar with the GRANDPA Finality and BEEFY systems, used to verify finality on GRANDPA and Ethereum based chains, respectively. These modules are being reviewed by auditors and tested on the prototyping networks.

The second half, a message format and delivery service, comes from XCM v3 and Polkadot’s suite of transport protocols (UMP, DMP, HRMP/XCMP-Lite, and eventually XCMP). XCM v2 already allows for secure communication between parachains, but does not contain all of the messaging primitives that bridges need to interact with other consensus systems. XCM v3 is under review and bridges will be ready for action once XCM v3 is in production.

In practice, a bridge between Polkadot and Kusama will allow collectives like the Alliance and Fellowship to serve both networks, and even for Kusama to act as a unified voice and participant within those collectives or the Polkadot network as a whole.

Assets

Finally, let us not forget the first common good parachain, Statemint, which has a rich roadmap in its own right. At the launch of Statemint, the team kept the runtime intentionally lean, eschewing features like smart contracts that, according to the architectural principles behind Polkadot, should exist on other chains and interact with assets via XCM. This decision was frustrating to many developers who wanted to express more complex interactions. But the advancement of XCM is making these possible now.

Statemint’s two core pallets are dedicated to fungible assets and NFTs. After much feedback from the community about usability and desired features (e.g. asset locking and reserving, nested and multi-resource NFTs), several people from Parity, RMRK, Phala, KILT, and others are working on the next generation of these pallets to deliver these features.

Building on XCM v3 and the newer assets features, Statemint will also begin taking more “core system” level work from the Relay Chain, especially for the on-chain Treasury and balances.

It has been a long-standing idea within the Polkadot network for the on-chain Treasury to hold many assets, in addition to its native token. One, users making Treasury proposals may want to request funding in other assets besides DOT. In addition, the Polkadot stakeholder community as a whole may want Polkadot to acquire stakes in other assets. By providing the multi-asset support that Statemint specializes in, it can allow more options for Treasury use and management.

Statemint will eventually take on more balances functionality too. With staking and governance both on the Relay Chain, they can each interact synchronously with the DOT/KSM balances on the Relay Chain. That is, they can each get a “real-time” thumbs up that an account has sufficient lockable balance to stake, vote, etc. But as these subsystems move to parachains, they can only interact asynchronously. A user’s balance cannot exist at the same time on a governance parachain and a staking parachain, so those systems need a common place to reference balances.

To solve this, Statemint and XCM v3 support locking over XCM. In this model, a user may want to both vote and stake with 100 DOT, and the governance and staking chains would each request that Statemint lock the DOT and send an affirmation that the balance has been locked for each purpose. Then the governance and staking chains can issue the user the correct voting and staking rights, using the same locked DOT.

Community

The community has been a driving force in developing these plans. The roadmap that I originally had in mind for common good parachains has been rendered obsolete by many conversations with community members over the winter and spring. And that is a good thing.

Parachains have a diverse set of users: from end-users to application developers to other parachain developers. Feedback from all these groups has influenced our roadmap, and quite often external contributors submit PRs for the features that they want.

As the common good parachain team at Parity grows, we would love to see more community involvement from all types of users. The roadmap I’ve laid out in this article is a gargantuan endeavor. Common good parachains are meant to be an extension of the Relay Chain itself, part of the Polkadot core protocol. Like the rest of the core protocol, its success requires engagement from the entire community. We encourage everyone to get involved in any way: feel free to ask questions on Stack Exchange or open issues in the Cumulus repository.

Interested in building on Polkadot? Get in touch here.