Yes that is right.
To generate the genesis block we are currently leveraging the native runtime. It holds the GenesisConfig
that can decode the json chain specs for example or is the one that is used in the code like in your example. The problem is now that the native runtime evolves together with the on chain runtime, because both are sharing the same code. This would then lead to a genesis block with a potential different storage root. Even with the same native runtime, it would be required that WASM_BINARY
is the same for everyone, but that isn't the case.
To solve this, we have the raw chain spec. The raw chain spec is basically the genesis database, aka it contains all the key => value
pairs that you will find on each node as genesis state. Putting these values into the trie, will give you the storage root of the genesis block. This way we are not dependent on the native runtime to generate the genesis block. It is always advised, especially for Parachains, to first generate the raw chain spec. Parachain builders then can use the chain spec to extract the genesis wasm binary and to get the genesis state of their Parachain. If they don't do it that way, they probably will have different data registered on the relay chain than the Parachain nodes are using. This will then lead to collators being unable to build PoV candidates, because they can not find the required block in their local database. The error they will see is:
Could not find the header of the genesis block in the database!
TLDR: If you want to launch a chain, production or for testing (with multiple nodes), use a raw chain spec!