Web3.0 underlying language: What shortcomings of Solidity does Move address?

Authors: Song Jiajie, Ren Heyi, Guosheng Securities Research Institute

Why is the Ethereum ecosystem based on the Solidity language so vast, yet the market still has new expectations for new public chains? Move, originating from a major company (Meta), is widely regarded positively in the industry. Some public chains developed based on the Move language have gained market favor and capital support. With richer applications aimed at Web3, the evolution of the underlying language is fundamental. What advantages does Move have, and what shortcomings of Solidity does it address? Based on these characteristics, the Move ecosystem may give rise to new models and applications.

In contrast to existing programming languages like Solidity, the Move language considers many design details thoughtfully, such as separating libraries from application logic; however, its most prominent feature is its resource type, which is resource-oriented programming. In terms of Dapp application support, it absorbs the advantages of Bitcoin's script and Ethereum's smart contracts, leading to a generally positive outlook on this programming language in the industry. Moreover, Move is also attempting to address the security issues that Solidity has been criticized for.

Move is a resource-oriented programming language, where resources are "first-class citizens" in the Move world. Its key feature is the custom resource type: resources can never be copied or implicitly discarded, and can only be moved between program storage locations. Solidity is not resource-oriented; a user's account holds a certain Token asset, which is merely a value assigned to the user by the Token contract.

In contrast, the Token account assets created by Move are unique resource types. For example, the assets in Account A are stored in Account A, and although they are also values, they cannot be copied, discarded, or reused, allowing for secure storage and transfer. At the same time, account assets can only be created and destroyed by the module that defines that resource, which helps avoid issues like reentrancy, double spending, or imbalances in account balances that may arise from homogeneous numerical asset types. In this regard, Move account assets are somewhat similar to Bitcoin's UTXO mechanism, where Tokens are no longer simple homogeneous values but are distinguishable.

To enable more flexible business operations, Move also defines four permission attributes: copy, drop, store, and key. These four attributes can be combined in any way to define the properties of resources, allowing users to operate flexibly. For instance, the combination of drop + store + key defines a resource that cannot be copied, thus avoiding issues of token inflation and double spending caused by copying, similar to NFTs and Bitcoin's UTXO mechanism.

For modularity and contract composability, Move uses module and script design, enabling contract interaction through resource passing. In Solidity (like Ethereum), Contract contracts communicate through libraries (equivalent to static libraries), allowing for calls and interactions between Contract contracts. In contrast, the Move language employs modules and scripts, with the former being similar to Contract contracts, and the composability of Move contracts being a combination of modules through resource passing (i.e., the resources mentioned earlier). The differences in composability between Solidity and Move are quite evident.

In terms of transaction execution, Move's parallel processing significantly enhances blockchain performance compared to Solidity. Parallel execution (PE) identifies independent transactions and executes them simultaneously, greatly improving blockchain scalability. Solidity does not support parallel processing; transactions on Ethereum are executed sequentially, with other transactions placed in a paused (sorted) state—resulting in the creation of a mempool and MEV market. For example, the Move-based public chain Aptos utilizes the Block-STM (Software Transactional Memory) engine to achieve parallel processing, leading to significant performance improvements.

I: Core Viewpoints

Move, originating from a major company (Meta), is widely regarded positively in the industry, and some public chains developed based on the Move language have gained market favor and capital support. Why is the Ethereum ecosystem based on the Solidity language so vast, yet the market still has new expectations for new public chains? What advantages does Move have that address the shortcomings of Solidity? Based on these characteristics, the Move ecosystem may give rise to new models and applications.

This article compares the shortcomings of Solidity and EVM, analyzing the advantages and characteristics of Move.

II: Why Invent Move: What Problems Does It Address in Solidity (Ethereum)?

Move is a secure and reliable smart contract language developed by Meta (formerly Facebook) for its Diem project (initially a global stablecoin project called Libra). New public chains like Aptos and Sui use the Move programming language, which capitalizes on Move's advantages and its parallel processing characteristics to overcome the limitations of single-chain architectures. Move is based on the Rust programming language, but it is specifically optimized for smart contracts and primarily used for resource manipulation, making its entry barrier lower than that of Rust.

Since it primarily targets smart contracts, it eliminates many unnecessary operations from Rust, making it more concise. To address some shortcomings of Solidity and EVM, Move has made optimizations that allow Dapp applications based on Move to have more flexible gameplay.

In contrast to existing programming languages like Solidity, the Move language considers many design details thoughtfully, such as separating libraries from application logic; however, its most prominent feature is its resource type, which is resource-oriented programming. In terms of Dapp application support, it absorbs the advantages of Bitcoin's script and Ethereum's smart contracts, leading to a generally positive outlook on this programming language in the industry. Moreover, Move is also attempting to address the security issues that Solidity has been criticized for.

2.1. First-Class Resources and Digital Assets

Aligned with its background, Move is a resource-oriented programming language where resources are "first-class citizens." Its key feature is the custom resource type: resources can never be copied or implicitly discarded, and can only be moved between program storage locations. They can be stored in data structures like traditional types and passed as parameters.

In simple terms, it is a new data type that cannot be arbitrarily destroyed in traditional programming languages. In contrast to the assets defined in Solidity, such as a certain Token account on Ethereum, the asset is merely a value. When a transfer occurs between two accounts, the asset values change accordingly, and the distinction between different account assets is merely their numerical balance, with no essential difference (meaning the assets are homogeneous).

It is also important to note that, for example, the ERC20 token TokenA on Ethereum is an independent contract account that assigns a value to the user (account address), representing the quantity of Token A owned by the user. From this perspective, it is clear that Solidity is not resource-oriented; a user's account holds a certain Token asset, which is merely a value assigned to the user by the Token contract.

In contrast, the Token account assets created by Move are unique resource types. For example, the assets in Account A are stored in Account A, and although they are also values, they cannot be copied, discarded, or reused, allowing for secure storage and transfer. To use an imprecise analogy, the assets in Account A can be considered not entirely homogeneous compared to assets in other accounts.

Additionally, account assets can only be created and destroyed by the module that defines that resource, which helps avoid issues like reentrancy, double spending, or imbalances in account balances that may arise from homogeneous numerical asset types. In this regard, Move account assets are somewhat similar to Bitcoin's UTXO mechanism, where Tokens are no longer simple homogeneous values but are distinguishable.

To enable more flexible business operations, Move also defines four permission attributes: copy, drop, store, and key. These four attributes can be combined in any way to define the properties of resources, allowing users to operate flexibly. For instance, the combination of drop + store + key defines a resource that cannot be copied, thus avoiding issues of token inflation and double spending caused by copying, similar to NFTs and Bitcoin's UTXO mechanism.

One can understand that assets in Ethereum (Solidity) are controlled by the corresponding contracts. If we liken the Token A contract to a safe, the safe assigns a numerical balance to all users to express the quantity of Token A assets they own, but the assets themselves are still stored in the Token A contract's safe. In contrast, a Move user account itself is a separate large safe controlled by the user, where all Token assets are stored. Moreover, these Tokens do not exist in numerical form but as non-copyable resources (types) controlled by user permissions.

In the Move language, resource definitions and permissions are separate; the permissions of resources belong to the user. In Solidity, account resource permissions belong to the contract. For example, a certain ERC20 Token on Ethereum belongs to the corresponding contract. When a user exchanges Token A (whose permissions belong to the Token A contract) for Token B (whose permissions belong to the Token B contract) in a DEX like Uniswap, they cannot directly withdraw their A assets for B assets within the Uniswap contract—because the asset permissions in Uniswap belong to its contract.

The actual process involves at least three transaction operations: i) first, authorize the Uniswap contract (approve) to allow it to withdraw assets from the A contract on behalf of the user; ii) enter the Uniswap contract to exchange, withdrawing A and depositing B into the account; iii) revoke the authorization. However, users generally do not immediately revoke authorization after completing the exchange (to save gas fees for potential future exchanges). If the Uniswap contract is attacked or has vulnerabilities, it poses risks to the user's A Token account. It is important to note that both authorization and revocation require executing contract operations on Ethereum, incurring gas fees.

From this, we can clearly see that the permissions of Token A, Token B, and LP assets in Uniswap belong to their respective contracts, and users cannot freely switch between these three contracts with a single account. In contrast, Move's asset accounts do not require cross-contract authorization; permissions belong to the user, allowing users to directly withdraw A and exchange it for B in the DEX, all within a single transaction operation, without the need for authorization or revocation, thereby enhancing security to some extent.

2.2. Modularity and Flexible Composability of the Move Language

In our previous in-depth report "Web3.0 Era: Openness, Privacy, Co-construction," we pointed out that a significant difference between Web3.0 and Web2.0 lies in openness and composability. So how is this open invocation achieved at the underlying level? What conveniences does the Move language provide?

Regarding modularity and contract composability, Solidity (like Ethereum) uses libraries (equivalent to static libraries) to facilitate message passing between Contract contracts, enabling calls and interactions. In contrast, the Move language employs modules and scripts, with the former being similar to Contract contracts, and the composability of Move contracts being a combination of modules through resource passing (i.e., the resources mentioned earlier). The differences in composability between Solidity and Move are quite evident.

Taking the deployment of a Token contract as an example, a Token in Solidity exists as a service that can query balances, while a Token in Move is a resource, as mentioned earlier, "that can never be copied or implicitly discarded, and can only be moved between program storage locations." The distinction between the two can be likened to this: calls between contracts based on Solidity occur through message services, similar to trade exchanges between two primitive tribes. To facilitate interactions between the two tribes, standardized information such as production tools and methods must be unified—i.e., state synchronization between the two contracts to achieve interaction.

Tribe A invents a stone axe and informs Tribe B of the material standards and production methods for this stone axe, allowing Tribe B to produce it independently (this is akin to Token A and Token B being controlled by their respective contracts). It is important to note that for safety, contracts must remain isolated and can only pass message services, but message services can obviously be copied or discarded (erasing the stone-carved information).

