Open ntn-x2 opened 6 days ago
Hi @ntn-x2, thanks for your feedback. Does the custom chain-spec is in plain
mode? if not we can't customize it to spawn the new network. Also, you can use the chain-spec-generator to get a plain
version of polkadot local.
With the plain version should work as expected, please ping me if not and we can touch base and debug.
Thx!
Hi. Yes, our chain spec is a preset of our binary (generated when using --chain spiritnet-dev
), and it's a plain one. I did generate one for polkadot, which I attach here. This can be obtained using the command I list in the network config file above.
polkadot-1.3.2-plain.json
This is the chainspec generated by using the spiritnet-dev
chain preset.
Hi @ntn-x2, thanks for the info. Did you get any error? Or just the parachain doesn't produce blocks? If this is the case, does the relaychain is compiled with fast-runtime
? Can you check the session time and if the parachain is onboarded?
Thanks!!
@pepoviola I get no error whatsoever on either side. I also noticed parachain collators are not even attempting to author blocks, which is what made me think it could be something related to the nature of the Polkadot runtime. I get the same error with a kusama-local
relaychain. And I am using the official Docker image from parity, so I don't think that's compiled with fast-runtime
. As for the chainspec, I generate it from the release branch and specify no additional features, so that should also be ok.
Hi @ntn-x2, can you share with me the repo so I can try it? I think if you get the chain-spec (for polkadot-local) with the generator with fast-runtime
should work without any issue.
Thx!
Hey. I did not generate the chainspec with the fast-runtime
feature. Now I did, and I get something about the genesis preset not being found.
Here's the PR: https://github.com/KILTprotocol/kilt-node/pull/714. cd
into the zombienet
folder, run yarn
and then yarn spawn:spiritnet:with-env
, and you should get to the same point I am at. If you replace the chainspec with the one build without the fast-runtime
feature, then you get to the point where the chain is not authoring any blocks.
I tried it with the pre-release of the paseo relaychain, 1.3.1, and I am in the same situation. Could it be due to the fact that the peregrine-dev chain ID sets the relaychain extension part of the chainspec to rococo_local
? https://github.com/KILTprotocol/kilt-node/blob/d9552b70160465eaedd7263db450aa70f49667df/nodes/parachain/src/chain_spec/utils.rs#L55. I am under the assumption this would be overridden by Zombienet.
EDIT: Using spiritnet-new
, which uses simply "relay"
for the relaychain name seems to work with a rococo-local
chain. So my guess is that taking a pre-generated relaychain chainspec that is not hard-coded into the polkadot binary seems to be the issue.
EDIT 2: My assumption above was wrong. Using westend-local
for relaychain and either peregrine-dev
, spiritnet-dev
or spiritnet-new
for parachain also has the same result of the parachain not producing any blocks, with not weird errors in the logs. So it seems only rococo-local
is working.
Issue Description
I am trying to use the
polkadot-local
relay spec to set up a ZN network. Nevertheless, the parachain never gets to produce any blocks, and no errors is generated in the logs. I am not sure if this is howpolkadot-local
is supposed (not) to work, or if I am missing some additional configurations.Steps to reproduce the issue
Use the following basic network setup config:
the following
.env
file:and the following command:
env $(cat runtimes/spiritnet/.env | xargs) yarn zombienet --spawn-concurrency=3 spawn runtimes/spiritnet/network.yaml
Describe the results you received
The parachain does not produce nor attempts to author any blocks.
Describe the results you expected
Either an error or actually blocks being produced.
Zombienet version
1.3.109
Provider
Kubernetes
Provider version
Upstream Latest Release
Yes
Additional environment details
See snippets above.
Additional information
It works if a replace the custom chainspec with
rococo-local
.Screenshots
No response