[Feature]: Split Runtime and Node

[wilwade]

Feature Description

Details

It is now possible to separate out the repositories for the node vs the runtime code of the chain.

Goal

To have a clean separation between the node and the runtime

A/C (Repo Split Version)

(Note names are WIP)

• Two repos, both with the history up to now
• frequency-chain/runtimes (or should this still be the frequency repo?): Contains the Mainnet and Testnet runtimes
  • Produces wasm and runtime related artifacts only
• frequency-chain/node: Contains the custom node code for frequency
  • Produces the Docker images and node binaries

Open Questions

• How do we handle local development runtime builds? aka what does make start do in what repo?
• Do we need to separate repos or just one repo with separate folders?
• Testing e2e setup goes in which repo or both?
• Where does api-augment live?

Related

• Polkadot Runtimes: https://github.com/polkadot-fellows/runtimes/
• Paseo Runtimes: https://github.com/paseo-network/runtimes/

Searched for Related Issues

• [X] I have done a search for related issues and either found none, or noted them

[wilwade]

Notes from the 2024-07-18 Community Call

• Where does code that is common between the runtime and the node go?
  • Argument for mono-repo
  • Any additional interactions between these?
  • How much can we just get rid of the overlap? A lot of common isn't used on both sides
• Following the pattern of the larger community
  • Argument for at least doing it, and maybe separate repos
• What is our current list of custom node features?
  • TODO: @wilwade to add a list
  • Reverse index of MSAs to Keys
  • Custom RPCs (Some Custom RPCs can move to Runtime APIs. Make sure to note which ones could move to Runtime APIs easily/hard/etc...)
    • Nonce
  • Note that there has been some talk of more custom options with Omni-Node

Polled Consensus:

• Is separating out the node from the runtime a good idea?
  • Strong YES
• One repo or two?
  • Start with one, consider moving to two later separately