Gno Realm and Ownership Spec #2743
Comments
This was referenced Aug 29, 2024
Draft
|
Just added a new topic proposal.
|
This was referenced Oct 15, 2024
6 tasks
|
We recently discussed the possibility of not supporting local storage for remote realms. I understand this decision, as managing data would become more challenging and restrictive due to garbage collection, realm deprovisioning, or upgradeability. However, I appreciate this feature for its composability and the opportunities it offers. I'm currently brainstorming ways to adapt if we enable this additional inter-realm independence. The first experiment is underway in #3135. Edit: #3135 is also adding several new |
moul
added a commit
that referenced
this issue
Dec 3, 2024
- [x] Switch to storing a `type XXX func() grc20.Token` instead of a `grc20.Token` directly. - [x] Implement `grc20reg`. - [x] Add new tests in `gnovm/tests` to demonstrate the current VM's management of the cross-realm feature and support potential changes in #2743. - [x] Create a demo in `atomicswap` or a similar application. (#2510 (comment)) - [x] Try using a `Token.Getter()` helper. (Works! f99654e) - [ ] Demonstrate how to manage "disappearing" functions during garbage collection by checking if the function pointer is nil or non-resolvable. Alternative to #2516 NOT(!) depending on #2743 --------- Signed-off-by: moul <[email protected]>
r3v4s
pushed a commit
to gnoswap-labs/gno
that referenced
this issue
Dec 10, 2024
- [x] Switch to storing a `type XXX func() grc20.Token` instead of a `grc20.Token` directly. - [x] Implement `grc20reg`. - [x] Add new tests in `gnovm/tests` to demonstrate the current VM's management of the cross-realm feature and support potential changes in gnolang#2743. - [x] Create a demo in `atomicswap` or a similar application. (gnolang#2510 (comment)) - [x] Try using a `Token.Getter()` helper. (Works! f99654e) - [ ] Demonstrate how to manage "disappearing" functions during garbage collection by checking if the function pointer is nil or non-resolvable. Alternative to gnolang#2516 NOT(!) depending on gnolang#2743 --------- Signed-off-by: moul <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The issue is to follow up on the recently introduced document available here: https://docs.google.com/document/d/1eCgGPCJ8fMhNc_vc_pbgCxP10X7jGKLC89nBUGatsD4/edit
The ideal order to complete the GnoVM MVP (not only fixing bugs, etc.) is to at least finish and implement those breaking changes that should be shipped for the launch. These steps are ordered due to dependencies, and all of them are blocking the launch:
Additionally, this blocks things like pointer-based registries, see #2535, which is a pattern that deserves several rounds of experimentation before the launch, if possible. In other words, it's a high-priority blocking issue.
Assigning @thehowl and @ltzmaxwell to this, as discussed with Jae, so they can follow up on the topic and represent the EU and US teams. However, feel free to rely on the rest of the team, Jae, or me when needed.
The grantees and community are welcome to help, both on the Google Doc page or by proposing their spec PRs too; but for the sake of prioritization, the core team will directly work on it soon.
The text was updated successfully, but these errors were encountered: