Skip to content
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
This repository was archived by the owner on Nov 15, 2023. It is now read-only.

Support running the relay chain node as an extra process #545

@bkchr

Description

@bkchr

The Vision

Currently every parachain node includes a relay chain node. This relay chain node is required to get certain information about the relay chain that are important for the parachain, for example to query what is the best parachain block currently etc. While this makes it relative easy to run a parachain node, it also brings some problems like the high compilation time as we need to compile the parachain node and the relay chain node. Another, a more bigger problem is that parachain developers are required to update their collators when there is a new relay chain release that requires a timely update, because a new host function is added or something in the client code of the relay chain is fixed. So, it would be nice to have the relay chain node running as an extra process. Collator operators would just run an extra relay chain node (that could maybe even shared between multiple parachain nodes, but this is no real initial requirement!) and can freely update the relay chain node. The relay chain node itself could maybe directly bring the functionality required by Cumulus to connect to it or we provide some sort of wrapper (probably the best way for the first implementation).

The Plan

This feature would be implemented in the following order:

  1. Refactor all usages of the polkadot client to have them behind some common trait or maybe multiple traits. So, we should not have any reference to polkadot-service or polkadot-client in any of the "low-level" functionality of Cumulus. It should only use these interfaces to talk to the relay chain.
  2. Write an implementation of these traits for the "in-node relay chain" so that we are back to on par with the current implementation.
  3. Research what is the best way to implement the inter-process communication. Maybe some sort of json rpc over https://crates.io/crates/parity-tokio-ipc or whatever.
  4. Implement the wrapper and make it work. Running the relay chain as an external process should always be some sort of optional way of doing it. So, if the feature is compiled it should be enabled via some cli flag or something.
  5. ...
  6. Profit :P

Open Questions

If you want to help us out and contribute to this issue, in this section you can find open questions and tasks where we would appreciate any input.


Here you can find the board with specific sub-tasks to this milestone:
SDK Node (view)

Metadata

Metadata

Assignees

Labels

J0-enhancementAn additional feature request.

Type

No type

Projects

Status

done

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions