Launch the network & run a collator node
Relay Chain
Either follow the tutorial "Prepare a local Relay Chain", use Zombienet to setup a local environment or connect to Rococo.
Important: we need the same chainspec that is used to start the validators for the collator(s). In case of connecting to Rococo, we need the Rococo chainspec.
Parachain
Register Parachain
If necessary, register the parachain to the Relay Chain with the parachain-genesis-state
and the parachain-wasm
files generated above. In addition, you need a parachain manager account
and the para-id
. Check out the "Connect a local Parachain" tutorial and look for the step "Register with the local Relay Chain"
Launch Collator
Before we launch a Collator for the Parachain, make sure that its database is purged from any previous attempts, as any leftover state can cause syncing issues. In other words, the genesis state of the collator won't match the genesis state that has been given to the Relay chain.
./target/release/parachain-node-template purge-chain --base-path /tmp/parachain/<collator> --chain parachain-chainspec-raw.json
Launch the collator:
./target/release/parachain-node-template --collator \
--name C1 \
--base-path /tmp/parachain/collator1 \
--chain parachain-chainspec-raw.json \
--force-authoring \
--rpc-port 10001 \
--ws-port 10002 \
--listen-addr /ip4/0.0.0.0/tcp/10003/ws \
-- \
--execution wasm \
--chain /{PATH_TO_RELAYCHAIN_CHAINSPEC} \
--port 10004 \
--ws-port 10005
Ensure the collator is peering with the relay chain (and the other collator(s) if present) by checking the collator output logs.
No peers with the Relay Chain: if you made changes to the relay chainspec, make sure
bootnodes
are provided. In addition, NAT can also be a problem.No peers with the Parachain: see Important.
No blocks being produced should be expected until the session key is added to the keystore - This is specific to a custom chain spec and would probably work if using the parachain-node-template default spec as it would probably just use alice/bob as collators.
./target/release/parachain-node-template --help
:
Important:
the
force-authoring
flag is only necessary when you have one collator (e.g. for testing).the
listen-addr
flag is necessary if you want other nodes to be able to connect to you to join the network. An additionalbootnodes
flag is necessary for this other collator (when the chainspec doesn't providebootnodes
). In addition, you need the[parachain] local identity
of the collator you want to connect to (you can find this in the logs when you start your node).
An example of launching a second collator that you want to connect to the first collator shown above:
./target/release/parachain-node-template --collator \
--name C2 \
--base-path /tmp/parachain/collator2 \
--chain parachain-chainspec-raw.json \
--force-authoring \
--rpc-port 10006 \
--ws-port 10007 \
--listen-addr /ip4/0.0.0.0/tcp/10008/ws \
--bootnodes /ip4/127.0.0.1/tcp/10003/ws/p2p/{INSERT_COLLATOR_1_PARACHAIN_NODE_IDENTITY} \
-- \
--execution wasm \
--chain /{PATH_TO_RELAYCHAIN_CHAINSPEC} \
--port 10009 \
--ws-port 10010
*The force-authoring
can still be provided for the case where you want it to build blocks if it is the only collator in the network.
Last, depending on the chain and the syncing method, the time it takes to be completely synchronized and build your first block can vary. The flag --sync=warp
enables the node to make use of the warp sync protocol. This decreases the synchronization time significantly by only validating / applying full blocks at the end of the initial synchronization process.
Session Keys
The session key needs to be set for a collator to start producing blocks. It is advised to use a different keypair than the collator keypair. This is to minimize exposure of the collator keypair.
Generating keys
There are multiple ways to generate keys, such as:
Polkadot JS extension or any other custodial
Session-pallet
Session keys are set in session-pallet. Session keys can be added to genesis state, otherwise set_keys needs to be called by the collator.
In order to change your session keys you'd have to call set_keys
with the new public key.
Keystore
In order for a collator to be able to sign e.g. its produced block, the session keypair needs to be added to the keystore
. The keystore is a file that provides a secure and encrypted storage solution for your private keys. It ensures that only authorized processes can access and use the private keys when needed.
Connect to your collator via Polkadot JS: https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A10002 (
ws-port
flag set to 10002)Go to
Developer
andRPC calls
and click author, insertKey.Enter "aura" as the keyType
Enter the seed/mnemonic of the collator's session key as suri.
Enter he hex value of the public key of the collator's session key for publicKey.
The Collator's session keys are added to the keystore and should now be building blocks.
Invulnerables & Candidates
As for cumulus' out-of-the-box implementation, the set of collators that are allowed to build blocks are coming from the pallet collator-selection
, more specifically the invulnerables
and candidates
.
If we want to add a new collator we either add it to invulnerables
through root
or we can register as a candidate.
Important: invulnerables
will always be chosen to build blocks. As for candidates
, there is a desired_amount
that caps the amount of candidates that can be registered. In other words, if a collator wants to register as candidate but the desired_amount
is met, the collator has to wait until a collator leave_intent
or the desired_amount is increased.
Last updated