Add option to start omni node as a block importer only for peers with manual seal

[iulianbarbu]

Context

While discussing docs/templates in relation to https://github.com/paritytech/polkadot-sdk/pull/5954 we came across minimal-template and how it makes sense to be started in multi-node setup. We thought that minimal template makes most sense in a single-node chain, but it can be started as multiple nodes in a few scenarios:

• exercising solochains startup recipes with zombienet to observe how forks happen with an insufficient consensus logic in teaching context
• simply starting minimal node with a single block author node and multiple node importers, which makes most sense for a local testnet of minimal (although not practically useful in any way, other than observing how the networking component imports blocks from the sole block producer in the case of the node which only import).
• adding functionality incrementally over a basic example, while working towards better consensus and additional business logic that needs to be tested in multi-node setup (useful for educators or for parachain/solochain development almost from scratch).

This issue can be closed if the above scenarios are not very appealing in the long run.

Additional info

minimal-template-node provides similar functionality by passing it a --consensus none flag.

[bkchr]

Blockchains are deterministic by nature. This means whatever you do in the runtime, every node will need to do the same. This also means that you don't need multiple nodes when testing your runtime stuff locally, especially if you are using manual seal.

Also not sure what consensus logic you are talking about there. In my time working on this project, I haven't seen that many people writing their own consensus logic. Clearly nothing we need to optimize for.

[iulianbarbu]

Also not sure what consensus logic you are talking about there. In my time working on this project, I haven't seen that many people writing their own consensus logic.

I meant the logic that decides which block is considered as the next block of the blockchain, by multiple nodes. I am not interested in people writing their own consensus logic, but rather show them how insufficient consensus looks like - e.g. based on nodes internal clocks. Such setup is possible if starting multiple minimal template nodes with manual seal, each producing, proposing, importing blocks at certain intervals, somewhat taking their turns in this. This can lead to forks after some time and under certain load on the system, because the block producing happens at certain intervals dictated by timers, which are not perfect, and at some point two nodes could produce blocks for the same block height, at which point they'd fork and stop being peers.

Probably alignment based on internal clock is already obvious as an insufficient solution for how things should happen in a multi-machine/multi-clock network, for which I am happy to close this issue already, but all in all, my intention with this issue was to enable omni node to do something similar to what we did here: https://github.com/paritytech/polkadot-sdk/blob/master/templates/minimal/zombienet.toml, and along the lines of this comment: https://github.com/paritytech/polkadot-sdk/pull/5954#discussion_r1819606821.

This also means that you don't need multiple nodes when testing your runtime stuff locally, especially if you are using manual seal.

Yes. Testing runtime stuff would be orthogonal to multi-node setups, and re: this issue, I thought mainly about showcasing networking and forking (easily) for teaching purposes.

Clearly nothing we need to optimize for.

Agreed. Out of curiosity, @kianenigma what's your take on using omni-node + minimal runtime as a teaching resource for PBA (and not only) for networking and forks showcasing in a very simple local network, similar to this: https://github.com/paritytech/polkadot-sdk/blob/master/templates/minimal/zombienet.toml?

[bkchr]

Such setup is possible if starting multiple minimal template nodes with manual seal, each producing, proposing, importing blocks at certain intervals, somewhat taking their turns in this. This can lead to forks after some time and under certain load on the system, because the block producing happens at certain intervals dictated by timers, which are not perfect, and at some point two nodes could produce blocks for the same block height, at which point they'd fork and stop being peers.

Manual seal was not build for having multi node setups. It is a mode for a local node for testing. Generally I would say that with chopsticks this kind of testing is obsolete any way. Chopsticks enables you to test your runtime much easier and a node that only produces blocks when you tell it is maybe nice, but not sure what it helps you. I mean yes, I will accept the "teaching argument" for manual seal and even if you use it there with these other nodes, okay.