GavinWood proposes to minimize the relay chain

The Relay Chain is the core part of the Polkadot network, which contains the main logic of the network. It is necessary for the relay chain to assume these core logic before the parachain can start running and XCM can be developed. But with the development of time, now these core logic can be considered to be migrated to the system parachain! As a result, Dr. Gavin Wood and Joe Petrowski of the Web3 Foundation initiated RFC-32, proposing to migrate the logic of multiple subsystems from the relay chain to the “system parachain” that together form the entire Polkadot network.

So, why decompose part of the logic of the relay chain into system parachains? Which features are broken down first? Check out the important information compiled by PolkaWorld below!

Why do you want to do this? **

The Polkadot network is designed to scale and allow multiple independent state machines (i.e., parachains) to work under a common security and validity guarantee. To achieve this guarantee, the Relay Chain has a collection of validators who are primarily responsible for the security of the Relay Chain. However, not all validators deal directly with state transitions for parachains. Each state transition of the parachain is handled by a subset of validators, called a backing group. This means that not all validators deal directly with every state transition of the parachain, only a subset of them is responsible for handling state transitions.

But when state transitions occur on the relay chain, all validators need to be involved in the execution to ensure the consistency and security of the network. However, a side effect of this design is a performance bottleneck, as each state change requires network-wide validation, which increases latency and limits throughput.

But if the state transition of the relay chain can be done on the parachain, then this will free up some resources. This means that the portion of validator resources that would otherwise be used for relay chain state transitions can be repurposed, providing the network with more core time, i.e. more block space.

In general, there are several main reasons to migrate part of the logic of the relay chain to the system parachain:

1. Performance and Scalability: By migrating certain logic and responsibilities onto a system parachain, the Relay Chain can focus on its core responsibilities, improving the performance and scalability of the overall network.
2. Resource optimization: When part of the logic is migrated to the system parachain, the relay chain can free up more resources for other tasks, such as processing cross-chain messaging or providing security for more parachains.
3. Modularity and Flexibility: Modular design makes it easier to modify, upgrade, or add new features without interfering with the main operation of the Relay Chain. This provides greater flexibility for future innovation and feature expansion.
4. Security: Separating parts of the logic from the relay chain reduces the risk of a single point of failure. On a separate system parachain, if a parachain is attacked or fails, it is unlikely to affect the relay chain or other parachains.
5. More parachain opportunities: By freeing up the resources of the relay chain, the Polkadot network can support more parachain joining, further expanding its ecosystem.
6. Optimization of specific features: As Polkadot evolves, some features or logic may require specialized optimizations or specialized processing methods. Moving these functions to specialized system parachains ensures that they are optimally processed and optimized.

**Which functions will be broken down into system parachains? **

The following modules and subsystems are possible options for migrating out of the trunk chain:

1.Identity

2. Balances

3. Staking (Staking)

Strike

Election Provider

Bags List

NIS

Nomination Pools

Fast Unstake

4. Governance

Treasury and Bounties

Conviction Voting

Referendum

Note: The current auction and crowdlending modules will no longer be used, but will be replaced by a new system called Coretime. Details about Coretime’s system chain and its interfaces are described in RFC-1 and RFC-5, respectively. Polkadot Fellowship is also developing Coretime parachains. For more Polkadot progress, please see Polkadot Q3 Progress: 5 New Parachains Launched, USDC Enters the Ecosystem, Stake, Segregated Accounts and On-Chain Events Grow Significantly.

How do I migrate? **

Some subsystems can be migrated from the relay chain to other locations relatively simply. Using Authentication as an example, you can simply block state changes on the relay chain and set the initial state for the new chain using the state associated with authentication. This initial state and associated logic, or modules, are then used to start a new chain.

However, there are subsystems that cannot have any downtime during the migration process because they are critical to the proper functioning of the entire network, such as staking and governance. Even so, these critical subsystems may co-exist with other chains of systems with similar permissions for some time. Just as “Gov1” and “OpenGov” coexisted when the latter was introduced.