-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: shorter lifespan for testnets and enhancing portal loop #2744
Comments
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):
Comments:
Footnotes
|
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. |
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:
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:
|
The portal loop CI needs to check that it's not breaking current transactions of the current portal loop execution; see specific issue: #2862 |
## Description This PR introduces metadata support for genesis transactions (such as timestamps), in the form of a new Gno genesis state that's easily generate-able. Shoutout to @clockworkgr for sanity checking the idea, and providing insights that ultimately led to this PR materializing. **BREAKING CHANGE** The `GnoGenesisState` is now modified, and all functionality that references it (ex. `gnogenesis`, `tx-archive`) will need to adapt. ### What we wanted to accomplish The Portal Loop does not save "time" information upon restarting (from block 0). This means that any transaction that resulted in a Realm / Package calling `time.Now()` will get differing results when these same transactions are "replayed" as part of the loop (in the genesis state). We wanted to somehow preserve this timestamp information when the transactions (from a previous loop), are executed as part of the genesis building process. For example: - Portal Loop chain is on block 100 - tx A results in a call to `time.Now()`, which returns time T, and saves it somewhere (Realm state) - the Portal Loop restarts, and uses all the transactions it encountered in the past iteration as genesis txs - the genesis is generated by executing the transactions - when tx A is re-executed (this time as part of the genesis block), **it should return time T, as with the original execution context** It is worth noting that this functionality is something we want in `gnodev`, so simple helpers on the Realms to update the timestamps wouldn't work. ### What this PR does I've tried to follow a couple of principles when working on this PR: - don't break backwards compatibility - don't modify critical APIs such as the SDK ABCI, but preserve existing, working, functionality in its original form - don't add another layer to the complexity pancake - don't implement a solution that looks (and works) like a hack I'm not a huge fan of execution hooks, so the solution proposed in this PR doesn't rely on any hook mechanism. Not going with the hook approach also significantly decreases the complexity and preserves readability. The base of this solution is enabling execution context modification, with minimal / no API changes. Having functionality like this, we can tailor the context during critical segments such as genesis generation, and we're not just limited to timestamps (which is the primary use-case). We also introduce a new type of `AppState`, called `MetadataGenesisState`, where metadata is associated with the transactions. We hide the actual `AppState` implementation behind an interface, so existing tools and flows don't break, and work as normal. ### What this PR doesn't do There is more work to be done if this PR is merged: - we need to add support to `tx-archive` for supporting exporting txs with metadata. Should be straightforward to do - the portal loop also needs to be restarted with this new "mode" enabled - we need to add support to existing `gnoland genesis` commands to support the new `MetadataGenesisState`. It is also straightforward, but definitely a bit of work - if we want support for something like this in gnodev, the export / import code of gnodev also needs to be modified to support the new genesis state type (cc @gfanton) - #2943 Related PRs and issues: - #2751 - #2744 cc @moul @thehowl @jeronimoalbi @ilgooz <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details> --------- Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>
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
The text was updated successfully, but these errors were encountered: