Beosin security team officially announces the security audit service for Move smart contracts, aiming to discover and assist project owners to fix security risks in advance, and safeguard the assets of users and projects.

With the rise of new public blockchains like Aptos and Sui, Move has attracted more and more attention as an asset-oriented programming language, and more and more projects are written in the Move language. In this article, we will firstly discuss the features of Move language, then introduce the design of Move from the security perspective. Our next article will further deepen the understanding of Move by comparing Move with Solidity, and finally we will introduce the possible security vulnerabilities and corresponding audit items of Move projects summarized by our research team.

1. Basic Concepts

The Move language was originally designed and developed by the Facebook team as a new language for the Diem (formerly known as Libra) blockchain. Whereas Libra’s mission is to build a simple global monetary and financial infrastructure that supports billions of people, the Move language is intended to provide a secure, programmable foundation on which this vision can be built. Move must be able to express the Diem currency and governance rules in a precise, understandable and verifiable manner. In the long run, Move must be able to encode the various assets that make up the financial infrastructure and the corresponding business logic.

So, how can this vision be realized? In Move’s whitepaper, four key objectives are presented for design consideration: first-class assets, flexibility, security, and verifiability. The first-class assets are the foundation for achieving this vision. To understand first-class assets, let’s first introduce a few of the more important foundational concepts in the Move language.

1.1 Struct

Like many other languages, structures in the Move language are defined using struct. It is a custom type and the only way to create custom types in Move. Structs can contain complex data or no data at all, but recursive structs are not allowed to be defined. Structs consist of fields, which can be simply understood as “key-value” stores, where key is the name of the field and value is the stored content.

1.2 Abilities

Move’s type system is very flexible, and each type can be modified by four kinds of modifiers. These four modifiers, which we call abilities, have the following functions.

• Copy — The modified value can be copied.
• Drop — The modified value can be dropped at the end of the scope.
• Key — The modified value can be accessed as a key to the global state.
• Store — The modified value can be stored to the global state.

While Move’s basic types have store, copy and drop constraints by default, custom types have no constraints on structures by default.

1.3 Resources

After introducing structs and abilities, the next is the core concept in the Move language: resource.

If structs defined that cannot be copied or dropped, we call them resources. By default, structs are linear and ephemeral. They cannot be copied, they cannot be dropped, and they cannot be stored in global storage. This means that all values must have ownership of being transferred, and the values must be disposed of at the end of program execution. We can simplify this behavior by giving structs abilities that allow values to be copied or deleted, as well as stored in global storage or define patterns for global storage.

This property in the Move language is useful for modeling real-world resources (e.g., currency), since currency is theoretically not expected to be copied or dropped during circulation.

1.4 Module

In the Move language, code is organized in modules. How do we understand modules? In abstract terms, the module/resource/function interaction in Move is very similar to the class/object/function relationship in traditional object-oriented languages.

In contrast to other blockchain languages, the modules in Move are similar to smart contracts in other blockchains. The developer declares resource types and functions in the module, which define the rules for creating, burning and updating the declared resources.

1.5 Generic

Move has chosen the paradigm of generic programming in order to ensure scalability because it is a static language.

Using Aptos as an example, just look at the asset you hold as 0x1::coin::CoinStore<? > such a type, you can tell that the asset is defined by the standard module 0x1::coin. For example, Aptos’s native token AptosCoin is of type 0x1::aptos_coin::AptosCoin, meaning the type AptosCoin as defined by the aptos_coin module under the 0x1 account, but this type is not given key capability so it cannot be a resource, it only provides a type to be used as a generic, like by 0x1::coin::CoinStore.

Then 0x1::coin::CoinStore<0x1::aptos_coin::AptosCoin> is the CoinStore type defined by the coin module under the 0x1 account, which records the asset status of a certain coin under the address. So any 0x1::coin::CoinStore<?> assets under your address share the same logic and behavior, and are all defined in the 0x1::coin module.

