# Polkadot Parachain Omni-Node: Gathering Ideas and Feedback **URL:** \ **Category:** Ecosystem\ **Tags:** node\ **Created:** [May 10, 2024, 2:52pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823 "2024-05-10T14:52:49Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [May 10, 2024, 2:52pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/1 "2024-05-10T14:52:49Z")
This is an extension to [Stabilizing Polkadot - #15 by OliverTY](https://forum.polkadot.network/t/stabilizing-polkadot/7175/15), specifically the ideas around **Omni-Node**. ## Problem? The idea of the omni-node stems from the fact that for many builders, maintaining the node-side software is mere overhead with little benefit. If a team doesn’t want to customize the node components and simply follow the _defaults_, maintaining the node is not all that useful. This is why we have heavily relied so far on “templates” in our ecosystem, as this node boilerplate had to be handed over to developers in some way. But, even with proper _perfect_ semver-aware releases, and _perfect_ templates, there are still issues with maintaining a node: 1. Figuring out the right version to update to. > For this purpose, @OliverTY has suggested an [umbrella crate](https://forum.polkadot.network/t/stabilizing-polkadot/7175), and in the meantime [psvm](https://github.com/paritytech/psvm) is a great tool to help builders. 1. Figuring out the right changes that need to be applied. > For example, to enable PoV reclaim or async-backing, both of which are important features that we expect all parachain teams need to incorporate, some degree of change was needed in the node-side code. This usually includes a parachain developer to look into a correct example such as the `polkadot-parachain-bin` crate maintained by parity to run system parachain collators, and copy-paste the changes. Lastly, as `polkadot-sdk` is still working toward removing the native runtime from the node, it only makes sense to have more `omni-nodes` rather than custom nodes. ## Solution The “omni-node” idea consists of two steps to solve this: **Goal-0** : Provide a single binary that can sync all parachains _so long as they adhere to some standards_. We can foresee a few ways to run this omni-node, in the order of complexity respectively: ```auto ./omni-node --chain parachain.json -- --chain relay.json # Maybe possible: get the runtime and genesis state from relay-chain, or elsewhere ./omni-node --para-id 2345 ``` > As noted below, the `polkadot-parachain` binary is already almost exactly what we want here. In general, there is no limit to how much further we can bloat this binary. By bloating, I mean adding more features to it, such that a broader group of teams can use it without needing to compile anything. Some ideas here are: 1. EVM/Frontier/Contract support 2. Further consensus types 3. Custom RPCs 4. Ability to be both a solochain and a parachain 5. Custom host functions All of this will come at some cost, in that the code of the omni-node will become bigger and bigger, and harder and harder to maintain. **Goal-1** : A `node-builder` crate to allow compilation of custom nodes with smaller code footprint. Through building Goal-0, we can possibly clean up the interfaces needed to build the node side into a more reasonable level, such that we can foresee the following as the effort needed to run a node: ```auto use polkadot_sdk_node::Builder as NodeBuider; // A standard example fn main() -> sc_cli::Result<()> { let node = NodeBuilder::default() .node_type(builder::NodeType::Parachain) .authoring(builder::Authoring::Aura) .finality(builder::Finality::None) .extra_rpc(frame_system::Rpc) .extra_rpc(frame_transaction_payment_rpc::Rpc) .build() .unwrap(); node.run(); } // An ethereum enabled parachain fn main() -> sc_cli::Result<()> { let node = NodeBuilder::default() .node_type(builder::NodeType::Parachain) .frontier() // sets all the right configs .build() .unwrap(); node.run(); } // a PoW solochain node. fn main() -> sc_cli::Result<()> { let node = NodeBuilder::default() .node_type(builder::NodeType::Solochain) .finality(builder::Finality::None) .authoring(builder::Authoring::PoW) .build() .unwrap(); node.run(); } ``` This would mean that the aforementioned omni-nodes are merely pre-compiled instance of what the `polkadot-sdk-node-builder` crate already provides. A team would then have the option to use one of the pre-compiled versions, or compile their own node using the builder crate. Personal opinion: As stated here, I think building the `node-builder` is the right approach, as it forces us to repay some of the technical debt and structure the service/node side code into a cleaner software artifact. ## Existing `polkadot-parachain` The good news here is that the existing `polkadot-parachain` binary maintained in `polkadot-sdk` is already to a high extent decoupled from the system parachain runtimes and is therefore is an `omni-node-beta`. This node will by default spin up an aura-based parachain node, and is therefore well capable of syncing and hypothetically collating on any parachain that has a similar assumption. The general usage pattern that I have tried is as follows: ```auto ./polkadot-parachain --chain ./specs/parachain.json -- --chain ./specs/relay.json --sync warp ``` ## Questions 1. What are some examples of parachain teams needing to customize the node side, which I may have missed so far? What I know so far, as mentioned above: - Runtime types, such as `AccountId`, `Hash`, or even `Block` type. In cases such as a frontier-enabled parachain, these types might differ. - EVM compatible parachains. - Using different consensus. For example, many system chains start with the “no-consensus” code, and graduate to “aura”. I know some teams use Nimbus from moonbeam. - Custom RPCs. Custom RPCs are something that we consider by now “bad practice” (in favor of using custom runtime-api + `state_call`), as @xlc also pointed out another alternative [here](https://forum.polkadot.network/t/stabilizing-polkadot/7175/3). - Custom host functions - Custom Database (EVM Database) What else? 1. What are your common development/DevOps scenarios where you would have to maintain a node now, but ideally you want to get rid of it? For example, it would be great if developing a parachain, especially in the world of agile-coretime, can be entirely done using `chain-spec-builder` + a runtime/`.wasm` file. ## Next - make the minimum changes to `polkadot-parachain` such that it can run many parachains, publish it and encourage teams to use it for feedback. - Based on the feedback and need, remove more assumptions from it and make it more flexible/comprehensive, as per [`parachain-omni-node` binary by kianenigma · Pull Request #3597 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/pull/3597) ## Related Resources - [Vision for cleaner substrate-node's developer-facing interface · Issue #5 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/issues/5) - [Fix `polkadot-parachain` to work just with chain-spec · Issue #3944 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/issues/3944) - [`parachain-omni-node` binary by kianenigma · Pull Request #3597 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/pull/3597) - [Polkadot-SDK Umbrella Crate by ggwpez · Pull Request #3935 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/pull/3935) - [release chain-spec-builder · Issue #4352 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/issues/4352) ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [May 10, 2024, 2:54pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/2 "2024-05-10T14:54:33Z")
I have created 3 short videos where I explain this forum post, and showcase some examples: https://www.loom.com/embed/e3029713ae9b42ffa9692545a515cdc7?sid=851bb789-717c-4bfa-8ba3-466449653ad8 https://www.loom.com/embed/514013f57e214709a02598be54692240?sid=3f245ac4-2e18-487f-8c69-7b5fd0eadcb2 https://www.loom.com/embed/f7632e1793a04d6b89f149d1e1267f46?sid=dec4916a-9a98-44ad-8d3f-26cc64dead07 ---
**Author:** ![olanod](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/olanod/32/804_2.png) [@olanod](https://forum.polkadot.network/u/olanod)\ **Post date:** [May 10, 2024, 4:46pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/3 "2024-05-10T16:46:54Z")
I like the idea of a well abstracted node builder, a similar concept that was a nice experience was a custom reverse proxy I had to make with Cloudflare’s [pingora](https://github.com/cloudflare/pingora/), a few lines of code in the `main` function was enough to have a powerful custom proxy. If the builder can do something similar where you just need a couple of lines to have a node with good defaults that would be great(extending it and adding some extra bits should still be simple). ---
**Author:** ![bader](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/bader/32/2291_2.png) [@bader](https://forum.polkadot.network/u/bader)\ **Post date:** [May 13, 2024, 6:23pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/4 "2024-05-13T18:23:37Z")
Great post - will definitely reduce friction in spinning up tasks! Pleased to say that I was able to drop-in `polkadot-parachain` as a replacement node implementation for the parachain template! My steps were as follows: 1. Compiled `polkadot-parachain` with the same version as my runtime code (v1.10.0) 2. Use my parachain-template-node to generate my chain-spec (probably the one thing I still had to use the binary for) 3. Passed in my chain spec and OG sync settings for Rococo, along with a base path, and it synced with no issues. Was able to issue an on-demand extrinsic and collate: ```bash ./target/release/polkadot-parachain --alice \ --collator \ --chain ./specs/4418.json \ --base-path /Volumes/My\ Passport/ \ --force-authoring \ -- \ --chain rococo \ --sync fast-unsafe \ --blocks-pruning 256 ``` One question - where would the generation for genesis / chain spec CLI functionality live? Could it be that this is a separate tool, or that creating a `chain_spec.rs` is part of the runtime side of development? ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [May 14, 2024, 8:36am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/5 "2024-05-14T08:36:25Z")
Thanks for trying this out Bader! You can use the chain-spec-builder independent binary to generate the chain spec from a wasm file. At the moment it is not released, but it soon will be: > > > so I can cargo install it and use it Example: > At the moment the chain spec builder can generate either default chain specs, and/or patch them with a json file. @michal is working on a new system to have “presets” of chain-specs being generated from within the runtime. This will extend the default variant and remove the need for a patch file. ---
**Author:** ![0mm-mark](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/0mm-mark/32/850_2.png) [@0mm-mark](https://forum.polkadot.network/u/0mm-mark)\ **Post date:** [May 15, 2024, 1:05am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/6 "2024-05-15T01:05:43Z")
Given this is a node that, it would appear, is going to be widely used is it possible to clarify and address where this node sits with respect to the Polkadot Patent, see here: > [@Polkadot patent scope: Crates](https://forum.polkadot.network/t/polkadot-patent-scope-crates/5426): > > Context This is not a thread to solicit objections to, or complaints about this patent. I am a supporter of patent systems in general, and the idea of software patents in particular. Of course patent systems can be improved - this is not about those issues. Question Is there any authoritative (binding) guidance on the scope of the Polkadot patent, expressed in terms of rust crates. Specifically: [Substrate crates](https://github.com/paritytech/polkadot-sdk/tree/master/substrate)[ORML crates](https://github.com/open-web3-stack/open-runtime-module-library/tree/master) I’m not sure of the correct or best way to frame the questions/issu… Specifically, at a minimum can a clear statement be made upfront in the documentation about the extent to which using such a node is infringing the patent. Given this patent is granted through to late 2038, there is some sense making head room for things that might only emerge over time. A couple of ideas: 1. Clearly state in the docs where this node sits wrt to the patent. Example: Is it possible to use the node in a configuration that is patent free? 2. If it is maybe add a `"patent"` feature now, even if it is effectively a no-op. And everything is patent free unless it is moved under that feature flag - this way Parity has to state explicitly what they consider to be covered by the patent. Or maybe you are told everything has to be moved under the `"patent"` feature flag, and running the node without the `"patent"` feature flag results in crickets/no-op. At least users would now be aware of what they are doing and don’t inadvertently violate Parity’s rights. Hopefully that is clear. At the least, this should remove ambiguity, which is where the precautionary principle tends to lead people to be more averse than might be warranted. ---
**Author:** ![crystalin](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/crystalin/32/343_2.png) [@crystalin](https://forum.polkadot.network/u/crystalin)\ **Post date:** [May 15, 2024, 6:16am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/7 "2024-05-15T06:16:47Z")
Both solutions have pros/cons but, in my opinion, having the builder which could offer different level of granularity could be a good way to solve this problem and also provide a better approach to understand/tweak a substrate node over time. The challenge with the simplified builder is that upgrading will bring undetected changes (some of them breaking components compatiblity) which might be “ok” in a dev environment but could be problematic otherwise. ---
**Author:** ![wil](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/wil/32/927_2.png) [@wil](https://forum.polkadot.network/u/wil)\ **Post date:** [May 15, 2024, 1:16pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/8 "2024-05-15T13:16:35Z")
I like the idea of separating the runtime from the node either way. Runtime versions and node versions are too closely linked in Frequency and I think a decoupled setup would have been the choice had it been easy to do when it was started. > What are some examples of parachain teams needing to customize the node side? The Frequency Parachain has done a few node level modifications: Custom RPCs: We have one or two that I am not convinced a runtime-api + state call is truly able to replace. Custom RPCs are great in a few situations, which I admit are uncommon: - The code to process the call is heavier than would be desired inside of the runtime - The processing is better when native (becoming less of a concern as performance improves) Frequency also has an off-chain indexer. It handles generating a reverse index of data that is available on chain (A → B), but often users want/need the other direction (B → A). There is no reason to store that information inside consensus of course, and while a sidecar service can perform that action, it is nice to have it packaged together. Customization ideas we’ve had that we have _not_ done (and might be bad ideas): - Altering the storage system so that some portions of the historical state are not retained by default (although keeping the root hash). - Providing additional integration with ipfs. Like as any extrinsic that takes a CID is able to check availability of that CID before continuing to post the transaction. Or able to retrieve IPFS data along with the event. With the exception of the storage idea (which might well have to be entirely inside the runtime anyway), I don’t think it invalidates having an omni-node for most use cases. Assuming no modifications to the node are operational, things like custom RPCs and such could still be available via a custom node while many/most node operators use an omni-node. ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [May 15, 2024, 5:06pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/9 "2024-05-15T17:06:36Z")
> [@crystalin](#): > > The challenge with the simplified builder is that upgrading will bring undetected changes (some of them breaking components compatiblity) which might be “ok” in a dev environment but could be problematic otherwise. Yeah, this is the problem with abstraction as usual. I would argue that teams that can afford the cost should maintain a full node software crate, and in return they will remain informed of more such changes. > [@wil](#): > > - The code to process the call is heavier than would be desired inside of the runtime > - The processing is better when native (becoming less of a concern as performance improves) Both of these are valid arguments, but you should be aware that both basically break the assumption of forkelss upgrade in some cases. in that, those RPCs that you put inside the Node/Native side will either have to be static, or else their upgrade process will be difficult as they are not part of the WASM blob. Have you considered @xlc’s suggestion as noted [here](https://forum.polkadot.network/t/stabilizing-polkadot/7175/6)? Can you point me to which of [your RPCs](https://github.dev/frequency-chain/frequency/tree/main/node) are entirely handled within the node side? > [@wil](#): > > I don’t think it invalidates having an omni-node for most use cases. Assuming no modifications to the node are operational, things like custom RPCs and such could still be available via a custom node while many/most node operators use an omni-node. Indeed, I find your examples interesting use-cases, but it is arguably fair to expect teams that want to do some extensive customization to use a full node template code base, so all of that would be outside the scope of the omni-node. ---
**Author:** ![wil](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/wil/32/927_2.png) [@wil](https://forum.polkadot.network/u/wil)\ **Post date:** [May 15, 2024, 5:47pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/10 "2024-05-15T17:47:15Z")
> [@kianenigma](#): > > Have you considered @xlc’s suggestion as noted [here](https://forum.polkadot.network/t/stabilizing-polkadot/7175/6)? We’ve been moving many things in that direction. We’re working on a group of job specific sidecars which mostly follows that same pattern: [GitHub - ProjectLibertyLabs/gateway: Gateway microservices for DSNP/Frequency](https://github.com/AmplicaLabs/gateway/) > [@kianenigma](#): > > Can you point me to which of [your RPCs](https://github.dev/frequency-chain/frequency/tree/main/node) are entirely handled within the node side? - `get_messages_by_schema_id`does a lot off-chain: [frequency/pallets/messages/src/rpc/src/lib.rs at 857169df34dfed2acc3ab833289b70d2d43a539d · frequency-chain/frequency · GitHub](https://github.com/frequency-chain/frequency/blob/857169df34dfed2acc3ab833289b70d2d43a539d/pallets/messages/src/rpc/src/lib.rs#L77) - `check_schema_validity` is entirely off-chain, but it is a convenience method [frequency/pallets/schemas/src/rpc/src/lib.rs at 857169df34dfed2acc3ab833289b70d2d43a539d · frequency-chain/frequency · GitHub](https://github.com/frequency-chain/frequency/blob/857169df34dfed2acc3ab833289b70d2d43a539d/pallets/schemas/src/rpc/src/lib.rs#L84) The `get_messages_by_schema_id` is the one that is the most confusing for the blockchain side of things as Frequency stores messages in state instead of at the block level (even though the data is block-centric) so that you don’t need to run an archive node to be able to access that set of data. (I have the goal of removing that data from archive nodes as well as you might have guessed from the idea list). If needed, all of those could be moved into sidecars and such. Most of the cases resolve around the question of how can we make it easier to use the chain. Once you get outside of JavaScript, it is not easy to integrate. JS based sidecars solve some of that issue, but leave a lot to be desired for performance. ---
**Author:** ![mustermeiszer](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/mustermeiszer/32/73_2.png) [@mustermeiszer](https://forum.polkadot.network/u/mustermeiszer)\ **Post date:** [May 21, 2024, 7:32am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/11 "2024-05-21T07:32:15Z")
First of all, I think that is a great development into the right direction! Will make it much easier for externals to integrate parachains into their stack. > [@kianenigma](#): > > - EVM/Frontier/Contract support > - EVM Database For us, if this is supported, we are happy. The only thing I could think of was custom inherents, but then our validators just need to run our custom node instead of the omni-node. Which I think is a reasonable compromise. ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [May 31, 2024, 6:10am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/12 "2024-05-31T06:10:50Z")
> [@mustermeiszer](#): > > For us, if this is supported, we are happy. The only thing I could think of was custom inherents, but then our validators just need to run our custom node instead of the omni-node. Which I think is a reasonable compromise. I was informed by the need for custom inherent through @seunlanlege as well, and I will look into it. I believe it should be easy enough to inject custom inherents in the builder pattern as well. The end goal ofc is to allow both syncing and authoring nodes on most networks. ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [June 4, 2024, 1:33pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/13 "2024-06-04T13:33:43Z")
Something that is needed for the _omni-node-driven future_ but I am having a hard time finding is a good up to date index of all parachains and their chain-specs. I have found [Home](https://paritytech.github.io/polkadot_network_directory) / [GitHub - polkadot-ui/polkadot\_network\_directory: Documentation about Chains of the Polkadot and Kusama networks](https://github.com/polkadot-ui/polkadot_network_directory) so far coming closest, but neither seem to be exactly what we need here. ---
**Author:** ![0mm-mark](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/0mm-mark/32/850_2.png) [@0mm-mark](https://forum.polkadot.network/u/0mm-mark)\ **Post date:** [June 5, 2024, 1:14am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/14 "2024-06-05T01:14:21Z")
Is this partially what you are looking for? It has the chains but not the specs, although maybe you can add logic to arrive at a way to find the specs? > ---
**Author:** ![ntn\_x2](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ntn_x2/32/167_2.png) [@ntn\_x2](https://forum.polkadot.network/u/ntn_x2)\ **Post date:** [June 11, 2024, 8:24am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/15 "2024-06-11T08:24:34Z")
Question for support: how is the `polkadot-parachain` binary supposed to be used? Running a basic command like `cargo run -p polkadot-parachain-bin -- --chain ` results in the following message: `No specific runtime was recognized for ChainSpec's id: 'peregrine-kilt-paseo', so Runtime::default() will be used`. I see there’s an open issue about this: [Fix `polkadot-parachain` to work just with chain-spec · Issue #3944 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/issues/3944). I can’t believe this does not work with a custom parachain chainspec, so I am sure I’m doing something wrong. Or is the binary still supposed to work only with well-known runtimes, and this omninode will work with all runtimes? Cc @kianenigma ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [June 11, 2024, 3:35pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/16 "2024-06-11T15:35:54Z")
The main pattern is as follows: ```auto ./polkadot-parachain --chain para.spec -- --chain relay.spec ``` > Or is the binary still supposed to work only with well-known runtimes, and this omninode will work with all runtimes? The issue you linked above has a bit of a misleading title, the `polkadot-parachain` can already be used. @bader’s example above already demonstrates one example of this, or if you see my recordings above, I am using the same binary. We are working in renaming `polkadot-parachain` to `omni-node` and slightly better general support and documentation around this in an upcoming `polkadot-sdk` release. ---
**Author:** ![michal](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/michal/32/1733_2.png) [@michal](https://forum.polkadot.network/u/michal)\ **Post date:** [June 11, 2024, 7:31pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/17 "2024-06-11T19:31:56Z")
> [@kianenigma](#): > > At the moment the chain spec builder can generate either default chain specs, and/or patch them with a json file. @michal is working on a new system to have “presets” of chain-specs being generated from within the runtime. This will extend the default variant and remove the need for a patch file. I’ve added [some documentation](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/chain_spec_genesis/index.html) about _presets_, _chain spec_ and _genesis config_. There is a working minimal example on how to add presets and how to interact with `chain-spec-builder`. ---
**Author:** ![ntn\_x2](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ntn_x2/32/167_2.png) [@ntn\_x2](https://forum.polkadot.network/u/ntn_x2)\ **Post date:** [June 12, 2024, 12:06pm UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/18 "2024-06-12T12:06:18Z")
Ops, my bad, did not go over all your videos before posting. I understand that the log message can be ignored and a generic aura-based consensus system will be used, that is good to know. Nevertheless, when running either v1.1.0 or v1.12.0, we can see that the parachain node has 0 peers. All works fine if we use, for example, Kusama AssetHub’s chainspec. It also works fine if from the same machine we run our own binary. It does not work with the `polkadot-parachain` binary and our own chainspecs. The chainspecs are [here](https://github.com/KILTprotocol/kilt-node/tree/develop/chainspecs/peregrine). We use Aura-based consensus with some staking on top, but it should not be relevant. First few lines of logs: ```auto 2024-06-12 12:05:35.405 INFO main sc_cli::runner: Polkadot parachain 2024-06-12 12:05:35.405 INFO main sc_cli::runner: ✌️ version 1.12.0-b4016902ac7 2024-06-12 12:05:35.405 INFO main sc_cli::runner: ❤️ by Parity Technologies , 2017-2024 2024-06-12 12:05:35.405 INFO main sc_cli::runner: 📋 Chain specification: KILT Peregrine 2024-06-12 12:05:35.405 INFO main sc_cli::runner: 🏷 Node name: macho-wool-6150 2024-06-12 12:05:35.405 INFO main sc_cli::runner: 👤 Role: FULL 2024-06-12 12:05:35.405 INFO main sc_cli::runner: 💾 Database: RocksDb at /parity/.local/share/polkadot-parachain/chains/peregrine_kilt_paseo/db/full 2024-06-12 12:05:36.572 INFO main polkadot_parachain::command: Parachain id: Id(2086) 2024-06-12 12:05:36.572 INFO main polkadot_parachain::command: Parachain Account: 5Ec4AhNtskxrg56TpEJ8zweU5h4JVUmGgxDqnoE1grqycu6q 2024-06-12 12:05:36.572 INFO main polkadot_parachain::command: Is collating: no 2024-06-12 12:05:36.572 WARN main polkadot_parachain::command: No specific runtime was recognized for ChainSpec's id: 'peregrine-kilt-paseo', so Runtime::default() will be used 2024-06-12 12:05:37.187 INFO main sc_service::client::client: [Parachain] 🔨 Initializing Genesis block/state (state: 0x3ff7…c422, header-hash: 0xa0c6…cc21) 2024-06-12 12:05:37.853 INFO main sc_service::client::client: [Relaychain] 🔨 Initializing Genesis block/state (state: 0x2b2a…6ab6, header-hash: 0x77af…764f) 2024-06-12 12:05:37.854 INFO main grandpa: [Relaychain] 👴 Loading GRANDPA authority set from genesis on what appears to be first startup. 2024-06-12 12:05:37.854 INFO main babe: [Relaychain] 👶 Creating empty BABE epoch changes on what appears to be first startup. 2024-06-12 12:05:37.854 INFO main sub-libp2p: [Relaychain] 🏷 Local node identity is: 12D3KooWAcpxyXM1bQHigtsWxSeUPy8TARoSmvWheiFmTLo5GjkJ 2024-06-12 12:05:37.854 INFO main sub-libp2p: [Relaychain] Running libp2p network backend 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 Operating system: linux 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 CPU architecture: x86_64 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 Target environment: gnu 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 CPU: 12th Gen Intel(R) Core(TM) i9-12900K 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 CPU cores: 16 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 Memory: 128614MB 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 Kernel: 5.15.0-102-generic 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 Linux distribution: Ubuntu 22.04.4 LTS 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 💻 Virtual machine: no 2024-06-12 12:05:37.877 INFO main sc_service::builder: [Relaychain] 📦 Highest known block at #0 2024-06-12 12:05:37.877 INFO tokio-runtime-worker substrate_prometheus_endpoint: [Relaychain] 〽️ Prometheus exporter started at 127.0.0.1:9616 2024-06-12 12:05:37.877 INFO main sc_rpc_server: [Relaychain] Running JSON-RPC server: addr=127.0.0.1:9945, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 🏁 CPU score: 1.55 GiBs 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 🏁 Memory score: 15.46 GiBs 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 🏁 Disk score (seq. writes): 1.43 GiBs 2024-06-12 12:05:37.877 INFO main sc_sysinfo: [Relaychain] 🏁 Disk score (rand. writes): 681.35 MiBs 2024-06-12 12:05:37.878 INFO main sub-libp2p: [Parachain] 🏷 Local node identity is: 12D3KooWLyJUaXEKXw9wFRgcuGseEGwZSmXf68opYhh4fjYLwux9 2024-06-12 12:05:37.878 INFO main sub-libp2p: [Parachain] Running libp2p network backend 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 Operating system: linux 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 CPU architecture: x86_64 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 Target environment: gnu 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 CPU: 12th Gen Intel(R) Core(TM) i9-12900K 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 CPU cores: 16 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 Memory: 128614MB 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 Kernel: 5.15.0-102-generic 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 Linux distribution: Ubuntu 22.04.4 LTS 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 💻 Virtual machine: no 2024-06-12 12:05:37.937 INFO main sc_service::builder: [Parachain] 📦 Highest known block at #0 2024-06-12 12:05:37.937 INFO main sc_rpc_server: [Parachain] Running JSON-RPC server: addr=127.0.0.1:9944, allowed origins=["http://localhost:*", "http://127.0.0.1:*", "https://localhost:*", "https://127.0.0.1:*", "https://polkadot.js.org"] 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 🏁 CPU score: 1.55 GiBs 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 🏁 Memory score: 15.46 GiBs 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 🏁 Disk score (seq. writes): 1.43 GiBs 2024-06-12 12:05:37.937 INFO main sc_sysinfo: [Parachain] 🏁 Disk score (rand. writes): 681.35 MiBs 2024-06-12 12:05:37.937 INFO tokio-runtime-worker substrate_prometheus_endpoint: [Parachain] 〽️ Prometheus exporter started at 127.0.0.1:9615 2024-06-12 12:05:37.938 INFO tokio-runtime-worker libp2p_mdns::behaviour: [Relaychain] discovered: 12D3KooWLyJUaXEKXw9wFRgcuGseEGwZSmXf68opYhh4fjYLwux9 /ip4/172.17.0.2/tcp/30333/ws 2024-06-12 12:05:37.938 INFO tokio-runtime-worker libp2p_mdns::behaviour: [Parachain] discovered: 12D3KooWAcpxyXM1bQHigtsWxSeUPy8TARoSmvWheiFmTLo5GjkJ /ip4/172.17.0.2/tcp/30334/ws 2024-06-12 12:05:38.535 INFO tokio-runtime-worker sub-libp2p: [Relaychain] 🔍 Discovered new external address for our node: /ip4/78.46.69.208/tcp/30334/ws/p2p/12D3KooWAcpxyXM1bQHigtsWxSeUPy8TARoSmvWheiFmTLo5GjkJ 2024-06-12 12:05:42.937 INFO tokio-runtime-worker substrate: [Parachain] 💤 Idle (0 peers), best: #0 (0xa0c6…cc21), finalized #0 (0xa0c6…cc21), ⬇ 4.0kiB/s ⬆ 1.8kiB/s 2024-06-12 12:05:43.161 INFO tokio-runtime-worker substrate: [Relaychain] ⏩ Warping, Downloading target block, 3.68 Mib (8 peers), best: #0 (0x77af…764f), finalized #0 (0x77af…764f), ⬇ 922.6kiB/s ⬆ 61.9kiB/s 2024-06-12 12:05:43.474 INFO tokio-runtime-worker sync: [Relaychain] Warp sync is complete, continuing with state sync. 2024-06-12 12:05:46.513 WARN tokio-runtime-worker libp2p_identify::handler: [Relaychain] New inbound identify request from 12D3KooWSEfsFGA8GpkY978cUYCToRTWsJjHNNc427xYDGVc3U9X while a previous one is still pending. Queueing the new one. 2024-06-12 12:05:47.475 INFO tokio-runtime-worker sync: [Relaychain] State sync is complete, continuing with block sync. 2024-06-12 12:05:47.794 INFO tokio-runtime-worker substrate: [Relaychain] 🏆 Imported #1622294 (0xcb53…6c9d → 0x41bc…6101) 2024-06-12 12:05:47.795 WARN tokio-runtime-worker parachain::prospective-parachains: [Relaychain] Failed to fetch info for hash returned from ancestry. relay_hash=0x5373687b2f017fb6f907994d8c6edba4ecca3ea1db7ecc2143d81838e8e43d42 2024-06-12 12:05:47.799 INFO tokio-runtime-worker substrate: [Relaychain] 🏆 Imported #1622295 (0x41bc…6101 → 0x16de…63c8) 2024-06-12 12:05:47.804 INFO tokio-runtime-worker substrate: [Relaychain] 🏆 Imported #1622296 (0x16de…63c8 → 0x1fbe…90a7) 2024-06-12 12:05:47.809 INFO tokio-runtime-worker substrate: [Relaychain] 🏆 Imported #1622297 (0x1fbe…90a7 → 0x0e23…5411) 2024-06-12 12:05:47.937 INFO tokio-runtime-worker substrate: [Parachain] 💤 Idle (0 peers), best: #0 (0xa0c6…cc21), finalized #0 (0xa0c6…cc21), ⬇ 1.9kiB/s ⬆ 0.9kiB/s 2024-06-12 12:05:48.162 INFO tokio-runtime-worker substrate: [Relaychain] ⏩ Block history, #768 (9 peers), best: #1622297 (0x0e23…5411), finalized #1622295 (0x16de…63c8), ⬇ 8.9MiB/s ⬆ 17.7kiB/s 2024-06-12 12:05:48.190 INFO tokio-runtime-worker substrate: [Relaychain] 🏆 Imported #1622298 (0x0e23…5411 → 0x0e03…983d) ``` ---
**Author:** ![pierre.besson](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/pierre.besson/32/644_2.png) [@pierre.besson](https://forum.polkadot.network/u/pierre.besson)\ **Post date:** [June 13, 2024, 9:44am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/19 "2024-06-13T09:44:51Z")
> [@kianenigma](#): > > Something that is needed for the _omni-node-driven future_ but I am having a hard time finding is a good up to date index of all parachains and their chain-specs. For those looking for a up-to-date collection of the current Polkadot/Kusama chainspecs, we have published a collection at [Chainspecs Collections | chainspecs](https://paritytech.github.io/chainspecs/) The way we maintain the chainspec files up-to-date with is by having each parachain’s upstream repo as submodule of [paritytech/chainspecs](https://github.com/paritytech/chainspecs) and using a symlink to where they have commited their chainspecs. We are also generating automatic weekly PR updates with dependabot. ---
**Author:** ![serban](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/serban/32/661_2.png) [@serban](https://forum.polkadot.network/u/serban)\ **Post date:** [June 13, 2024, 11:18am UTC](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823/20 "2024-06-13T11:18:32Z")
@ntn_x2 we looked into the issue. There are more details here: [Investigate `peregrine` syncing issue when using the `polkadot-parachain` binary · Issue #4787 · paritytech/polkadot-sdk · GitHub](https://github.com/paritytech/polkadot-sdk/issues/4787) The problem is that `Peregrine` uses `BlockNumber = u64`, while `polkadot-parachain` is hard-coded to use `u32` for the moment. Probably we’ll need to think of a way of allowing custom params such as `BlockNumber`. [Next page](https://forum.polkadot.network/t/polkadot-parachain-omni-node-gathering-ideas-and-feedback/7823.md?page=2)