I Like to Move It, Move It

user-image
DongHyun Kang
Research Associate/
Xangle
Oct 17, 2023

1. Introduction

2. What is Move?

3. Comparison with Other Languages and VMs

4. Next Step: Building a Strong Developer Ecosystem and Killer DApps

5. Closing Thoughts

 

 

 

1. Introduction

In the Web3 industry, the emphasis is on providing users with a seamless experience. From this perspective, the blockchain upon which a dApp is built matters less than the interoperability that ensures a smooth user experience across different blockchains. In the years 2021 and 2022, lively debates unfolded between monolithic blockchains and multi-chains. Notably, Solana and Luna rose to prominence briefly, only to recede, paving the way for Aptos and Sui to capture the market's attention.

Aptos and Sui, both descendants of Meta's blockchain project Diem (formerly Libra), have a common thread—they both employ the Move programming language. This article hones in on Aptos, delving into the characteristics of the Move language it utilizes and the MoveVM state machine, and how it measures up against established programming languages and state machines such as Solidity/EVM and Rust/WASM.

 

2. What is Move?

2.1. How Move came to be 

The Diem team at Facebook (now Meta) identified two limitations in the widely-adopted Solidity programming language within the blockchain industry. First and foremost, Solidity exhibits vulnerabilities like reentrancy attacks and double-spending attacks. While blockchain networks employing Solidity, such as Ethereum, mitigate these attacks through consensus algorithms, it is an undeniable fact that the language itself harbors potential attack vectors.

Secondly, Solidity's inability to parallelize transaction processing leads to bottlenecks. To prevent double-spending, Solidity mandates the sequential execution of transactions such as smart contracts. This sequential processing limits speed, which in turn hinders the blockchain’s scalability.

Driven by these concerns, the Diem team (Meta's blockchain division) developed the Move language, influenced by Rust, to address the aforementioned shortcomings. While Rust is a commendable programming language, it can lead to lengthy code when used for writing smart contracts. Subsequently, Aptos retained the original Move language while incorporating an object-oriented programming model, evolving it into Aptos Move. Meanwhile, Sui adopted an object-oriented language known as Sui Move.

2.2. Aptos Move/MoveVM Features

Aptos' Move/MoveVM have been meticulously designed with a primary focus on security. Furthermore, Aptos streamlined Move's contract code and enabled parallel processing, minimizing the potential for blockchain attacks and maximizing scalability. In this section, we will delve into how Move accomplishes these features.

Enhanced Security with Move Prover and Resource Model

Formal verification involves mathematically proving that a software’s code adheres to specific rules or properties. Aptos leverages formal verification through the Move Prover tool to verify the security of its smart contracts. Move Prover can shield against potential attack vectors within smart contracts, such as double-spending and reentrancy attacks, by applying formal verification, while also identifying other code errors and ensuring stability. Unlike other blockchains that rely on consensus algorithms to fend off double-spending and reentrancy attacks, Move proactively addresses these issues through its language and tools.

Additionally, MoveVM employs static dispatch to call functions to prevent reentrancy attacks on function calls. In contrast, the conventional Ethereum Virtual Machine (EVM) uses dynamic dispatch. These two approaches differ in the timing of function calls within the program execution sequence, which typically proceeds as follows: Compile → Link → Load → Run → Terminate. Static dispatch involves calling functions at compile-time, enabling smart contracts to undergo a preliminary error-checking phase at this stage. Consequently, in MoveVM, smart contracts enter the verification phase early, effectively preempting reentrancy attacks at the source.

Transaction Parallel Processing

Aptos MoveVM enhances scalability through transaction parallel processing. To achieve this, MoveVM employs Block-STM (Block-Level Software Transactional Memory) to distribute database transactions across multiple threads for parallel execution. A closer look at Block-STM reveals the following key features:

  • Block-STM utilizes optimistic concurrency control to execute transactions in parallel and subsequently validates them. Transactions that encounter conflicts are re-executed.
  • Block-STM employs a multi-version data structure to prevent write-write conflicts. All writes are stored in the same location, along with transaction IDs and the number of re-executions. This ensures that transactions are processed sequentially in the predefined order even if they are re-executed.

  • Block-STM introduces a collaborative scheduler to prioritize the execution and validation of sub-transactions, thus specifying the processing order among transaction threads. Move employs this collaborative scheduler to prevent conflicts between transactions and prevent their invalidation.

  • Finally, dynamic dependency estimation is used to group transactions by estimating their dependencies and identifying related transactions.

Through Block-STM, Aptos achieves parallel transaction processing in the following ways. Additionally, while validation is uniform among validators, execution occurs in parallel across each validator, further enhancing scalability. The summary of Aptos' transaction parallel processing is as follows:

1. Users generate transactions and sends them to the network.

2. Validators authenticate transactions.

3. Authenticated transactions are grouped based on dynamic dependency estimation, and simultaneously each transaction group undergoes parallel processing by validators.

4. Processed transactions are compiled into blocks and disseminated throughout the network.

Enhanced Developer and User Convenience with Aptos Token Standards

Aptos also used Move to build its own token standard, the Aptos Coin Standard. In doing so, Aptos has improved upon the limitations associated with the traditional EVM. MoveVM eliminates the need to issue a separate smart contract for token issuance, which allows for the issuance to occur with only a small gas fee. However, this was not a significant advantage as non-EVM blockchains such as Solana and Algorand also use their own token standards.

Nevertheless, starting from August 2023, Aptos introduced two new standards for FTs and NFTs. Notably, the new standard for FTs enables developers to choose and issue one of the following based on their development objectives: regular token assets, tokenized RWA, or in-game tokens. This appears to align with Aptos' strategy to tap into the growing RWA-associated market. In practice, Web 2.0 companies often seek control over assets when tokenizing RWAs, but Ethereum's limitations have made it challenging to achieve this, leading many companies to embark on the creation of their own blockchains. In contrast, Aptos has made it possible to accomplish this at the protocol level through token standard settings.

 

3. Comparison with Other Languages and VMs

3.1. Move vs. Solidity

Move/MoveVM was created to compensate for the limitations of Solidity, so it is more secure and scalable than Solidity. As elucidated earlier, the features of Move/MoveVM fortify Aptos with enhanced security and scalability. As mentioned in 2.1, MoveVM prevents reentrancy and double-spending attacks at the language stage, while Solidity/EVM has already seen numerous reentrancy attacks. The DAO attack of Ethereum in 2016 is a prime example, and while the Ethereum Foundation has issued preventative measures, there are still numerous reentrancy attacks in DeFi. Hackers are still attempting reentrancy attacks in the hope that a wrong contract will be deployed in DeFi of the EVM ecosystem.