search

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source.
https://gno.land/
Other
880 stars 364 forks source link

[GnoVM] Whitelist deployment paths instead of import paths #1865

Closed leohhhn closed 3 months ago

leohhhn commented 6 months ago

Description

It seems that in transpile.go, some imports are not allowed. Why is this?

Currently, it seems that imports from p/demo & r/ are allowed, along with packages from the stdlibs whitelist.

From a DevX perspective, it makes much more sense to not allow deployment to specific paths, instead of not allowing imports. People can get stuck with a package that has been deployed successfully, but is not importable - this clogs on-chain storage, and makes for temporarily or permanently useless code.

This is part of a larger namespacing issue.

EDIT: I noticed a weird thing that is happening: when deploying to a local network, the above rules apply. However, when working with Portal Loop, it seems that packages under p/ can also be namespaced. Here is an example.

cc @zivkovicmilos, @gfanton

thehowl commented 4 months ago

This is an issue I was aware of. #1695 fixes it, removing the stdlibWhitelist and similar exceptions entirely.

The reason why it exists in the first place, is that the current transpiler is selective on what it can transpile or not; partly due to the fact that it does not attempt to transpile standard libraries. For this reason, when transpiling, the stdlibs have to exist in both Gno and Go; and have matching function names and signatures. (Hence, the reason for stdshim, which is instead transpiled).

1695 allows full transpilation without exceptions, and thus no restrictions on this front.

As of the recently merged #1702, the transpiler check is no longer in the gnokey command, and so you should also be able to publish without name restrictions (aside from having to use /p and /r.)