RFC: shorter lifespan for testnets and enhancing portal loop

[moul]

TL;DR:

• regularly release new testX testnets (e.g., monthly)
• sunset testX-2
• make block height and timestamp consistent on portal loop (and gnodev? 🙏)
• developers should use portal loop
• node operators and tool writers should focus use testnets (and eventually portal loop)
• automated workload on testnets with tx relaying

---

In my opinion, test4 is not being utilized in the way it should be, and people often forget that it is:

• Already deprecated
• Scheduled for sunset

Instead of improving the Portal Loop to address its primary limitation for developers (lack of block and timestamp consistency), we are ignoring this problem and investing time and energy in developing tools and dapps on a network that will be discarded, and people keep asking me to make test4 permanent for SEO reasons, etc. And some other are proposing also to make test4 flexible (a.k.a., a kind of loop, lol).

Another aspect of test4 is the multi-node environment, which is currently useful for detecting bugs. However, we are only testing a running chain, not the deployment of a new one. As a result, test4 is primarily a networking-oriented network where we only test a portion of what a network entails.

My proposal is to regularly release a new testX testnet, perhaps on a monthly basis. This would make it more evident that everything on test4 will be deleted soon and reinforce the idea that a testnet is closely associated with a specific git hash (deprecated after 1 commit).

By keeping testX and testX-1 running, we can sunset test4 only when we release test6. This would allow us to focus the testX networks on the following:

• Testing networking features (p2p, consensus)
• Testing the deployment of a new network and pre-genesis coordination
• Testing the release process, including git tags and reviews
• Allowing tools like indexers to practice managing multiple stable networks and updating their configurations accordingly

We should maintain the Portal Loop (the devnet) as the suggested developer network, where developers can discover, experiment, and showcase their work, potentially with incentivization. This devnet should serve as our dynamic frontend website, (marketing needs + staging for features) ensuring that the initial set of contracts we release (in the examples folder) are of high quality and provide an MVP of required dapps.

In addition to my proposal to establish a known end-of-life for the testnets and make them true testnets, we should also consider unlocking people who depend on block height and timestamps on portal loop. This includes both developers who cannot find an alternative way to write their flow logic and tools that could potentially start indexing the Portal Loop as if it were a blockchain in terms of consistency (although I'm not sure if this is feasible).

Finally, I suggest that we create a small tool to simulate load on the testX networks. This tool would attempt to relay the transactions made on the Portal Loop to the testX networks. Most of these transactions will fail due to inconsistent sequence numbers, but for users exclusively relying on the Portal Loop, we can expect a decent amount of transactions to pass, providing additional load testing alongside the dedicated workload tests we'll perform on the testX networks. This approach would also require the testX networks to have the same chain ID, which may not be ideal but could be a reasonable compromise to enable this mirroring feature.

cc @leohhhn @ilgooz @zivkovicmilos

[grepsuzette]

Hey Manfred,

Since I wrote most of the recent packages on test4 this past week, seems I could explain my motives (although the way you write about it, seems it concerns much more people):

• some time ago I published a PR for a stateless tic-tac-toe demo (feat(examples): add r/demo/games/tictactoe 1P-VS-CPU #2554, btw take a look got some questions for you).
• this is a demo I expect to be contentious (half-expect it to not pass¹),
• but sometimes a demo is a good way to raise questions,
• however until it's accepted, only reviewers will see it,
• hence why test4 deployment.

Comments:

• 1 month between new testnets, 2 months for sunset seems good.
• it's amazing to use test4, absolutely love it.

Footnotes

1. one reason is because if nobody pays for gas for this game, validators will be working for free. Another is because it uses its own styles. ↩

[moul]

I don't expect people to avoid using test4, especially developers who want to. I expect us, especially through documentation, communication, and devrel efforts, to guide people to use the right network for the right purpose. Please feel free to use test4 if you don't care about the limitations I mentioned above.

To be honest, after reading what you wrote, I still don't understand why you believe test4 was a better choice, because everything you said is also compatible with Portal Loop. Either I missed something, or the issue is more complex than I realized. It seems there might be a gap in how I've communicated the purposes and benefits of test4 and Portal Loop. I want to improve this understanding and am looking for ways to communicate better about what is unclear.

[grepsuzette]

To be honest, after reading what you wrote, I still don't understand why you believe test4 was a better choice, because everything you said is also compatible with Portal Loop. Either I missed something, or the issue is more complex than I realized. It seems there might be a gap in how I've communicated the purposes and benefits of test4 and Portal Loop. I want to improve this understanding and am looking for ways to communicate better about what is unclear.

The fact it was possible to directly addpkg to Portal Loop completely went over my head...

---

In my opinion, the docs could do a better job to explain contributors can deploy packages permissionlessly on Portal Loop. You see, there is a gap in complexity between:

• testnets like test3, test4 which are permissionless and conventional chains,
• Portal Loop which is neither purely permissioned, permissionless, or even an actual chain: it is a perceived continuity of successive reconstructed chains where,
  • the living chain is permissionless,
  • the process of reconstruction has a permissioned aspect (the master branch has authority, its packages are added before recorded transactions).

It is easy to forget you can permissionlessly deploy to it, or simply to assume the only way to publish anything on Portal Loop is by getting your PR s approved.

---

I suggest https://docs.gno.land/concepts/portal-loop/ to have a new section "Permissionless deployments to Portal Loop" mentioning that:

• you can permissionlessly deploy packages to Portal Loop, using gnokey maketx addpkg,
• you could do that e.g. to allow people testing realms you submit to the monorepo even before they get approved,
• packages deployed from master will supersede packages deployed permissionlessly (given identical pkgpath), because they get added first.

[thehowl]

The portal loop CI needs to check that it's not breaking current transactions of the current portal loop execution; see specific issue: #2862