sui icon indicating copy to clipboard operation
sui copied to clipboard

[move] 0x0 subst on publish matches source subst

Open amnn opened this issue 2 years ago • 0 comments

Replacing address 0x0 with a fresh address during publish was previously handled by ModuleHandleRewriter, which took a mapping of new to old module handles (address, name pairs) and visited all structures that referenced them in a CompiledModule replacing old for new, and allocating new slots in the identifier and address pools as needed.

This process can be simplified because of the following properties:

  • All the identifiers are already allocated.
  • There is only one new address, the new Package ID.
  • That address is replacing the old 0x0 address in all cases.

The new implementation takes advantage of these properties and the indirection of the Address Identifier Pool, and substitutes the address at the index referenced by the module's self_handle (which it confirms is 0x0) with the new address.

Gas costs reduce slightly, because published module sizes decrease (by the size of one address in the pool).

The main motivation for this change is dependency source verification: The old implementation left a redundant 0x0 in the address pool, which developers do not get if they set the address of the module in Move.toml, this meant that the following (common) process results in a source verification failure:

  • Write a package b, with its address set to 0x0.
  • Publish it, remember its address.
  • Substitute its address in Move.toml with the published address.
  • Distribute its source.
  • Depend on this source when writing another package, a.
  • Publish the new package.

The second publish will fail dependency verification, because the locally compiled b will not contain 0x0 in its address pool, but the on-chain b will. With this change, that is no longer true, and source verification passes in this case.

Test Plan

cargo simtest
cargo nextest run
  • new source verification tests coming in a follow-up commit.

amnn avatar Nov 21 '22 14:11 amnn