2

I'm using the Parity Tech Github as source for the Relay, with some simple modifications in the node\service\src\chain_spec.rs and cli\src\command.rs to build a personalized chain specification file.

So, I can input my seed(s) and it writes the keys and session keys in the ChainSpec.json file. After generating and transforming it to the raw format, I use the raw chain spec to add the keys into the node's keystore.

I'm using those 3 key types: gran, babe and imon.

./target/release/polkadot key insert --base-path /tmp/relay/multi1 --chain 3-raw.json --scheme ed25519 --suri "<key>" --key-type gran    
./target/release/polkadot key insert --base-path /tmp/relay/multi1 --chain 3-raw.json --scheme sr25519 --suri "<key>" --key-type babe
./target/release/polkadot key insert --base-path /tmp/relay/multi1 --chain 3-raw.json --scheme sr25519 --suri "<key>" --key-type imon

I'm not using the Dev/Testing accounts. I'm using keys generated by me.

Everything on the Relay runs without any problems. The issue appears when I deploy a Parachain. The Parachain Node is discovered, and can be seen as a FULL node on the Network>Node Info.

So, what I need to do? I have to add session keys for the parachain as well? If so, where? What I'm missing here? Why it tries over and over to start collating but nothing happens?

Output Log from the Parachain

2022-10-13 14:35:12.039  INFO tokio-runtime-worker substrate: ✨ Imported #655 (0x7f2c…0759)
2022-10-13 14:35:12.043  INFO tokio-runtime-worker cumulus-collator: Starting collation. relay_parent=0x88da0da170e12fe60447128581d6507e3faf82cdb355e3ea1d8cd7f22dc2d26e at=0x448337c11caa11ea07e126518e2c439e65b53e0ce223cf40ca040aa8d81a4800
2022-10-13 14:35:12.045  INFO tokio-runtime-worker cumulus-collator: Starting collation. relay_parent=0x7f2ccf7c492abf73210caf96e1d280d4cfdce2ff310e7ad05f1bb12515500759 at=0x448337c11caa11ea07e126518e2c439e65b53e0ce223cf40ca040aa8d81a4800
2022-10-13 14:35:12.989  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0x4483…4800), finalized #0 (0x4483…4800), ⬇ 0 ⬆ 0
2022-10-13 14:35:13.112  INFO tokio-runtime-worker substrate: 💤 Idle (2 peers), best: #655 (0x88da…d26e), finalized #652 (0xe496…e47e), ⬇ 1.2kiB/s ⬆ 0.5kiB/s
2022-10-13 14:35:17.989  INFO tokio-runtime-worker substrate: 💤 Idle (0 peers), best: #0 (0x4483…4800), finalized #0 (0x4483…4800), ⬇ 0 ⬆ 0
2022-10-13 14:35:18.015 DEBUG tokio-runtime-worker runtime::inclusion-inherent: [enter_inner] parent_header=0x88da0da170e12fe60447128581d6507e3faf82cdb355e3ea1d8cd7f22dc2d26e bitfields.len(): 0, backed_candidates.len(): 0, disputes.len(): 0
2022-10-13 14:35:18.016 TRACE tokio-runtime-worker runtime: Batch-verification: 0 pending tasks, 0 sr25519 signatures
2022-10-13 14:35:18.016 TRACE tokio-runtime-worker runtime: Finalization of batch verification took 0 ms
2022-10-13 14:35:18.016 DEBUG tokio-runtime-worker runtime::system: [656] length: 344 (normal 0%, op: 0%, mandatory 0%) / normal weight: 0 (0%) / op weight 0 (0%) / mandatory weight 6038475000 (0%)
2022-10-13 14:35:18.018  INFO tokio-runtime-worker substrate: ✨ Imported #656 (0x3c1d…70da)
2022-10-13 14:35:18.021  INFO tokio-runtime-worker cumulus-collator: Starting collation. relay_parent=0x3c1d92f510cfb8ef59bd9eaf47734109f3cba6ce51981e749cdd40de9fc670da at=0x448337c11caa11ea07e126518e2c439e65b53e0ce223cf40ca040aa8d81a4800

Some additional info:

