grepsuzette
commented
3 months ago 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 (#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[^1]),
- 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.
[^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
thehowl
TL;DR:
In my opinion, test4 is not being utilized in the way it should be, and people often forget that it is:
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:
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