Sui: In-depth Analysis of Move VM Technical Details

In today's blockchain technology field, Move VM, as a key technical component, plays an important role in Sui.
This article provides an in-depth analysis of Move VM’s technical details, including:

• Initialization process
• Code caching mechanism
• Module & script publishing
• Function execution
• Binary format analysis

---

1. Move VM Initialization

The initialization of Move VM is simple and efficient. It requires just a single Loader instance — essentially a few Mutex-protected empty tables like HashMap and Vec.

This process is low-cost and sets the groundwork for all VM operations.

Move VM uses on-demand code loading.
Code isn’t preloaded; instead, it's fetched at runtime during function or script execution.

Once loaded, modules/scripts are cached and reused, boosting performance significantly.

---

2. Code Caching Mechanism

2.1 First-Time Loading

When the VM loads a module for the first time:

1. Queries the data store to fetch binary data (Vec<u8>)
2. Deserializes and verifies the data for accuracy and integrity
3. Loads all dependencies with the same process
4. Links the module with its dependencies
5. Caches the module via Loader for reuse during the VM lifecycle

2.2 Cache Coherence

• System transactions (like hard upgrades) may break code cache coherency.
• The client should suspend transaction processing and restart the VM when this happens.
• Clients must align their DataStore view with loaded code, and re-instantiate the VM if needed.

---

3. Module Publishing Process

To publish a module, the client calls publish_module with:

• Serialized module bytes
• Sender’s address
• A reference to GasMeter

Steps:

1. Deserialization

   • If it fails → return an error.

2. Address Validation

   • Module address must match sender address → else MODULE_ADDRESS_DOES_NOT_MATCH_SENDER.

3. Duplication Check

   • Re-publishing same-named module → DUPLICATE_MODULE_NAME error.

4. Load Verification

   • Ensures module is loadable later. Fails? Return error.

5. Write to Storage

   • Once verified, the serialized module is saved and considered valid.

---

4. Script Execution Mechanism

A script in Move is essentially a one-off function, often used to execute transactions.

Steps:

1. Load Script & Main Function

   • Calculate sha3_256 hash of the script.
   • Use hash to check if it's in the cache.
   • If not cached → load and verify.
   • Verify main function type params.

2. Build Parameter List

   • Signer values based on sender accounts.
   • Other args must match allowed types → else TYPE_MISMATCH.

3. Execute Script

   • VM calls interpreter.
   • On error → transaction fails and error returned.
   • Else → return success.

---

5. Script Function Execution

Introduced in Move VM v2.0.

• Works like a regular script
• Source is a script-visible function inside an on-chain module

Steps:

1. Load the function using ModuleId and function name
2. Check visibility (script)
   • Not script-visible? → EXECUTE_SCRIPT_FUNCTION_CALLED_ON_NON_SCRIPT_VISIBLE
3. Execute same as normal script

---

6. General Function Execution

Move VM allows you to execute any function in a module by name.

Function names are unique in a module → no signature needed.

Execution Steps:

1. Load Module

   • If error → return failure

2. Resolve Function

   • If not found → FUNCTION_RESOLUTION_FAILURE
   • Check type params match → else error

3. Build Parameter List

   • Match all params to allowed types → else TYPE_MISMATCH

4. Execute

   • Interpreter runs the function
   • VM returns result

---

7. Binary Format Analysis

7.1 Overall Architecture

• All modules/scripts exist in binary form
• Modules = collections of functions & structs
• Scripts = simple entry points (no return value)

Uses ULEB128 for integer compression and size-prefixing for vectors.

7.2 Binary Header

3 components:

• Magic: Fixed 4 bytes → 0xA1, 0x1C, 0xEB, 0x0B
• Version: 4-byte little-endian int
• Table count: ULEB128

7.3 Table Headers

Each header includes:

• TableKind (1 byte)
• TableOffset (ULEB128)
• TableLength (ULEB128)

Tables must be contiguous, non-overlapping.

7.4 Table Details

Tables describe:

• MODULE_HANDLES: module locations via index
• ADDRESS_IDENTIFIERS, IDENTIFIERS, STRUCT_HANDLES, FUNCTION_HANDLES: type and function metadata
• FUNCTION_INSTANTIATIONS, SIGNATURES, CONSTANT_POOL: instantiations and constants

7.5 Auxiliary Definitions

• Type Parameter Kind: 1 byte → ALL, COPYABLE, RESOURCE
• SignatureToken: 1 byte to represent types (U8, U64, STRUCT, etc.)
• Bytecodes: 1 byte opcode + optional payload → e.g., POP, RET, BR_TRUE

7.6 Script Specific Binary Data

• Scripts lack FUNCTION_DEFINITIONS
• Instead, they embed entry info directly:
  • Type parameter count & types
  • Param type indexes
  • Bytecode length & body

---

✅ Conclusion

Move VM offers a powerful, secure, and efficient environment for blockchain execution.
By understanding:

• VM initialization
• Caching strategies
• Function/module execution
• Binary structure

Developers can optimize their Move-based apps and debug issues effectively — contributing to the evolution of the Sui ecosystem.