Error that appears when I try to do a Runtime call to generate session keys on the parachain ws.

 0: sp_panic_handler::set::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:702:17
   2: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:588:13
   3: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:138:18
   4: rust_begin_unwind
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
   5: core::panicking::panic_fmt
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
   6: core::panicking::panic_display
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:72:5
   7: core::panicking::panic_str
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:56:5
   8: core::option::expect_failed
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/option.rs:1874:5
   9: <&mut dyn sp_externalities::Externalities as sp_io::crypto::Crypto>::sr25519_generate_version_1
  10: std::thread::local::LocalKey<T>::with
  11: tracing::span::Span::in_scope
  12: sp_io::crypto::sr25519_generate_version_1
  13: sp_io::crypto::ExtCryptoSr25519GenerateVersion1::call
  14: <sc_executor_wasmtime::imports::Registry as sp_wasm_interface::HostFunctionRegistry>::with_function_context
  15: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  16: <F as wasmtime::func::IntoFunc<T,(wasmtime::func::Caller<T>,A1,A2),R>>::into_func::wasm_to_host_shim
  17: <unknown>
  18: <unknown>
  19: wasmtime_runtime::traphandlers::catch_traps::call_closure
  20: wasmtime_setjmp
  21: wasmtime_runtime::traphandlers::catch_traps
  22: wasmtime::func::invoke_wasm_and_catch_traps
  23: sc_executor_wasmtime::instance_wrapper::EntryPoint::call
  24: sc_executor_wasmtime::runtime::perform_call
  25: <sc_executor_wasmtime::runtime::WasmtimeInstance as sc_executor_common::wasm_runtime::WasmInstance>::call
  26: sc_executor_common::wasm_runtime::WasmInstance::call_export
  27: std::thread::local::LocalKey<T>::with
  28: sc_executor::native_executor::WasmExecutor<H>::with_instance::{{closure}}
  29: sc_executor::wasm_runtime::RuntimeCache::with_instance
  30: <sc_executor::native_executor::NativeElseWasmExecutor<D> as sp_core::traits::CodeExecutor>::call
  31: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_aux
  32: sp_state_machine::execution::StateMachine<B,H,Exec>::execute_using_consensus_failure_handler
  33: <sc_service::client::call_executor::LocalCallExecutor<Block,B,E> as sc_client_api::call_executor::CallExecutor<Block>>::call
  34: <sc_rpc::state::state_full::FullState<BE,Block,Client> as sc_rpc::state::StateBackend<Block,Client>>::call
  35: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
  36: tokio::runtime::task::core::CoreStage<T>::poll
  37: tokio::runtime::task::harness::Harness<T,S>::poll
  38: tokio::runtime::blocking::pool::Inner::run
  39: std::sys_common::backtrace::__rust_begin_short_backtrace
  40: core::ops::function::FnOnce::call_once{{vtable.shim}}
  41: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/alloc/src/boxed.rs:1951:9
      <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/alloc/src/boxed.rs:1951:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys/unix/thread.rs:108:17
  42: start_thread
  43: clone
Thread 'tokio-runtime-worker' panicked at 'No keystore associated for the current context!', /home/amrm/.cargo/git/checkouts/substrate-7e08433d4c370a21/e8a7d16/primitives/io/src/lib.rs:846

Thanks for any hint or help in advance! x)

3
  • Hello Alexandre, maybe you are from the blockchain academy if so its me Ramsey, hello! A good tip is to rotateKeys so that al the keys in your node's keystore are added then setKeys on the chain. There are probably somekeys missing so that parachain functionality can work. Check this tutorial which has the rotateKeys workflow decentration.medium.com/… Oct 14, 2022 at 13:15
  • Aslo are you running with just one validator on the relay chain? you need at least 3 validators in order to include a parachain. Oct 14, 2022 at 13:18
  • Also in the error it says No keystore associated for the current context! try adding --alice and --bob to your collator commands, which should add the keys to the keystore of your nodes automatically. But if your chain spec of your parachain requires specific keys then you will need add those keys, to do that you need to curl insertKey with the correct methods. Or do key-insert like you did with the relay chain. Oct 14, 2022 at 13:21

1 Answer 1

2

In the error it says No keystore associated for the current context!

This means that your parachain node does not have the aura key that it needs to start collating.

Try adding --alice and --bob to your collator commands e.g. (./target/release/parachain-collator --collator --alice...`), which should add the keys to the keystore of your nodes automatically.

But if you have added specific keys to the chain spec of your parachain node then you will need add those keys, just like you did with key-insert for your relay chain.

Or you can make a curl request:

curl -vH 'Content-Type: application/json' --data '{ "jsonrpc":"2.0", "method":"author_insertKey", "params":["aura", "0x153d8db5f7ef35f18a456c049d6f6e2c723d6c18d1f9f6c9fbee880c2a171c73", "0x408f99b525d90cce76288245cb975771282c2cefa89d693b9da2cdbed6cd9152"],"id":1 }' localhost:9933

9
  • Yes, I'm using specific keys for both. In the Relay and in the Parachain. The thing is, how can I add those keys to the parachain keystore? The parachain build doesn't have the key subcommand. When I tried using the Relay binary to use it's key-insert I got a panic error. (rethinking now, it might work! ) Can I add the key subcommand in the cli.rs and commands.rs on my para node? And thanks for the help!! <3 I'll try to add it to the para's keystore. Oct 14, 2022 at 15:31
  • Yes, as I thought the error when trying to insert the keys into the parachain keystore returns me this: ./target/release/polkadot key insert --base-path /tmp/parachain/mld --chain rococo-para-2000-raw.json --scheme sr25519 --suri "<key>" --key-type aura Error: 0: Invalid input: Error parsing spec file: unknown field relay_chain at line 64 column 1 Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it. Run with RUST_BACKTRACE=full to include source snippets. Oct 14, 2022 at 16:45
  • 1
    Then you can curl it in something like this: curl -vH 'Content-Type: application/json' --data '{ "jsonrpc":"2.0", "method":"author_insertKey", "params":["aura", "0x153d8db5f7ef35f18a456c049d6f6e2c723d6c18d1f9f6c9fbee880c2a171c73", "0x408f99b525d90cce76288245cb975771282c2cefa89d693b9da2cdbed6cd9152"],"id":1 }' localhost:9933 Oct 14, 2022 at 20:51
  • Still don't working. When I'm going to check the node's keystore by ls /tmp/parachain/mycol it shows two chain options instead of just one. Can you please check if that is correct? terminal outputs Oct 15, 2022 at 0:10
  • When I tried the curl, the output I got was {"jsonrpc":"2.0","result":null,"id":1} I must be missing something on the keystore. I'm going crazy with this D: Oct 15, 2022 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.