Document various testnets and their goals

[moul]

There is a need to document each network, its goal, when to use it today, when to use it in the future, and what we have in mind for the future ("coming soon").

Networks

1. testX.gno.land: These are testnets fixed in the codebase with a fixed history. They are ideal for tools that need consistent growing height and timestamps, such as indexers, oracles, and some clients. They are hard to use for development, demonstrations, etc. Mostly recommended for tool writers, rather than developers or citizens.

2. localhost (localdev): This is the node you can run locally with gnoland or gnodev. This network is ideal for local development. In practice, you can expose it to more people, and we can expect improving gnodev to make it easy to publish a blockchain to the world.

3. staging.gno.land: This is a special node that is reset regularly (every ~1h), all the history is trashed, and the latest git commit is used to create a new instance. This target is ideal for quick testing where we don’t want to pollute other chains.

4. gno.land (a.k.a., portal loop): This is something between a testnet AND staging.gno.land; it regularly resets the chain, but will replay the history of the previous calls in an eventually-consistent way.

Miro draft used to build this issue

cc @gnolang/devrels

[moul]

We should encourage people to work locally with the full setup.

Use staging for CI and make staging.

Then, use the portal loop on GNO Playground (default target?) and make publish. We should encourage a simple manual/semi-auto versioning strategies like r/manfred/v{autoincrement}/myrealm.

Testnets other than portal and staging ones should not be the initial options in dropdown menus of tools like playground and Adena. Instead, they should be grouped under an "other networks" section, where we can include networks like Berty's staging.

[leohhhn]

@moul

I've communicated with DevX to include Portal Loop as an option in the Playground. The PR has been merged and now we are awaiting a new Playground release. Soon after a few docs PRs will be unblocked.

Here is the issue I'm referring to. https://github.com/gnostudio/studio/pull/578

Will work on documenting testnet usage in more detail asap 👌🏻

[ilgooz]

Some thoughts:

• Keep subsequent testnets coming on every major release / addition and changes in the Gno.land. (always consistent, use real validators)
• Rename staging to dev or devnet, make the state persistent by writing migrations when data structure is changed. Redeploy the devnet every month, appoint a release manager for it that will also take care of migrations. (same as upgrading a cosmos-sdk chain, always consistent, doesn't involve replays)
• Portal loop, stays as it's. There will be a new deployment on every commit and state persistance is not important. (state isn't consistent, txs can be replayed or not, block height might change)
• localnet (it's your net, do whatever)
• mainnet.

For the best observability of the on chain data we should be mindful about not losing data state and prevent mixed states.
For the best UX, we should avoid any downtimes in the network that we refer inside the docs and courses.

For those reasons, I suggest having the docs use the devnet and testnets and point people to portal loop or localnet for experimenting and testing the hottest features.

[moul]

Rename staging to dev or devnet, make the state persistent by writing migrations when data structure is changed. Redeploy the devnet every month, appoint a release manager for it that will also take care of migrations. (same as upgrading a cosmos-sdk chain, always consistent, doesn't involve replays)

Perhaps we should rename the current staging to better reflect its purpose. However, what you're suggesting seems distinct, and the current staging serves other needs. I rely on the current staging, so replacing it with a stricter version like you propose or what other networks use would make me lose the current functionality.

Aligned on other points.

[moul]

I believe the current documentation needs clarity on what a portal loop is and what it is not. You can refer to #1941 for more information.

[leohhhn]

@moul

Apart from the Testnets page, we have a separate page for the Portal Loop itself, as it is a more specific piece of tech. I will push out a PR to add more details on how the replay mechanism actually works.