# Iota Script: the Move language

# Introduction

Move language for smart contracts was created within the Libra project (now named: [diem](https://github.com/diem)) from Facebook.

The official repo of move tools (compiler, verifiers, VM...) is [here](https://github.com/diem/move).

All the ecosystem and tools related to Move are written in Rust.

Move language is used in several contexts:
- [Sui](https://docs.sui.io/build/move) (interesting because of Framework and support: Rust)
- [Aptos](https://aptos.dev/guides/move-guides/move-on-aptos/) (interesting because of Framework and support: Rust)
- [Solana](https://github.com/solana-labs/move) (not interesting)
- [DFinance](https://github.com/dfinance/dvm) (interesting the bridge with Go),

The embedding of Move language in the Solana chain is only an [accepted design proposal](https://docs.solana.com/proposals/embedding-move).

## Move Language

Indept documentation about the Move language can be found in ["The Move Book"](https://move-language.github.io/move/): we report within this section only some info about its use of global state and its features.

Each module is associated to an address; here an example to save BasicCoin module:

module 0x42::BasicCoin {
    // bytecode here
    ...
}


Contract code can borrow variable associated to address using `borrow_global_mut` and
`borrow_global_mut`. In this way the contract can associate structure (for example a Token)
to addresses and manipulate them accessing the global storage.

Associating storage (structs) to addresses allows to increase parallel access to global data.

## Differences with Ethereum

Ethereum digital assets are locked in the condition of the contract that declares it (i.e the smart contract is the only one able to manipulate them); your NFT or digital assets cannot validly cross the contract boundary on their own.

With the Move blockchain state, each address possesses objects that were originally stored only within the smart contract on Ethereum. Move liberates digital assets to be a first-class citizen for the first time.

## Features

Here's a list of interesting features of Move language and tools:

### Generics

Move inherith generics from Rust; for this reason is possible to use phantom types
as the following in methods:

public fun mint<T: drop>(mint_addr: address, amount: u64, _witness: T) acquires Balance {
        deposit(mint_addr, Coin<T> { value: amount });
}

The previous example allow to define and use multiple datatypes without repeating the
code multiple times.

### Named Addresses

Addresses used in the code (for example to define the module's scope `0x42::BasicCoin`)
can be named in the `Move.toml` project descriptor:

[addresses]
NamedAddr = "0x42"

and use them in the code:

module NamedAddr::BasicCoin {

in order to make addressing of module parametrical.

### Testing

Move code can contains unit tests: this feature is important to check the contract
code agains business logic bugs. You can define a testing method for example in this way:

#[test(account = @0xC0FFEE)]
fun test_mint_10(account: signer) acquires Coin {
...

and define the method under test using also parameter specified in the defined section.
The test can run in CI pipeline with the `move test` command

## Prover

> The Move Prover (MVP) is a formal verifier for smart contracts written in the Move programming language. MVP has an expressive specification language, and is fast and reliable enough that it can be run routinely by developers and in integration testing in a few minutes

[reference](https://arxiv.org/pdf/2110.08362)

### Visual Studio Code support

You need to install [move analyzer](https://github.com/solana-labs/move/tree/main/language/move-analyzer) and then the "move-analyzer" plugin

## How to implement IOTA scripting with Move

In order to use Move in IOTA scripting we need to realyze the following:

- Create a standard library of native functions to access the IOTA tx runtime
- Create a structure around the MoveVM in order to use an external datasource within Move code
- Create some kind of general purpose MoveVM to communicate with Go runtime using method invocation standards (e.g. gRPC)

The more general purpose MoveVM seems to be the one offered by the [Sui Framework](https://github.com/MystenLabs/sui/tree/main/crates/sui-framework) or [Aptos Framework](https://github.com/aptos-labs/aptos-core/tree/main/aptos-move/framework/aptos-stdlib).

* Experimental feature to run Move contract on EVM [here](https://github.com/move-language/move/tree/main/language/evm)

## Limitations

* Move language ecosystem/artefacts/libraries/wrappers are in Rust. This means that the implementation effort is related to the implementation effort of Rust that has a very steep learning curve.
* Lack of well encapsulated and plug and play solutions (e.g. an gRPC MoveVM). It seems that [this directory](https://github.com/diem/move/tree/main/language/extensions/async) can be interesting in order to address this.
* Not many dApp written in Move.*
* Existing solutions around Move are complex and it require a lot of work in order to have something running (no plug and play).