[docs] Create documentation for multinode clusters

[zivkovicmilos]

Description

This issue concerns creating official documentation on spinning up multinode clusters that cover:

• how to generate / fetch genesis.json
• how to generate / manage node secrets
• how to generate / manage node config files
• how to spin up a completely new network
• how to connect to an existing network

[Kouteki]

Blocked by #1821

[adr-sk]

As part of Onbloc's multi-node testnet initiative effort, we have tested the newly added gnoland config and gnoland secrets commands to start and connect to a multi-node Gno Chain. Sharing our feedback and suggestions here based on our experience to help improve the Validator management flow: docs

Test Environment:

• Branch: master
• Last Commit: aab9f4
• Validator Node Specs
  • EC2: 2 CPU, 4GB RAM // 1st Validator
  • EC2: 2 CPU, 2GB RAM // 2nd Validator

Stress Test

Performed with the 2nd Validator (2 CPU, 2GB RAM) using Supernova

// Under normal circumstances ( CPU % / RAM GB) 7% / 0.5 GB

// 300 realm call transactions +7% / +0.02 GB

// 300 realm deployment transactions +15% / +0.06 GB

Feedback from our Tests

1. There needs to be a way to get the node-id from the CLI level. https://github.com/gnolang/gno/issues/1922
2. The unconditional_peer_ids is missing from the config.toml. This is an essential option that is required for setting up the Sentry Architecture to achieve higher security of the Validator Node. https://github.com/gnolang/gno/issues/1923
   • https://forum.cosmos.network/t/sentry-node-architecture-overview/454
   • https://docs.tendermint.com/v0.34/tendermint-core/validators.html
3. Missing support for pruning. (All nodes are archive nodes for now. Might need to analyze the long-term disk usage.)

With the Gno team's feedback, we’d like to test it further to streamline the multi-node setup experience and help complete the documentation efforts, similar to our past Gnoland Developer Portal initiative.

Please let us know what you think about our suggestions. @zivkovicmilos

(cc @r3v4s @dongwon8247)

[zivkovicmilos]

@adr-sk @r3v4s @dongwon8247

Thank you for the feedback on this initial setup, and for opening up the issues 🙏

I'm trying to figure out what the best approach for #1922 is, since for the node's node_id, you need a wombo combo of the derived address from the secret (required secret), as well as the listen address of the node (configuration, not required). I'm not sure if it should slap on the default node ID if no configuration is present, and read from the actual configuration if it is.

What would be the CLI API or showing this, given how gnoland secrets work?

[r3v4s]

Hey @zivkovicmilos, for form of node_id@ip:port, can we just combine these 2 command output?

• gnoland secrets get NodeKey
• gnoland config get p2p.laddr

[zivkovicmilos]

Hey @zivkovicmilos, for form of node_id@ip:port, can we just combine these 2 command output?

• gnoland secrets get NodeKey
• gnoland config get p2p.laddr

Yes, you are absolutely correct, I'm just not sure what the command chain would be to call this functionality. I'd prefer to keep gnoland secrets, and gnoland config with the current API, and figure out another solution for this UX feature, maybe another command suite that just combines other commands, ex gnoland meta

What do you think?

cc @gfanton @ajnavarro @thehowl

[r3v4s]

@zivkovicmilos How about gnoland validator or gnoland node?

I think gnoland meta should provide something like gnoland meta version(daemon or binary version)

[r3v4s]

// UPDATE

Missing support for pruning. (All nodes are archive nodes for now. Might need to analyze the long-term disk usage.)

Sorry for wrong info. Currently when we start gnoland chain it doesn't archive but prune everything.