-
Notifications
You must be signed in to change notification settings - Fork 645
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
base: master
Are you sure you want to change the base?
polkadot-parachain
: add manual seal support
#5586
Conversation
d283731
to
bc89536
Compare
bc89536
to
0c8a994
Compare
@@ -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"); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
).
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. Done.
There was a problem hiding this 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.
cumulus/polkadot-parachain/polkadot-parachain-lib/src/common/mod.rs
Outdated
Show resolved
Hide resolved
|
||
pub trait NodeBlock: | ||
BlockT<Extrinsic = OpaqueExtrinsic, Header = Self::BoundedHeader, Hash = DbHash> | ||
+ for<'de> serde::Deserialize<'de> | ||
+ UnwindSafe |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
cumulus/polkadot-parachain/polkadot-parachain-lib/src/command.rs
Outdated
Show resolved
Hide resolved
.ok_or("Could not find parachain extension in chain-spec.")?, | ||
); | ||
|
||
if let Some(dev_block_time) = cli.dev_block_time { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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: