[chain] Chain Creation Flow Improvement

[zivkovicmilos]

Description

This effort covers an overhaul of how new Gno chains are initialized.
Currently, to start a chain, users need 2 things:

• a genesis file that contains immutable information (independent)
• a config file, that is highly dependent on things like:
  • the genesis location
  • node key generation, and location

This is also in addition to the user being required to specify absolutely everything in the config file, otherwise the configuration is not valid (current implementation).

However, there is no way to specify any of these things in advance to creating the config, because Gno is lacking a command suite for generating and manipulating a config file.
The current flow initializes the config file automatically, along with a plethora of other things, such as validator keys.

Additionally, there is also no way to generate validator / node keys in advance, that can be used in the config / genesis files.

The optimal flow for chain creation should look something like this:

• create node key (independent)
• create genesis file
  • dependent on the node key, if the node is a validator in the initial validator set, and the key is provided upon genesis creation (as raw input)
  • otherwise, independent
• create individual configs (which are optional) for different modules
  • high level information like chain ID should be passed around as flags, while broader configs should be separate

This flow not only gives the ability to create a new network without worrying about setting everything up from the get-go. Additionally, it also enables easy orchestration, containerization and testing suite buildup (to understand how cumbersome the testing process is, take a look at how the in-memory node was implemented, and how gno dev works).

Successful outcome of this effort:

• A user can independently create a node / validator key
• A user can independently create a genesis file (this functionality is already present)
• A user can, but does not have to, specify a configuration file for each module in TM2
  • If the user does not specify a configuration file, the default configuration is loaded for the module, no questions asked
• A user can specify top-level chain info (BaseConfig) as flags when starting the Gno node

Copied over from #1593:
1️⃣ A user wants to connect to the existing gno mainnet (testnet, whatever):

• gnoland init
• gnoland start

That's it -> you don't really need to configure anything else, because our genesis.json will be publicly known and initial bootnodes hardcoded by default in the config p2p section

2️⃣ A user wants to set up their own Gno network (testnet):

• gnoland init
• gnoland genesis ... -> if they want to edit the genesis json (to add validators)
• gnoland config p2p --persistent-peers ... -> so they can set their bootnodes
• gnoland start

For the user to get these persistent-peers Node IDs, those peers would need to make their IDs public, and they can fetch them locally with:
gnoland secrets show (all, or a single secret, in this case the node key)

3️⃣ A user wants to connect to a custom Gno network (testnet):

• gnoland init
• gnoland config p2p --persistent-peers ... -> so they can connect to the custom network's bootnodes
• gnoland start

This user would reuse the genesis.json that was generated at some point for the custom gno network, and have info on the custom Gno network's persistent peers

The foundations of this flow are built with #1605 and #1593.

[r3v4s]

Question for 3️⃣

reuse the genesis.json that was generated at some point for the custom gno network

As we all know base on current rpc struct, that genesis can be found on :26657/genesis. But if files is tooooooo large timeout might happen.
(like others) can we just grab genesis file from git?

[zivkovicmilos]

Question for 3️⃣

reuse the genesis.json that was generated at some point for the custom gno network

As we all know base on current rpc struct, that genesis can be found on :26657/genesis. But if files is tooooooo large timeout might happen. (like others) can we just grab genesis file from git?

That's the plan, it should be downloadable easily

[adr-sk]

Relevant Docs Efforts: #1820 (comment)

[thehowl]

On this front, maybe we should consider moving the loading of examples/ packages that is done at chain initialization to something that is actually set up by the genesis command suite (and code utilities, so that it can be easily integrated by other tools)?

I think we want to go in the direction whereby gnoland can be started after it has its configuration/genesis dependencies set up; without relying on things like being in this repository's directory structure. And if anything, adding all the examples from examples/ should be something set up by genesis, not gnoland start.

As for standard libraries, I think we'll have to wait for #1248, so that stdlibs are embedded into Gno by default.

[zivkovicmilos]

@Kouteki
I'm closing this issue as completed since we just merged #1985 - the remaining open issues are actually not blocking, and are QoL improvements we will implement down the line