2. Security

2.1 Design Security

Move makes it clear in the whitepaper that Move must reject programs that do not satisfy key properties, such as Resource safety, type safety, and memory safety. How do we choose an executable representation that ensures that every program executed on the blockchain satisfies these properties? Two possible approaches are.

(a) use a high-level programming language with a compiler that checks for these properties.

(b) use a low-level untyped assembly and perform these security checks at runtime.

Move takes an approach between these two extremes. Move’s executable format is a typed bytecode, which is higher-level than assembly but lower-level than the source language. Bytecode is checked for Resource, type, and memory safety by a bytecode verifier on the chain, and then executed directly by the bytecode interpreter. This option allows Move to provide the security guarantees normally associated with the source language, but without adding the source compiler to a trusted compute library or adding compilation costs to the critical path of transaction execution.

In addition, Move has many security features built into its design, such as arithmetic overflow, permission leakage due to default visibility, etc.

2.2 Underlying Security

2.2.1 Resources

In the real world, assets have two attributes that are difficult to express numerically.

1) Scarcity. The number of assets issued in the system must be controlled. Copying existing assets must be prohibited, and creating new assets is a privileged operation.

2) Access control. System participants must be able to protect assets using access control policies.

Therefore, Move introduces resources to represent assets. In a blockchain application, a token is a resource, which must be stored under an account, and during a transaction, the asset must flow to one place, either transferred to another address or burned, and the token cannot be copied, used multiple times or “dangled”. The operation of resources can be likened to a unique pointer in C++.

2.2.2 Byte Verification Before Contract Execution

Move was designed to be an executable bytecode language with built-in security algorithms and a Bytecode verifier that protects against many common errors. In his “Smart Contract Development — Move vs. Rust”, Krešimir Klas states that the distinguishing feature of Move is the executable bytecode representation that provides all programs with resource security guarantees for all programs. This is critical given the open deployment model of contracts — recall that any contract must tolerate arbitrary interactions with untrustworthy code. If source-level linearity can be violated by untrusted code at the executable level, then its value is limited.

2.2.3 Static Call

In blockchain, the way contracts are invoked can be divided into static and dynamic invocations. If the target of a program call must be determined at runtime, the call is called a dynamic call; conversely, if the target of the call can be determined before runtime and cannot be changed at runtime, the call is called a static call.

Move uses the static invocation method. That is, the execution logic of the contract implemented by Move is already determined at the time of deployment. Then we can statically analyze the bytecode to get the status of operations on all possible paths of the contract and prompt the user in the block browser or wallet.

Therefore, the wallet provider can design the wallet to prompt the user with the change in status of the contract after execution when pre-executing the contract, so that the user can know which of their important assets were operated by this transaction, and the result after execution. The following diagram shows the effect of the implementation in StarMask.

Source: jolestar.eth

3. Move Audit Service & Audit Categories

Beosin security team has officially launched the security audit service for Move smart contracts, which includes the following security audit items.

- Overflow vulnerability

- Replay attack

- Insecure random numbers

- Transaction-ordering dependency

- Denial of Service

- Access control

- Improper permissions

- Variable override

- Business design

- Business implementation

- Manipulable token prices

- Arbitrage attacks

- Gas optimization

- Third party module security

- Ability Security

- Resource Security

- Upgrade Security

- Centralization risk

References

https://developers.diem.com/docs/technical-papers/move-paper/

https://mirror.xyz/asmp.eth/xUzqdBXewRPhLKLAYekiwU5S9uFiTnJ3f56KbkcOz-M

https://mirror.xyz/jolestar.eth/sQ0nMCO3eNig6gCzqQO7xew1mn8oUi1-rKtfZKmGlNI

https://medium.com/@kklas/smart-contract-development-move-vs-rust-4d8f84754a8f

Contact

If you have need any blockchain security services, please contact us:

Website Email Official Twitter Alert Telegram LinkedIn