diff --git a/text/0032-minimal-relay.md b/text/0032-minimal-relay.md new file mode 100644 index 000000000..1903f0740 --- /dev/null +++ b/text/0032-minimal-relay.md @@ -0,0 +1,264 @@ +# RFC-0032: Minimal Relay + +| | | +| --------------- | ----------------------------------------------------------------------------- | +| **Start Date** | 20 September 2023 | +| **Description** | Proposal to minimise Relay Chain functionality. | +| **Authors** | Joe Petrowski, Gavin Wood | + +## Summary + +The Relay Chain contains most of the core logic for the Polkadot network. While this was necessary +prior to the launch of parachains and development of XCM, most of this logic can exist in +parachains. This is a proposal to migrate several subsystems into system parachains. + +## Motivation + +Polkadot's scaling approach allows many distinct state machines (known generally as parachains) to +operate with common guarantees about the validity and security of their state transitions. Polkadot +provides these common guarantees by executing the state transitions on a strict subset (a backing +group) of the Relay Chain's validator set. + +However, state transitions on the Relay Chain need to be executed by _all_ validators. If any of +those state transitions can occur on parachains, then the resources of the complement of a single +backing group could be used to offer more cores. As in, they could be offering more coretime (a.k.a. +blockspace) to the network. + +By minimising state transition logic on the Relay Chain by migrating it into "system chains" -- a +set of parachains that, with the Relay Chain, make up the Polkadot protocol -- the Polkadot +Ubiquitous Computer can maximise its primary offering: secure blockspace. + +## Stakeholders + +- Parachains that interact with affected logic on the Relay Chain; +- Core protocol and XCM format developers; +- Tooling, block explorer, and UI developers. + +## Explanation + +The following pallets and subsystems are good candidates to migrate from the Relay Chain: + +- Identity +- Balances +- Staking + - Staking + - Election Provider + - Bags List + - NIS + - Nomination Pools + - Fast Unstake +- Governance + - Treasury and Bounties + - Conviction Voting + - Referenda + +Note: The Auctions and Crowdloan pallets will be replaced by Coretime, its system chain and +interface described in RFC-1 and RFC-5, respectively. + +### Migrations + +Some subsystems are simpler to move than others. For example, migrating Identity can be done by +simply preventing state changes in the Relay Chain, using the Identity-related state as the genesis +for a new chain, and launching that new chain with the genesis and logic (pallet) needed. + +Other subsystems cannot experience any downtime like this because they are essential to the +network's functioning, like Staking and Governance. However, these can likely coexist with a +similarly-permissioned system chain for some time, much like how "Gov1" and "OpenGov" coexisted at +the latter's introduction. + +Specific migration plans will be included in release notes of runtimes from the Polkadot Fellowship +when beginning the work of migrating a particular subsystem. + +### Interfaces + +The Relay Chain, in many cases, will still need to interact with these subsystems, especially +Staking and Governance. These subsystems will require making some APIs available either via +dispatchable calls accessible to XCM `Transact` or possibly XCM `Instruction`s in future versions. + +For example, Staking provides a pallet-API to register points (e.g. for block production) and +offences (e.g. equivocation). With Staking in a system chain, that chain would need to allow the +Relay Chain to update validator points periodically so that it can correctly calculate rewards. + +A pub-sub protocol may also lend itself to these types of interactions. + +### Functional Architecture + +This RFC proposes that system chains form individual components within the system's architecture and +that these components are chosen as functional groups. This approach allows synchronous +composibility where it is most valuable, but isolates logic in such a way that provides flexibility +for optimal resource allocation (see [Resource Allocation](#resource-allocation)). For the +subsystems discussed in this RFC, namely Identity, Governance, and Staking, this would mean: + +- People Chain, for identity and personhood logic, providing functionality related to the attributes + of single actors; +- Governance Chain, for governance and system collectives, providing functionality for pluralities + to express their voices within the system; +- Staking Chain, for Polkadot's staking system, including elections, nominations, reward + distribution, slashing, and non-interactive staking; and +- Asset Hub, for fungible and non-fungible assets, including DOT. + +The Collectives chain and Asset Hub already exist, so implementation of this RFC would mean two new +chains (People and Staking), with Governance moving to the _currently-known-as_ Collectives chain +and Asset Hub being increasingly used for DOT over the Relay Chain. + +Note that one functional group will likely include many pallets, as we do not know how pallet +configurations and interfaces will evolve over time. + +### Resource Allocation + +The system should minimise wasted blockspace. These three (and other) subsystems may not each +consistently require a dedicated core. However, core scheduling is far more agile than functional +grouping. While migrating functionality from one chain to another can be a multi-month endeavour, +cores can be rescheduled almost on-the-fly. + +Migrations are also breaking changes to some use cases, for example other parachains that need to +route XCM programs to particular chains. It is thus preferable to do them a single time in migrating +off the Relay Chain, reducing the risk of needing parachain splits in the future. + +Therefore, chain boundaries should be based on functional grouping where synchronous composibility +is most valuable; and efficient resource allocation should be managed by the core scheduling +protocol. + +Many of these system chains (including Asset Hub) could often share a single core in a semi-round +robin fashion (the coretime may not be uniform). When needed, for example during NPoS elections or +slashing events, the scheduler could allocate a dedicated core to the chain in need of more +throughput. + +### Deployment + +Actual migrations should happen based on some prioritization. This RFC proposes to migrate Identity, +Staking, and Governance as the systems to work on first. A brief discussion on the factors involved +in each one: + +#### Identity + +Identity will be one of the simpler pallets to migrate into a system chain, as its logic is largely +self-contained and it does not "share" balances with other subsystems. As in, any DOT is held in +reserve as a storage deposit and cannot be simultaneously used the way locked DOT can be locked for +multiple purposes. + +Therefore, migration can take place as follows: + +1. The pallet can be put in a locked state, blocking most calls to the pallet and preventing updates + to identity info. +1. The frozen state will form the genesis of a new system parachain. +1. Functions will be added to the pallet that allow migrating the deposit to the parachain. The + parachain deposit is on the order of 1/100th of the Relay Chain's. Therefore, this will result in + freeing up Relay State as well as most of each user's reserved balance. +1. The pallet and any leftover state can be removed from the Relay Chain. + +User interfaces that render Identity information will need to source their data from the new system +parachain. + +Note: In the future, it may make sense to decommission Kusama's Identity chain and do all account +identities via Polkadot's. However, the Kusama chain will serve as a dress rehearsal for Polkadot. + +#### Staking + +Migrating the staking subsystem will likely be the most complex technical undertaking, as the +Staking system cannot stop (the system MUST always have a validator set) nor run in parallel (the +system MUST have only _one_ validator set) and the subsystem itself is made up of subsystems in the +runtime and the node. For example, if offences are reported to the Staking parachain, validator +nodes will need to submit their reports there. + +Handling balances also introduces complications. The same balance can be used for staking and +governance. Ideally, all balances stay on Asset Hub, and only report "credits" to system chains like +Staking and Governance. However, staking mutates balances by issuing new DOT on era changes and for +rewards. Allowing DOT directly on the Staking parachain would simplify staking changes. + +Given the complexity, it would be pragmatic to include the Balances pallet in the Staking parachain +in its first version. Any other systems that use overlapping locks, most notably governance, will +need to recognise DOT held on both Asset Hub and the Staking parachain. + +There is more discussion about staking in a parachain in [Moving Staking off the Relay +Chain](https://github.com/paritytech/polkadot-sdk/issues/491). + +#### Governance + +Migrating governance into a parachain will be less complicated than staking. Most of the primitives +needed for the migration already exist. The Treasury supports spending assets on remote chains and +collectives like the Polkadot Technical Fellowship already function in a parachain. That is, XCM +already provides the ability to express system origins across chains. + +Therefore, actually moving the governance logic into a parachain will be simple. It can run in +parallel with the Relay Chain's governance, which can be removed when the parachain has demonstrated +sufficient functionality. It's possible that the Relay Chain maintain a Root-level emergency track +for situations like [parachains +halting](https://forum.polkadot.network/t/stalled-parachains-on-kusama-post-mortem/3998). + +The only complication arises from the fact that both Asset Hub and the Staking parachain will have +DOT balances; therefore, the Governance chain will need to be able to credit users' voting power +based on balances from both locations. This is not expected to be difficult to handle. + +### Kusama + +Although Polkadot and Kusama both have system chains running, they have to date only been used for +introducing new features or bodies, for example fungible assets or the Technical Fellowship. There +has not yet been a migration of logic/state from the Relay Chain into a parachain. Given its more +realistic network conditions than testnets, Kusama is the best stage for rehearsal. + +In the case of identity, Polkadot's system may be sufficient for the ecosystem. Therefore, Kusama +should be used to test the migration of logic and state from Relay Chain to parachain, but these +features may be (at the will of Kusama's governance) dropped from Kusama entirely after a successful +migration on Polkadot. + +For Governance, Polkadot already has the Collectives parachain, which would become the Governance +parachain. The entire group of DOT holders is itself a collective (the legislative body), and +governance provides the means to express voice. Launching a Kusama Governance chain would be +sensible to rehearse a migration. + +The Staking subsystem is perhaps where Kusama would provide the most value in its canary capacity. +Staking is the subsystem most constrained by PoV limits. Ensuring that elections, payouts, session +changes, offences/slashes, etc. work in a parachain on Kusama -- with its larger validator set -- +will give confidence to the chain's robustness on Polkadot. + +## Drawbacks + +These subsystems will have reduced resources in cores than on the Relay Chain. Staking in particular +may require some optimizations to deal with constraints. + +## Testing, Security, and Privacy + +Standard audit/review requirements apply. More powerful multi-chain integration test tools would be +useful in developement. + +## Performance, Ergonomics, and Compatibility + +Describe the impact of the proposal on the exposed functionality of Polkadot. + +### Performance + +This is an optimization. The removal of public/user transactions on the Relay Chain ensures that its +primary resources are allocated to system performance. + +### Ergonomics + +This proposal alters very little for coretime users (e.g. parachain developers). Application +developers will need to interact with multiple chains, making ergonomic light client tools +particularly important for application development. + +For existing parachains that interact with these subsystems, they will need to configure their +runtimes to recognize the new locations in the network. + +### Compatibility + +Implementing this proposal will require some changes to pallet APIs and/or a pub-sub protocol. +Application developers will need to interact with multiple chains in the network. + +## Prior Art and References + +- [Transactionless Relay-chain](https://github.com/paritytech/polkadot/issues/323) +- [Moving Staking off the Relay Chain](https://github.com/paritytech/polkadot-sdk/issues/491) + +## Unresolved Questions + +There remain some implementation questions, like how to use balances for both Staking and +Governance. See, for example, [Moving Staking off the Relay +Chain](https://github.com/paritytech/polkadot-sdk/issues/491). + +## Future Directions and Related Material + +Ideally the Relay Chain becomes transactionless, such that not even balances are represented there. +With Staking and Governance off the Relay Chain, this is not an unreasonable next step. + +With Identity on Polkadot, Kusama may opt to drop its People Chain.