feat: support custom VM domain

[moul]

Introducing the concept of "ChainDomain," a local primary domain for packages.

The next step, which will be another PR, is to ensure that we can launch a gnoland/gnodev instance while importing a local folder or using a genesis to preload packages from other domains. This will allow users to add packages only to the primary domain while accessing packages from multiple domains. The result will be a preview of the upcoming IBC era, where a single chain can add packages only to its domain but can fetch missing dependencies from other registered zones.

• gnovm unaware of gno.land, just accepting valid domains
• vmkeeper initialized with a domain
• Stdlib to know the current primary domain + new std.ChainDomain
• new unit tests around custom domains

Depends on #2910
Depends on #3003
Blocks a new PR that will add multidomain support.
Related with #2904 (comment)

[codecov]

Codecov Report

Attention: Patch coverage is 72.34043% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gno.land/pkg/gnoland/node_inmemory.go	0.00%	8 Missing ⚠️
gno.land/pkg/sdk/vm/keeper.go	80.00%	2 Missing and 1 partial ⚠️
gnovm/stdlibs/std/native.go	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[gh-gno-bot]

Merge Requirements

The following requirements must be fulfilled before a pull request can be merged.
Some requirement checks are automated and can be verified by the CI, while others need manual verification by a staff member.

These requirements are defined in this configuration file.

Automated Checks

🔴 Maintainers must be able to edit this pull request
🟢 The pull request head branch must be up-to-date with its base

Details

Maintainers must be able to edit this pull request

If

🟢 Condition met
└── 🟢 On every pull request

Then

🔴 Requirement not satisfied
└── 🔴 Maintainer can modify this pull request

The pull request head branch must be up-to-date with its base

If

🟢 Condition met
└── 🟢 On every pull request

Then

🟢 Requirement satisfied
└── 🟢 Head branch (dev/moul/gno-domain) is up to date with base (master): behind by 0 / ahead by 36

Manual Checks

• The pull request description provides enough details

Details

The pull request description provides enough details

If

🟢 Condition met
└── 🟢 Not (🔴 Pull request author is a member of the team: core-contributors)

Can be checked by

• team core-contributors

[MikaelVallenet]

i also found that it does not work with gnodev for now, the params should be added to genesis state in contribs/gnodev/pkg/dev/node.go and added into every execContext in gno.land/pkg/sdk/vm/keeper.go (it's what i did on my side with chain tz to make it work with gnodev, maybe it's not the good way)

[moul]

i also found that it does not work with gnodev for now, the params should be added to genesis state in contribs/gnodev/pkg/dev/node.go and added into every execContext in gno.land/pkg/sdk/vm/keeper.go (it's what i did on my side with chain tz to make it work with gnodev, maybe it's not the good way)

Do you have an example?

[MikaelVallenet]

i also found that it does not work with gnodev for now, the params should be added to genesis state in contribs/gnodev/pkg/dev/node.go and added into every execContext in gno.land/pkg/sdk/vm/keeper.go (it's what i did on my side with chain tz to make it work with gnodev, maybe it's not the good way)

Do you have an example?

So here is the addition of params into genesis: c3ecc97
Here is the file where i add chain tz to every ExecContext: https://github.com/gnolang/gno/pull/3193/files#diff-3663e30f0c0e01d8d47bb7974d605b4cf12d1a244970c6a9bbba55fb0be6aced
Without this, running gnodev --<param>=<value> will not work, (not sure it's good to do the way i did tbh)

[moul]

So here is the addition of params into genesis: c3ecc97

I suggest you switch to my method. I implemented this in gnoland, which is used by pkg/integration. You made a similar change, but only in gnodev, making this feature harder to use and test outside of gnodev.

Here is the file where i add chain tz to every ExecContext: #3193 (files)

If I'm not mistaken, that's what I did as well. Do you see any places where I overlooked it?

[MikaelVallenet]

So here is the addition of params into genesis: c3ecc97

I suggest you switch to my method. I implemented this in gnoland, which is used by pkg/integration. You made a similar change, but only in gnodev, making this feature harder to use and test outside of gnodev.

Here is the file where i add chain tz to every ExecContext: #3193 (files)

If I'm not mistaken, that's what I did as well. Do you see any places where I overlooked it?

• Yes this one is just the commit about gnodev, but i think the change should be applied to both places

• I can see on your PR
  you did not add ChainDomain in ExecContext return value in QueryEval and QueryEvalString and Call function maybe AddPackage function too (github diff is a bit broken and does not display func name). I added it to these places, but i dont know exactly what QueryEval or QueryEval are used for, just felt it could fix my gnodev issue since it returns ExecContext and it works

[moul]

Yes this one is just the commit about gnodev, but i think the change should be applied to both places

`gnodev` -> `gno.land/pkg/integration` > `gno.land/pkg/gnold`
    CLI       ->             helper with new arg  >        actual place where we create a dynamic genesis

The param override should occur in gnoland. gnodev should simply configure its CLI parser and pass the new option, but it shouldn't manipulate the genesis directly (not for this case).

I can see on your PR
you did not add ChainDomain in ExecContext return value in QueryEval and QueryEvalString and Call function maybe AddPackage function too (github diff is a bit broken and does not display func name). I added it to these places, but i dont know exactly what QueryEval or QueryEval are used for, just felt it could fix my gnodev issue since it returns ExecContext and it works

I should definitely add them. Thank you.

• TODO