Abstract
After Solidity and Rust, Move, a new generation of programming language that was born from the debris of Libra, has been brought back into the spotlight by Aptos and Sui. Throughout the history of blockchain development, the rise of each L1 chain often implies a certain degree of development paradigm change. The return of Move seems to be suggesting that new languages are becoming a new battleground for competition in the L1 chain landscape.
The Ethereum programming language, Solidity, has witnessed a number of alarming security incidents. In 2021 alone, there were over 200 publicized security incidents in the blockchain ecosystem with losses of over US$9.8 billion; the vast majority of security issues are caused by vulnerabilities in smart contracts. Since Libra's vision is to become the financial infrastructure for a global currency system, Move must place asset security at the forefront of its design goals.
To better implement asset security, Move has made innovative changes on three levels: language design, virtual machine and verification tools. First, Move defines a new Resource type for digital assets and abstracts two basic properties: resources should satisfy both scarcity and access control. Second, Move implements account permission control through a Module system with strong data abstraction. Third, Move inherits Rust's Ownership system to achieve the transfer of asset ownership. In addition, the introduction of mechanisms such as static invocation, formal verification, and bytecode checker also jointly provide multiple guarantees for the security of digital assets.
In terms of language acceptance, Move is very developer-friendly, and its purpose is to lower the security threshold for developers so that contract developers can focus on business logic. It is easy to get started, and the overall developer migration cost is not high. From the ecosystem perspective, the actual application scenario of Move is still in the early stage, and the application ecosystem has not yet developed on a large scale. At present, the only L1 chain projects incubated with Move are Aptos, Sui and Starcoin in Mainland China. In the future, Move's financial characteristics and maturity will cultivate the first batch of financial infrastructures such as DEX, DeFi and wallet, followed by financial-related applications such as Socialfi and Gamefi.
Table of Contents
1. The Birth of Move 1
2. How Move Secures Assets 4
2.1 Language Design: Made for Digital Finance 4
2.2 Virtual Machine: Runtime Bytecode Verifier 11
2.3 Off-chain Tools: Formal Verification 15
3. Summary and Outlook 17
References 19
Overview
The L1 chain segment has been abnormally active of late: two new L1 chains, Aptos and Sui, have received mass attention from the market as they raised nearly half a billion dollars despite overall bearish market conditions. Apart from the fact that most of the founding team are experts coming from the now defunct stablecoin, Libra (later renamed Diem), current success has been more largely attributed to the inheritance from Diem’s legacy core - the Move language.
Some degree of development paradigm shift is spotted with each L1 chain rise. Currently, the L1 chains from the Diem family, led by Move, seem to be suggesting that the narrative of new programming languages has become one of the battlegrounds for L1 chain competition.
1. The Birth of Move
With so many coding languages available, why did Libra "go the extra mile" to design Move? We know that Libra's vision is to be the financial infrastructure for a global currency that benefits billions of people. With this in mind, Move had to put asset security at the forefront of its design goals. However, past programming languages did not meet this requirement very well.
According to incomplete statistics from SlowMist Hacked data, more than 200 cases of security incidents have been publicized in the blockchain ecosystem in 2021 alone with losses of more than US$9.8 billion. Among them, the vast majority of security issues appear in the DApp or DeFi protocols.
Figure 1: Overview of blockchain security issues
Resource: SlowMist Hacked
Furthermore, DApp incidents can be divided into front-end incidents, back-end incidents and contract incidents. Front-end incidents are mainly caused by security vulnerabilities in the client side of DApps involving traditional information technology, resulting in the theft of users' account information, personal information, etc., leading to crypto asset loss; whereas back-end incidents usually involve a security breach on the server side of a DApp, leading to the hijacking of the DApp's back-end service and on-chain interaction, resulting in the theft or loss of the user's crypto assets. Contract incidents are usually caused by the loss of assets due to the vulnerability of the smart contract’s protocol. Most security incidents involving on-chain protocols are contract security incidents.
Figure 2: DApp related incidents
Resource: Fairyproof
Typical contract security attacks include attacks on flash loans, reentrancy attacks, double-spend attacks, overflow, transaction replay, fake receipt, etc.: These all reflect that the older generation programming languages represented by Solidity have more or less security risks in terms of language features, contract operation and virtual machine design.
Table1: Smart contract vulnerability causes
Resource: WeStar
Therefore, Libra decided to abandon the old smart contract programming language and developed the more secure Move language. This article will also focus on the security features of Move.
2. How Move Secures Assets
Move outperforms previous programming languages in terms of asset security, in large part because it has made progress in three main areas its predecessors were deficient in: language design, virtual machines, and off-chain verification tools.
2.1 Language Design: Made for Digital Finance
Move is gradually weakening the "digital" attribute and emphasizing the "asset" attribute in digital finance. Why is this happening? Let's look at how the Turing-complete smart contract language is in place to define digital assets.
As we know, Ethereum adopts an account model, which itself is a huge transaction state machine: each transaction changes the state of the Ethereum blockchain, which is also packaged in blocks. So, Ethereum can be deemed as a chain of accounts formed by transactions packed in blocks on the one hand, and on the other hand, as a state machine that constantly leaps from one state of the blockchain to another as blocks are created.
Furthermore, the sum of information for each account is composed of the state of the blockchain at each moment. At the same time, for each account, it is a mapping from the address to the account state. As an example, when you open your wallet, each bank card corresponds to a bank account. The card number of the bank card is equivalent to the address of the account, and the account information, including fund balance, consumption details, and position of financial products stored in the card number are status of the account. Each card corresponds to a status at a certain point in time. The collection of all your bank cards corresponds to your overall financial state. As you use your bank card to make transactions or purchases, the state of your bank card changes and your financial state also correspondingly changes.
This mapping relationship is mainly represented by the balance in the key strings in an Ethereum account. Intuitively, this is a typical KV key-value pair (mapping (address => uint256) public balances), with Value embodied as Token balance of the account. So, the account balance is represented in Solidity by an integer numeric variable (uint), and the process of transferring tokens between different accounts is operated by numeric addition and subtraction.
Figure 3: Ethereum blockchain structure diagram
Source: Ethereum.org
The following is an ERC20 transfer logic realized by Solidity, where the "from user" (sender) transfers a Value (number of tokens) to "to user" (receiver) with the following main process:
Figure 4: Example of a simple transfer contract
Source: Starcoin
i. Mapping the initial balance from the sender address (from) to the oldFromVal variable.
ii. Requiring oldFromVal to be greater than value, i.e., the sender balance is sufficient.
iii. The initial balance is derived from the mapping of the receiver address (to) and assigned to the oldToVal variable.
iv. Using oldToVal plus value and assigns it to newToVal.
v. Using oldFromVal minus value and assigns it to newFromVal.
vi. Setting the newFromVal to the new balance of the sender address (from).
vii. Setting newToVal to the new balance of the recipient (to).
In a simple example, Alice transfers $10 to Bob, calling the smart contract to subtract $10 from Alice's account address and add $10 to Bob's address. The whole process of modifying the balance is a common debit logic in centralized financial scenarios.
However, the on-chain world is quite a different story. For example, will there be a situation where Bob's balance increases by 10, but Alice's balance does not change? The answer is yes. We know that on-chain actions mostly rely on smart contracts, which are automatically executed according to preset rules. Back to the example above, if the from and to addresses are the same, that is equivalent to sending a token to itself. According to the order of code execution, although the transfer value is first subtracted from the sender address, the value of newToVal is later overwritten with the value of newFromVal, resulting in that the balance of that account keeps increasing, but there is no subtraction. This is what we often call the token infinite increment vulnerability.
From this example, it is evident that the transaction between users is completed by executing the coded program, which is ultimately reflected in updates of numbers under the address. The reliability depends on the developers, and no guarantees are made on possible errors caused by human bias. In all, Solidity is a language for blockchain smart contracts, which is not an asset-oriented language. Digital assets are merely numbers that can be added or subtracted in Solidity, but has no definition of class; whereas numbers are incapable of expressing the class of assets.
a) First-class Resource - Enabling Assets Digitalization
To solve the problem above, Move has defined a new data class First-class Resource for digital assets, which literally translates to that Resource being a first-class citizen: In coding, a first-class citizen receives priority to be considered, and a resource is anything that is limited in number but can potentially produce values. Move follows this concept and abstracts two constraints for resources to be programmed, namely scarcity and access control.
Scarcity
Scarcity is an important property of valuable physical assets, such as a gold bar in the real world, which does not change in number from one to two or suddenly disappear, no matter how many times it changes hands; however, digital assets do not possess this inherent physical scarcity. Therefore, Move believes that digital asset computation rules must be programmed to enforce this scarcity. It specifies that the supply of assets in the system should be limited, assets should not vanish, copying existing assets should be prohibited, and creating new assets should be a privileged operation. The programming approach mentioned here refers to the syntactic structure Ability defined by Move. It contains four attributes abstracted by Move for various variables, copy, key, drop, and store; developers can use these strings in combination with each other to enable different capabilities of variables. Notably, once the variable is declared as a Resource, it is only editable with Key and Store, and invalid with Copy and Drop. In this way, Move ensures the scarcity of resource class from the programming syntax structure.
Access Control
Owners of assets should be able to protect their assets with an access control strategy. As we know, Ethereum mainly relies on the public key signature mechanism, and Move provides a new Module system on top of that, which we will elaborate on later.
Move encapsulates the definition of assets on the underlying logic using Resource, transforming digital assets to real contract variables that can not only be stored and assigned, but also participate as parameters and return values of functions/procedures. The Ability structure also syntactically reflects Move's mandatory rules for Resource variables, ensuring that assets cannot disappear or be copied arbitrarily, which is efficient in minimizing security risks such as the above-mentioned infinite increment vulnerability.
b) Module – Realizing Access Control and Composability
Module, similar to Mod in Rust and Contract in Solidity, is capable of declaring a series of data classes and functions, including Resource, Struct, and Function. Both Struct and Resource are adopted to define new data structure types, Resource differs somewhat as it cannot be copied and discarded. Function is similar to most other languages, and adopted in place to create, destroy and update the types of declaration in Module. As a whole, Module has the following characteristics.
Figure 5: Test Module Example
Source: Huobi Research
Strong Data Abstraction
A Module is a strong data abstraction because it specifies that data classes are transparent inside the declared Module and opaque outside; each Resource object is encapsulated in a specific Module, controlled and updated by the owner's account, with functions provided externally to create, modify and destroy assets according to a detailed command. As mentioned above, this feature is also effective in controlling access to Move, which is impossible for entities outside of the Module to operate directly on the internal Resource; they must follow certain given functions and conduct only limited actions on Resource. This is reflected in the code, where external developers can only call Public functions in the Module and operate according to the module's internal definition, avoiding the security risks associated with accidental calls.
Flexibility and Statelessness
Module preserves a public socket of modules for external sources to enable inter-contract combination and resource utilization, which barely differs from the Interface Standard of Solidity in terms of functionality. The only minimal difference is that the modules in Move are stateless and the state is stored in the global status. Specifically, issuing ERC-20 tokens in Solidity is more akin to keeping a ledger, which records the complete data of each user's interaction with the contract through the state change of the ledger; On the other hand, Move encapsulates the assets through Modules and stores them under the account address in a distributed manner, which is more like a labeled but independent safe.
c) Ownership System - Realizing Asset Ownership
This concept is inherited from Rust, which defines ownership in the following:
1. Each value has a corresponding variable called the owner.
2. The value has one and only one owner at any given moment.
3. When the owner leaves the scope, the value will be discarded.
Simply, a value can only have a sole owner; in this case, the owner could be a function. When a value is passed to a new function, the new function becomes the new owner, where passing a value to a function is semantically similar to assigning a value to a variable.
How does this feature manifest itself in Move? First of all, all Resource must be stored under an account – that is to say, Resource can only be generated after an account is allocated. Second, each Resource must be labeled as "used" as soon as it is extracted from the account: when the asset is taken out of the account by the built-in Move_from command, it is either circulating as a returned value, flowing to a new account, or would be destroyed. Anything “out-of-pocket” would be labeled “used” regardless of how much was withdrawn from the account. This is a good elaboration of the inherence of a transaction: to transfer ownership.
With a retrospective view of Resource's properties, although Resource transactions between users are still based on addition, subtraction and indexing accordingly to the size of the asset value, there is a distinct difference from that in Solidity. The latter executes coding logic by force to reduce the balance of one and add to the other, while the transfer process of Resource is more like moving bricks: moving unique resources from one account to another, with no loss or duplication during the transfer for better asset security.
Overall, Move clarifies data ownership through the concept of linear class, emphasizing resource scarcity, protection and access control. It also adopts a modular system to define the lifecycle, storage and access patterns of each Resource. Together, these features ensure that digital assets are not created out of thin air or discarded implicitly, reducing vulnerabilities from security issues such as double-spending and infinite increments.
2.2 Virtual Machine: Runtime Bytecode Verifier – Tracing Bugs at Execution
The preceding section describes the language design features of Move that enable developers to write smart contracts for specific needs. However, both Move and Solidity are advanced programming languages. Computers do not directly read and execute these source codes; contracts are implemented with a reliance on specific executors.
Currently, virtual machines are one of the mainstream implementation methods of smart contracts and are also applicable to Move. They provide a completely transparent execution environment to underlying logic for programs, and are designed to be "write once, run everywhere". The latter contrasts with having developers write different versions of the program to be compatible with different servers. The rationale for this design is that smart contracts run in a distributed systematic environment that requires Byzantine fault tolerance to reach consensus, and all nodes must produce the same computation result following the rules preset in the smart contract. Otherwise, the result of contract execution cannot be consented by each node. However, virtual machines can disregard the difference between execution environments on blockchain nodes so that everything on nodes is consistent with the rest, ensuring the certainty of the contract.
Move VM is a typical stack-based bytecode interpreter, where the input is bytecode. With the current state of the world added, the output is the change to the state of the world. It has a separate set of internal instructions to execute and cope with all state changes of the system; users could locate the meaning of the command counterpart in the bytecode cross-reference table provided by Move.
Figure 6: Move bytecode cross-reference table
Source: Move Whitepaper
Workflow
The specific workflow of the Move virtual machine is as follows. First, the source code is turned into elementary bytecode by the compiler and passed to the virtual machine. After receiving the bytecode, the virtual machine has to first call the bytecode verifier for verification, which distinguishes various types of errors from Move source code. Finally, the virtual machine interpreter articulates and executes the script in order, traversing data or bytecode from left to right. The runtime is based on the stack execution, pressing the data into the stack when it encounters data, popping the data of the corresponding data when it encounters bytecode, calculating based on bytecodes, and then pressing the calculation result back into the stack after calculation until it exits.
Figure 7: Move Virtual Machine Workflow
Source: Move whitepaper
The main types of errors that may occur in this process of source code screening include:
i. Out-of-bounds check of stack is the process of checking the range of each function accessing the operand stack and whether the stack height is legal. In this case, the stack is specified as an instruction block (basic block) of each bytecode created by the bytecode verifier.
ii. Type & Kind check is to check if the specific type of the variable within the derived stack is correct. For instance, the stack class cannot use CopyLoc bytecode for variables of type Resource, which is a direct reflection of asset scarcity.
iii. Reference check is to prevent dangling references; each reference must point to the allocated storage location.
EVM and Move VM
The EVM is an isolated and ascertainable sandbox environment created by on-chain nodes for smart contracts, where multiple contract programs are running in different virtual machine sandboxes within the same process. In other words, inter-contract calls on Ethereum are calls between VMs within the same process, and security relies on the isolation between VMs.
Figure 8: Schematic diagram of EVM
Source: https://jolestar.com/why-move-1/
The Move virtual machine, on the other hand, supports parallel execution. Calls between contracts are centrally placed in a sandbox, and under this setting, the security of the contract state is isolated mainly by the internal security settings of the programming language, rather than relying on the virtual machine for isolation.
Figure 9: Move VM diagram
Source: https://jolestar.com/why-move-1/
2.3 Off-chain Tools: Formal Verification - Detecting Vulnerabilities before Execution
Ideally, Move would be able to discover security vulnerabilities in contract runtime by running bytecode checks. However, such on-chain verification is expensive in computation; moreover, it consumes overwhelming network resources, dragging the on-chain TPS. Therefore, Move proposed a strategy of only performing lightweight on-chain verification of critical security properties and relying on off-chain static verification tools for other security issues. Based on this strategy, Move developed the proprietary Move Prover formal verifier to prevent human editing errors, thus improving the security level of the code.
Formal verification is the process of verifying the reliability of a program by some formal specification or property, usually based on mathematical models. The process follows strict logical reasoning to obtain precise results, proving the contract is bug-free before it is officially deployed.
Speaking of Move Prover, Move has established a set of standardized language, the Move specification language, which describes how a program is considered to run correctly through preconditions, post conditions, invariants, etc. The Move boogie compiler then converts the Move program specification into a boogie program. Boogie is a formal verification intermediate language developed by Microsoft to build program verifiers for other languages, as the tool synthesizes verification conditions and passing to a solver. Finally, the results given by the solver serve to verify whether the program conforms to the specification; if not, a specific solution path will be provided.
Figure 10: Move formal verification process
Source: Move whitepaper
Static Call
It is worth mentioning that Move Prover is a static verification tool, this is because Move is designed by a mechanism not to support dynamic calls at all. A dynamic call is a contractual call that takes place when a program calls another program in such a way that the target being called can only be determined at runtime. Mechanically, it is somewhat similar to a remote call from a server. However, dynamic invocation raises concurrency issues during circular invocations. For example, if contract A calls contract B, and contract B calls contract A, the second execution is performed when the previous execution of contract A is incomplete. As a result, the subsequent execution cannot read the previous intermediate state, which eventually leads to security vulnerabilities. The infamous accident of The DAO was triggered by the problem of dynamic contract invocation. Therefore, in the Move design, each function call is static: the developer is well aware of the order in which functions are called before the program runs. This static system is better suited to reasoning through formal verification, front-loading the exposure of problems to the compilation stage to reduce the possibility of bugs at runtime, and relieving the pressure of security checks right on.
3. Summary and Outlook
If the diffusion process from Bitcoin Script to Ethereum Solidity is considered a revolution in contract expression capability, the transition from Solidity to Move would be an evolution in contract security capability. Accordingly, market expectations of Move are also higher.
In terms of language mechanism, the direction of Move's exploration of asset security is encouraging. Innovative changes are seen at three levels: language design, virtual machine and verification tools, which are integrated as an organic whole. The asset-oriented programming design holds up the Move language as a natural fit for decentralized financial applications to deploy; features such as linear logic, access control, static invocation, and formal verification serve as multiple layers of security for digital assets.
In terms of language acceptance, Move is rather developer-friendly: it aims to lower the security threshold for developers so that contract developers can focus on business logic. At the same time, Move evolved from Rust and Solidity, discarding unnecessary "rot" from both designs, which embodied low complexity. Therefore, the overall migration cost is not high for developers. According to Move practitioners, for developers with experience in Rust and Solidity programming, it only takes 1-2 days to get up to speed with Move. For developers without experience in smart contract programming, it only takes 1-2 weeks to learn Move from scratch.
From the ecosystem point of view, the actual application scenario of Move is still at an early stage, and the application ecosystem is not yet widespread. Apart from Libra, which has already been renounced, the only L1 chain projects incubated with Move are Aptos, Sui and China's StarCoin. Aptos and Sui are both at the test network stage, and both have explored different directions based on Move: Sui has introduced an immutable state and tried to implement a UTXO-like programming model in Move, while Aptos is exploring parallel execution of transactions on Layer1 and better performance. Starcoin, whose main network was launched in May 2021, is exploring layered scaling models on Layer2, and even Layer3. As these projects move forward, we expect to see more niche projects in their respective ecosystems. Due to the nature of Move for the sake of finance, it is foreseeable that the first batch of projects will still fall within the scope of financial infrastructures such as DEX, DeFi and wallets. As the infrastructure strengthens with the support of vast development, more finance-related segments, such as Socialfi and Gamefi, will be introduced into the ecosystem.
The superstar in the current wave of the new L1 chain narrative is undoubtedly Move. Can it take advantage of the momentum? Let’s look forward to the future performance of Move.
References
1. https://diem-developers-components.netlify.app/papers/diem-move-a-language-with-programmable-resources/2020-05-26.pdf
2. https://move-book.com/cn/index.html
3. https://move-dao.github.io/move-book-zh/modules-and-scripts.html
4. https://jolestar.com/why-move-1/
5. https://mirror.xyz/0xbuidlerdao.eth/MePeSGYe63OX8xXb8IwIrXzGk_S606NG7SR879XMXRE
6. https://mp.weixin.qq.com/s/bSS9GAcVp6tuWjedpTysQw
7. https://starcoin.org/zh/developers/others/starcoin_ecology/
8. https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/design/virtual_machine/evm.html
9. https://doc.rust-lang.org/book/
10. https://solidity-cn.readthedocs.io/zh/develop/
About Huobi Research Institute
Huobi Blockchain Application Research Institute (referred to as "Huobi Research Institute") was established in April 2016. Since March 2018, it has been committed to comprehensively expanding the research and exploration of various fields of blockchain. As the research object, the research goal is to accelerate the research and development of blockchain technology, promote the application of blockchain industry, and promote the ecological optimization of the blockchain industry. The main research content includes industry trends, technology paths, application innovations in the blockchain field, Model exploration, etc. Based on the principles of public welfare, rigor and innovation, Huobi Research Institute will carry out extensive and in-depth cooperation with governments, enterprises, universities and other institutions through various forms to build a research platform covering the complete industrial chain of the blockchain. Industry professionals provide a solid theoretical basis and trend judgments to promote the healthy and sustainable development of the entire blockchain industry.
contact us:
Website: http://research.huobi.com
Email: research@huobi.com
Twitter https://twitter.com/Huobi_Research
Telegram: https://t.me/HuobiResearchOfficial
Medium： https://medium.com/huobi-research
Disclaimer
1. The author of this report and his organization do not have any relationship that affects the objectivity, independence, and fairness of the report with other third parties involved in this report.
2. The information and data cited in this report are from compliance channels. The sources of the information and data are considered reliable by the author, and necessary verifications have been made for their authenticity, accuracy and completeness, but the author makes no guarantee for their authenticity, accuracy or completeness.
3. The content of the report is for reference only, and the facts and opinions in the report do not constitute business, investment and other related recommendations. The author does not assume any responsibility for the losses caused by the use of the contents of this report, unless clearly stipulated by laws and regulations. Readers should not only make business and investment decisions based on this report, nor should they lose their ability to make independent judgments based on this report.
4. The information, opinions and inferences contained in this report only reflect the judgments of the researchers on the date of finalizing this report. In the future, based on industry changes and data and information updates, there is the possibility of updates of opinions and judgments.
5. The copyright of this report is only owned by Huobi Blockchain Research Institute. If you need to quote the content of this report, please indicate the source. If you need a large amount of reference, please inform in advance (see "About Huobi Blockchain Research Institute" for contact information) and use it within the allowed scope. Under no circumstances shall this report be quoted, deleted or modified contrary to the original intent.
