[Design Task] Guidelines and tooling support for Move code portability about move HOT 2 OPEN

I think you might want to flip tier 4-5? I feel like you might want to itnroduce storage concepts before you do entry points

I think the tier system definitely seems expressive, but maybe overkill for a package system.
Thoughts on just splitting it into: "Library", "X-Library" where X is some instantiation of Move (Sui, Diem, etc), or "X-Application"
I think

• "Library" tier 1-2
• "X-Library" tier 3+5
• "X-Application" tier whatever's left

I the short term we could at least enforce a "library" annotation in the package system, that checks against natives (outside of those in the stdlib?), globals, entries, etc.

from move.

How to define the tier is a challenge.

Option 1: Like Rust, a project is a workspace, which corresponds to an address in Move, and there are many crates in a project which correspond to packages in Move. A project can depend on another project's sub-crates.

Option 2: Like Solidity, we distinguish between contract and library, and the library can only include stateless modules and will be embedded in the binary of contract when packaging. This can solve the dependency problem of pure util library(tire 1), but the disadvantage is that duplicate binary wastes state space on the chain.

Before finding a good tier solution, we can figure out how to share stdlib. Currently, Move stdlib is embedded in the x-framework in different projects and shares the 0x1 address with the framework.

Maybe stdlib can use the reserved address 0x0 and load it directly from the VM. Using the 0x0 address also can avoid module name conflicts between stdlib and x-framework.

from move.