Launch the network & run a collator node
Last updated
Last updated
Either follow the tutorial , use 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 .
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 tutorial and look for the step "Register with the local Relay Chain"
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.
Launch the collator:
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 Parachain: see Important.
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 additional bootnodes flag is necessary for this other collator (when the chainspec doesn't provide bootnodes). 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:
*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.
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.
There are multiple ways to generate keys, such as:
Polkadot JS extension or any other custodial
In order to change your session keys you'd have to call set_keys with the new public key.
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.
Go to Developer and RPC 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.
No peers with the Relay Chain: if you made changes to the relay chainspec, make sure bootnodes are provided. In addition, can also be a problem.
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:
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 . This decreases the synchronization time significantly by only validating / applying full blocks at the end of the initial synchronization process.
Session keys are set in . Session keys can be added to , otherwise needs to be called by the collator.
Connect to your collator via Polkadot JS: (ws-port flag set to 10002)
As for cumulus' out-of-the-box implementation, the set of collators that are allowed to build blocks are coming from the pallet , more specifically the invulnerables and candidates.
If we want to add a new collator we either through root or we can .
Important: invulnerables will always be chosen to build blocks. As for candidates, there is a 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 or the desired_amount .