-
Notifications
You must be signed in to change notification settings - Fork 704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix polkadot-parachain
to work just with chain-spec
#3944
Comments
Some hints from: https://github.com/paritytech/polkadot-sdk/pull/3961/files#r1549575119
|
also we should remove testnet runtimes from dependencies, the more testnet runtimes we add to polkadot-sdk, the bigger the Maybe very easy fix would be to add testnet runtimes behind features. |
I agree totally with this. I think that ideally we would keep polkadot-parachain-bin very light, with no chainspec bytes or runtime dependencies (by removing the local configs completely). This would mean that chain specs are passed as arguments and any other information that is needed for a specific runtime to run is passed as an argument (e.g. key type = ed25519 for asset hub polkadot). I also agree that the testnets being feature gated would be great, and separated into a I'd love to remove the RuntimeApi dependencies, and actually wonder whether we need the benchmarking in this tool as well. "Do one thing and do it well" |
I think benchmarking can go away with omni-bencher |
Aligned with #3597 as well. This crate can end up being a Once the revamp of chain-spec by @michalkucharczyk is done, we are one step closer to being able to remove all the runtime related things from this crate. |
#2714 should definitely help with removing runtime deps. With work done there the entire initial genesis config can be queried from the runtime (for different flavors, e.g. -dev, -local), so we should be able to get rid of all runtime deps. Theoretically it should be possible to run the node with just runtime blob and preset name. However there are still two open questions:
|
And there is also another question, Note: I don't know what are exact differences, but Now this is switched/decided by
If we want to
So you would be able to run whatever chain-spec/runtime with whatever aura setup, e.g.:
or maybe easily just with runtime wasm:
I think this is pretty easy and independent change to |
This could be provided by runtime-side. We could provide new runtime API to provide some node-side config, or parse runtime metadata, or maybe there is another approach. It was already briefly discussed here and there... The goal would be to minimize the knowledge required to run the node. Ideally just provide the runtime blob, and that's all. |
IIRC The |
Some draft idea on how to move genesis config presets into the runtime: #3996 (Hopefully the last thing that keeps dep to |
I think something like the type of the aura/consensus, among other parameters, should be exposed as configurations to a builder pattern crate that lets you easily build a node software with fewer lines of code, as per #5 CLI flag would also do, but we already have a million of them. Moreover, let's not forget that part of the goal here is to also reduce the footprint of the code in |
afaiu the builder pattern is orthogonal to what we do with omni-node, right? What I mean is that it allows to reduce the LOC in omni-node, but will not solve a problem how to handle different consensus (or other chain-specific configuration options). We would still need to provide some means of execution time customization. |
Your comment is generally right, but through prototyping, I have come to the conclusion that building a The builder pattern would force us to think in a structured way about all thing that need to be parameterized in the node side. These parameters could be exposed as a combination of either builder functions, or CLI arguments. The final I'd say that the ideal course of action is to build the |
As a potential followup. The ideal user story is: I want to spawn a full node for any Polkadot parachain by simply running
This could be achieved by:
As a side it has been raised, that it would be nice if omninode were suitable for benchmarks as well. Having a separate binary as discussed above is likely a descent solution too though. TL;DR: Ideally the relay chain would be self sufficient to launch nodes for any parachain |
This is the only suitable solution for this and nothing else of what you listed there. With this information the node can warp sync. |
The listed bullet points are not options, but overall requirements needed for this feature (from my understanding). The only two that are actually missing to my knowledge:
|
You don't need to fetch the chain spec, if you have the bootnodes on chain. Or what do you mean by this? |
I wonder if this patter of using it seems like quite an inefficiency to indefinitely maintain this duality of "aura or relay consensus" just for the sake of the initial blocks of a parachain's lifecycle. |
Also others have done this. However, we also don't do this anymore.
What is inefficient? You also still need this to be able to sync. |
I was told we need it, I have not yet checked myself. If just boot nodes suffice - even better 🥳 So the only actual missing ingredient for doing omninode --paraid paraid is actually having bootnodes on the DHT? Nice! |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/1 |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/15 |
@bkontur this can be closed now? |
Gensis config presets moved from `polkadot-parachain` binary into `asset-hub-rococo` runtime. relates to: #3944 --------- Co-authored-by: Dónal Murray <donal.murray@parity.io> Co-authored-by: Bastian Köcher <git@kchr.de>
TBD
Runtime::default()
https://github.com/paritytech/polkadot-sdk/blob/master/cumulus/polkadot-parachain/src/command.rs#L90-L133, e.g.coretime-kusama
causes problem...enum Runtime
polkadot-parachain-bin
and createchain-spec-generator
for testnets?Relates to: #1984
Relates to: #2714
The text was updated successfully, but these errors were encountered: