Skip to content
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

polkadot-parachain: add manual seal support #5586

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

serban300
Copy link
Contributor

Resolves #5026

This PR adds support for starting a dev node with manual seal consensus. This can be done by using the --manual-seal argument and it will work only with dev chains (chain id ends with -dev) . For example:

polkadot-parachain --chain asset-hub-rococo-dev --manual-seal --tmp

@serban300 serban300 added R0-silent Changes should not be mentioned in any release notes T0-node This PR/Issue is related to the topic “node”. labels Sep 4, 2024
@serban300 serban300 self-assigned this Sep 4, 2024
@serban300 serban300 force-pushed the polkadot-parachain-manual-seal branch from d283731 to bc89536 Compare September 4, 2024 11:37
@@ -215,7 +212,24 @@ pub fn run<CliConfig: crate::cli::CliConfig>(cmd_config: RunConfig) -> Result<()
RelayChainCli::<CliConfig>::new(runner.config(), cli.relay_chain_args.iter());
let collator_options = cli.run.collator_options();

let is_dev_chain = runner.config().chain_spec.id().ends_with("-dev");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a bit unsure as to why this limitation should exist. So this will only work if the chain-spec's id ends with -dev. Why should this limitation exist?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will investigate and get back with the details, but the general problem is that I'm getting errors at block production when trying to use a non-dev runtime (for example: asset-hub-polkadot).

Copy link
Contributor Author

@serban300 serban300 Sep 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that for live chains we use predefined json configs (https://github.com/paritytech/polkadot-sdk/tree/master/cumulus/polkadot-parachain/chain-specs) and I think that most of them are outdated. I tried to update the code for the asset hub rococo and asset hub westend configs (chain-spec-builder update-code) and after that polkadot-parachain --chain asset-hub-rococo --dev-block-time 5000 worked for example. But polkadot-parachain --chain asset-hub-rococo stopped working, because of errors like Bootnode with peer id `12D3KooWG4YUe7AfSxVwyLQBRRMU99krssmGAUghqUFoVY1iPkQs` is on a different chain (our genesis: 0xf52a…f62e theirs: 0x67f9…98c9).

Anyway, if the chain spec is generated correctly, manual seal should work. So I removed this if and I can open a different issue for updating the predefined chain specs. Or we can leave them as they are.

///
/// This works only with dev chains (e.g. asset-hub-rococo-dev).
#[arg(long)]
pub manual_seal: bool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The raw manual seal also requires you to submit some kind of an RPC to author a block. What I have done in the past, I think this is a good improvement to it, is to run an RPC client internally that pings the manual seal server and produces blocks every x ms.

This is then how I re-formulated this CLI argument as --dev-block-time 100, which produces a block every 100ms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Done.

Copy link
Contributor

@skunert skunert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did not look at the manual_seal.rs code itself yet, will make one more pass.


pub trait NodeBlock:
BlockT<Extrinsic = OpaqueExtrinsic, Header = Self::BoundedHeader, Hash = DbHash>
+ for<'de> serde::Deserialize<'de>
+ UnwindSafe
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that these bounds where just moved, but why exactly do we need them in the first place?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need it because of this:

// All this `UnwindSafe` magic below here is required for this rust bug:

@@ -0,0 +1,152 @@
// Copyright (C) Parity Technologies (UK) Ltd.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need the shell node? I think we can just remove it. In the past it was used to transition from this placeholder shell runtime to system-chains. I think no one does it anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I don't know. I would be happy to remove it, but I'm not familiar with it and I don't know if it's still used by anyone. @kianenigma WDYT ?

use manual_seal::ManualSealNode;
use sc_service::{Configuration, TaskManager};

pub trait DynNodeSpecExt: DynNodeSpec {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This trait should be more clearly named, it is specifically tailored to enable this manual seal functionality. So maybe DevNodeExt or something? Just a suggestion, maybe someone has another idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also thought of something like DevNodeExt, but I think it can lead to misunderstandings. For example I would be tempted to understand that it's only something related to dev nodes. But it also contains the logic related to production nodes. Because of this, I would prefer to leave it as DynNodeSpecExt. But if you have strong preferences I can change it.

.ok_or("Could not find parachain extension in chain-spec.")?,
);

if let Some(dev_block_time) = cli.dev_block_time {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did not check this in-depth, but could we not mingle the dev_block_time into extra args and make the new_node_spec above have something like Consensus::Manual. I am wondering if we can get rid of the "special handling" of start_manual_seal and just treat it as a consensus variant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can treat the manual seal just like another consensus variant. Because the process of starting the node is a bit different (the relay_chain_interface is not built), and the arguments passed to start_consensus are also different. Mixing this in the NodeSpec feels a bit dirty.

That's why I just added a new type of node with a new start_manual_seal_node() fn that differs from start_node(). We could probably make it more generic and name it SoloChainNode instead of ManualSealNode, if it makes any difference, but I would keep it separate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R0-silent Changes should not be mentioned in any release notes T0-node This PR/Issue is related to the topic “node”.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Omni-node: add support for starting a dev chain with manual seal
3 participants