Skip to content
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

Open
moul opened this issue Aug 29, 2024 · 4 comments
Open

RFC: shorter lifespan for testnets and enhancing portal loop #2744

moul opened this issue Aug 29, 2024 · 4 comments
Labels
📖 documentation Improvements or additions to documentation help wanted Want to contribute? We recommend these issues. ❓ question Questions about Gno

Comments

@moul
Copy link
Member

moul commented Aug 29, 2024

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
Copy link
Contributor

grepsuzette commented Aug 30, 2024

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 pass1),
  • 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
Copy link
Member Author

moul commented Aug 31, 2024

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.

@moul moul added 📖 documentation Improvements or additions to documentation help wanted labels Aug 31, 2024
@grepsuzette
Copy link
Contributor

grepsuzette commented Sep 1, 2024

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
Copy link
Member

thehowl commented Sep 26, 2024

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

@Kouteki Kouteki modified the milestone: 💡Someday/Maybe Oct 2, 2024
@Kouteki Kouteki added help wanted Want to contribute? We recommend these issues. and removed help wanted labels Oct 2, 2024
zivkovicmilos added a commit that referenced this issue Nov 4, 2024
## 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 <[email protected]>
@Kouteki Kouteki moved this from Triage to Backlog in 🧙‍♂️gno.land core team Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📖 documentation Improvements or additions to documentation help wanted Want to contribute? We recommend these issues. ❓ question Questions about Gno
Projects
Status: 📥 Inbox
Status: Backlog
Development

No branches or pull requests

5 participants
@moul @grepsuzette @thehowl @Kouteki and others