If a contract undergoes an upgrade, such as Ethereum's NFT interface standards ERC 721, ERC 721A, and ERC4907 series optimizations, it is akin to Tribe A inventing iron tools, necessitating communication with the other tribe to update production configurations. Upgrading a contract requires other contracts that have called that contract to synchronize their states and follow the upgrade. This workflow undoubtedly increases complexity; the upgrade iterations of Ethereum contracts are similarly complex and can lead to EVM bytecode bloat.

In the world of Move, contract interactions exhibit greater flexibility in composability. Using the previous analogy, interactions between Move modules (i.e., trades between tribes) are achieved through resource passing. This optimization is akin to a technological upgrade; Tribe A does not inform Tribe B of the configuration information for production tools but instead packages the tools (whether stone axes or upgraded iron tools) in a suitably sized standard transport vehicle. The other party does not need to upgrade their production configurations but only needs to receive the vehicle each time.

In other words, the interactions between Move modules do not pass messages but rather directly transfer transport vehicles (which are resources that can never be copied or implicitly discarded and can only be moved between program storage locations). This model undoubtedly offers greater flexibility in composability; the receiving party can store the vehicle, transfer it to others (other contracts), or even unload the vehicle's cargo and repackage it into different vehicles. This means that when a Move module is upgraded, other contracts that have used that module automatically upgrade to the latest state.

2.3. Improvements to Web3 Security

The security improvements brought by the Move language are multifaceted.

The resources in the Move language have four attributes: copy, indexable, drop, and store. Through different combinations of these four attributes, users can easily define any type of resource. In contrast, assets in Solidity are assigned numerical balances to user accounts by token contracts, whereas Move undoubtedly enhances asset security.

In Solidity, assets are assigned numerical values by the corresponding Token contract to user accounts. In contrast, Move stipulates that resources are stored in modules controlled by their owners, who have the highest decision-making power. Only the owner can decide the storage and transfer of resources. The separation of operational permissions allows different scenarios to define different permissions, which is also a facet of security.

The design of Move resources ensures that the transfer of digital assets is not a simple addition or subtraction of balance values between accounts but rather a movement between storage locations (non-copyable, non-discardable), thereby avoiding reentrancy and double spending attacks. Reentrancy refers to hackers exploiting code vulnerabilities to create malicious contracts that call the transfer function again while the user is transferring funds (reentrancy), continuously withdrawing funds without changing the account balance. The assignment scheme of Token contracts in Solidity carries significant risks of reentrancy attacks and double spending.

Furthermore, the modular working mode of Move greatly reduces systemic risks— as mentioned earlier, upgrading Solidity contracts requires other contracts to upgrade accordingly; otherwise, security risks arise. In contrast, upgrading Move contracts is straightforward; only the relevant contract needs to upgrade without requiring updates from other contracts, thus mitigating security risks associated with untimely contract upgrades.

2.4. Move's Parallel Processing Brings Higher Scalability

In terms of transaction execution, Move's parallel processing significantly enhances blockchain scalability compared to Solidity. Parallel execution (PE) identifies independent transactions and executes them simultaneously, greatly improving blockchain scalability. Solidity does not support parallel processing; transactions on Ethereum are executed sequentially, with other transactions placed in a paused (sorted) state—resulting in the creation of a mempool and MEV market. For two unrelated transactions, if they can be processed in parallel, it is efficient and scalable.

For example, the Move-based public chain Aptos utilizes the Block-STM (Software Transactional Memory) engine to achieve parallel processing, leading to significant performance improvements. Its working principle is similar to Ethereum's Layer 2 network's Optimistic Rollup, where transactions within a block are pre-sorted, assuming there are no dependencies between transactions and optimistically executing them in parallel.

After execution, all transaction results are verified. If a transaction is found to have accessed a memory location modified by a previous transaction, that transaction is deemed invalid—because it is clear that the two transactions are related. The results of the transactions are refreshed, and then the transactions are re-executed. This process is repeated until all transactions in the block have been executed. The characteristic of Block-STM is that it supports relatively complex transactions, making it suitable for various application load conditions.

As shown in the figure below, Block-STM is compared with sequential execution of blocks. Each block contains ten thousand transactions, and the number of accounts determines the complexity of transaction competition within the block. In both low and high competition scenarios, Block-STM achieves 8-16 times acceleration compared to sequential execution. Even when transaction tasks are sequential, Block-STM consumes less. Thus, it is evident that the concurrent performance brought by Move is outstanding.

Therefore, before Layer 2 (L2) networks, the parallel processing capability of the main chain is also a positively considered solution for public chain scalability. This brings more possibilities to the Move ecosystem.

Risk Warning The realization of blockchain business models may fall short of expectations: Blockchain, cryptography, and related technologies and projects are still in their early stages of development, posing risks of business models not materializing as anticipated.

Uncertainty of regulatory policies: The actual operation of blockchain projects involves multiple financial, internet, and other regulatory policies. Currently, regulatory policies in various countries are still in the research and exploration stage, with no mature regulatory model, leading to risks associated with regulatory policy uncertainty.