I Like to Move It, Move It - Foresight News EN

Written by DongHyun Kang, Reseach Associate of Xangle

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.

As mentioned above, Move/MoveVM is also highly scalable, with a theoretical maximum of 160,000 TPS due to the ability to process transactions in parallel. This makes Aptos free of bottlenecks. Meanwhile, EVM must process transactions sequentially due to the risk of double-spending and reentrancy attacks. As a result, EVM chains suffer bottlenecks, with rapidly rising gas costs and transactions stagnating when there is a large number of transactions occurring at once.

When it comes to flexibility, Solidity/EVM has an advantage over Move/MoveVM. Solidity/EVM uses dynamic dispatch, whereas Move/MoveVM employs static dispatch. Move’s use of static dispatch enhances the security of smart contracts but limits their functionality when compared to Solidity. Additionally, Solidity permits protocol and contract code upgrades at any time, while Move imposes restrictions on these upgrades. Regarding interoperability between blockchains, Solidity demonstrates more flexibility and scalability than Move, primarily because Team EVM, including Ethereum, favors modular blockchains, whereas Team Move leans towards monolithic blockchains.

3.2. Move vs. Rust

Move, being derived from Rust, shares many performance and feature similarities with Rust, such as efficiency and security. The key distinction lies in their intended purposes: Rust serves as a general-purpose programming language, whereas Move specializes in smart contract development. Rust was designed for broader applications and is widely employed in various development contexts, including those unrelated to blockchain. Consequently, using Rust for smart contract code can result in longer and more intricate code. In contrast, Move is tailored as a blockchain-specific language dedicated to smart contracts. While this restricts its use to blockchain development, it leads to relatively concise and less complex code when writing smart contracts.

Above is a comparison of the code length between Solana and Sui when developing the same smart contract. It’s evident that longer code means more opportunities for potential smart contract attacks. Longer code also increases the chances of developers making errors, which could be overlooked during code inspection. In contrast, Move holds an advantage with its simpler code development, reducing the likelihood of developer errors and facilitating more effective inspection.

3.3. Aptos Move vs. Sui Move

Aptos Move and Sui Move both originated from the same Diem team, so they share many similarities. They are initially influenced by Rust, which gives them similar syntax and functionality. Additionally, both projects use Move Prover for validating smart contracts.

However, Aptos Move has retained the original Diem blockchain and adopted an object-oriented programming model, while Sui Move has introduced the object-oriented Sui blockchain as an evolution of Diem. Sui transitioned to an object-oriented blockchain to support parallelism, which depends on knowing the data to be read and written. Consequently, Aptos utilizes a resource model that classifies application building blocks into three distinct units: unique identifiers, properties, and methods. On the other hand, Sui employs an object-oriented model, dividing the application’s building blocks into states and behaviors. This results in Aptos Move offering developers considerable flexibility while Sui Move is relatively opinionated.

Aptos Move and Sui Move exhibit differences in how they operate on the blockchain. To begin, both blockchains support parallel processing, albeit through distinct methods. Aptos achieves parallel transaction processing through Block-STM, as previously mentioned, whereas Sui employs a Directed Acyclic Graph (DAG) structure to store transactions. The DAG structure severs transaction interlinking, enabling parallel transaction processing.

Another distinction lies in how reentrancy attacks are prevented. Aptos, as previously mentioned, prevents reentrancy attacks by employing Static Dispatch to validate the smart contract’s state before execution. In contrast, Sui thwarts reentrancy attacks by updating the smart contract’s state only once during transaction execution, ensuring the state remains unchanged even if an attacker interrupts the transaction. Furthermore, since Sui’s DAG structure is not reliant on transaction order, interruptions to one transaction don’t affect the independent processing of other transactions, providing an additional layer of protection against reentrancy attacks.

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

Move/MoveVM offers a promising platform for blockchain development, yet it faces two significant challenges. 1) Move still lags behind Solidity in terms of having an established developer ecosystem. Aptos has been in existence for nearly a year, while Sui launched its mainnet just recently. Consequently, Move has a considerable journey ahead when compared to Solidity, which boasts an established developer community. Solidity, with its eight-year history, offers a wide array of developer tools and dedicated training programs. For developers, having a supportive community to provide feedback on their work is essential, and Solidity already boasts a substantial developer community that hosts hackathons worldwide. Turing estimates the Solidity developer community to be around 200,000 strong.

Move, in contrast, has undergone development since Facebook, but most of it has been an internal effort by the Diem team. Consequently, the developer ecosystem for Move is neither as mature nor as extensive as that of Solidity. While there exists an Aptos developer community, including the Aptos Forum, it lacks the structured training programs, developer tools, and open feedback mechanisms found in Solidity. Mysten Labs, the company behind Sui, estimates the number of Move developers at 10,000, although Aptos does not provide an official count.

Secondly, 2) Move lacks a standout killer dApp. Many EVM chains like Ethereum and Arbitrum host numerous dApps that enjoy widespread use among crypto users. However, the Move ecosystem has yet to produce a similar standout application. As of September 26, Aptos’ total value locked (TVL) was $43.5M, notably smaller than the primary EVM layer 2, which boasts a base of over $300M (Source: DeFiLlama).

The Aptos Foundation has acknowledged the challenges it faces and is actively taking steps to overcome them. Firstly, the Aptos Foundation is placing a high priority on developing developer tools to nurture a thriving developer ecosystem. They have introduced an Aptos Tutorial to assist early developers in getting started and are creating educational programs like Move Spider. Additionally, the Aptos Foundation is fostering the developer community by organizing meetup groups worldwide, including in the United States, Korea, and China, to further enhance the developer ecosystem.

On the business side, Aptos is actively building partnerships with well-known entities and those with massive distribution in various sectors—NBCUniversal, Microsoft, Google, Netmarble(Marblex), Neowiz, and Chingari to name a few. On another note, Aptos is diligently working on internalizing Onchain Randomness through AIP-41 to facilitate game company integration. The adoption of AIP-41 by Aptos offers game companies a cost-effective alternative to middleware like Chainlink’s VRF for ensuring item randomization within the EVM chain, making Aptos an attractive choice.

5. Closing Thoughts

This article centers on Aptos’ Move/MoveVM and conducts a feature comparison with existing blockchain development languages. The findings reveal that Move is purpose-built for developing blockchain smart contracts and offers clear technical advantages over existing languages. However, Move is still in its early stages in terms of developer and dApp ecosystems. Presently, Solidity boasts approximately 20 times the number of developers compared to Move, and in terms of Total Value Locked (TVL) and influential dApps, Solidity holds a well-established position. Nonetheless, Move is only a year old and stands as one of the few programming languages dedicated to blockchain development, suggesting significant untapped potential. Furthermore, the language’s reputation, developed by the Diem team, adds to the prospects of Move ecosystem growth. Consequently, it is worthwhile to monitor whether Move, regarded as a comprehensive blockchain programming language, as illustrated in the figure above, can evolve to compete with Solidity.