Summary
first level title
Following the Solidity and Rust languages, Move, a new generation of programming language conceived from the collapsed project Libra, has returned to the spotlight due to the public chain projects Aptos and Sui. Throughout the development history of the blockchain, the rise of each batch of emerging public chains often means a change in the development paradigm to a certain extent. The reappearance of Move seems to imply that the narrative of the new language is becoming a new battlefield for public chain competition.
In order to better realize asset security, Move has made innovative changes in language design, virtual machine and verification tools: Move defines a new Resource type for digital assets, and abstracts two basic attributes that resources should meet. Scarcity and access rights; through the module system of strong data abstraction, the authority control of accounts is realized; the transfer of asset ownership is realized by inheriting Rust's Ownership system. In addition, the introduction of mechanisms such as static calls, formal verification, and bytecode verifiers also jointly provide multiple guarantees for the security of digital assets.
From the perspective of language acceptance, Move is very friendly to developers. Its purpose is to lower the security threshold for developers, so that contract developers can focus on business logic, easy to get started, and the overall cost of developer migration is not high; ecologically Look, the actual application scenarios of Move are still in the early stage, and the application ecology has not yet been rolled out on a large scale. At present, only Aptos, Sui and domestic Starcoin are the only public chain projects incubated by Move. In the future, due to factors such as the characteristics of Move for finance and the maturity of the track, financial infrastructure such as DEX, DeFi, and wallets will be implemented first, followed by financial-related applications such as Socialfi and Gamefi.
overview
first level title
Recently, the public chain track has been extremely active: two new public chains, Aptos and Sui, which have bucked the market and raised nearly US$500 million in financing, have attracted widespread attention in the industry. To say why they have such a great ability, apart from the fact that most of the founding team comes from the deep background of the defunct stablecoin project Libra (later renamed Diem), it is more likely that they have inherited the core legacy from Diem. ——Move language.
In the past few years, every wave of new public chains in the blockchain field has included a certain degree of development paradigm shift. Now, the Diem public chain headed by Move seems to be hinting that the narrative of the new programming language has become one of the battlefields of public chain competition.
first level title
1. The reason why Move was born
There are so many languages in the world, why does Libra design Move "overwhelmingly"? We know that Libra's vision is to become the financial infrastructure of a global currency, empowering billions of people. Therefore, Move must put asset security at the top of its design goals. However, programming languages of the past did not meet this requirement very well.
According to incomplete statistics from SlowMist Hacked, in 2021 alone, there will be more than 200 publicized security incidents in the blockchain ecosystem, with losses exceeding US$9.8 billion. Among them, the vast majority of security issues appear in ecological DApp or DeFi protocols.
Typical contract security attacks include flash loans, re-entry attacks, double-spending attacks, numerical overflows, transaction replays, transaction receipts, etc. They all reflect that the older generation of programming languages represented by Solidity have more or less security risks in terms of language features, contract operation, and virtual machine design.
Therefore, Libra resolutely abandoned the old smart contract programming language and developed a more secure Move language. This article will also mainly explain the various security features of Move.
2. How does Move ensure asset security
Move’s performance in asset security is superior to previous programming languages, largely because it has made innovative improvements on the shoulders of its predecessors. These improvements are mainly reflected in three aspects, namely, language design, Virtual machines and off-chain verification tools.
secondary title
2.1 Language Design: Born for Digital Finance
Move is gradually weakening the "digital" attribute and emphasizing the "asset" attribute. Why do you say that? Let’s first take a look at how Turing’s complete smart contract language defined digital assets in the past.
We know that Ethereum uses an account model, which itself is a huge transaction state machine. Every transaction will change the world state of Ethereum, and transactions are packaged in blocks. Therefore, on the one hand, Ethereum can be regarded as a ledger chain formed by transactions packaged into blocks. On the other hand, it can also be regarded as a continuous transition from one world state to another with the generation of blocks. state of the state machine.
Further, the sum of the information of each account constitutes the state of the world at each moment. At the same time, for each account, it is a mapping from address to account status. This expression may be more abstract, we can understand it in such a popular way. Open your wallet, and each of your bank cards corresponds to a bank account. The card number of the bank card is equivalent to the address of the account, and the fund balance, consumption details, wealth management product holdings, etc. in the card number are all the status of the account. So each card corresponds to a state at a certain point in time. The collection of all your bank cards corresponds to the world state of your funds. As you use your bank card for transactions and consumption, the status of your bank card will change, and the world status of your funds will also change.
This mapping relationship is mainly reflected by the balance in the key field of the Ethereum account. Intuitively, this is a typical KV key-value pair (mapping (address => uint256) public balances), and the Value is reflected in some kind of Token balance of the account. Therefore, Token is represented by an integer value variable (uint) in Solidity, and the transfer process of tokens between different accounts is operated by digital addition and subtraction.
The following is an ERC20 transfer logic implemented using Solidity. The "from user" (that is, the sender transfers the value of tokens to the "to user" (receiver). The main process is:
i. Map the initial balance balance from the sender address (from) and assign it to the oldFromVal variable;
ii. Require oldFromVal to be greater than value, that is, the sender has sufficient balance;
iii. Map the initial balance from the receiver address (to) and assign it to the oldToVal variable
iv. Assign oldToVal + value to newToVal;
v. Assign oldFromVal — value to newFromVal;
vi. Set newFromVal to the new balance of the sender address (from);
vii. Set newToVal as the receiver's (to) new balance;
To simplify it with a common example, Alice transfers 10 yuan to Bob, calls the smart contract to subtract 10 from Alice's account address, and adds 10 to Bob's address. The entire process of modifying the balance is a common deduction logic in centralized financial scenarios.
However, the on-chain world is different. For example, will there be a situation where Bob's balance has increased by 10, but Alice's balance has not changed? The answer is yes. We know that most of the on-chain behaviors rely on smart contracts, and smart contracts are automatically executed according to pre-set rules. Going back to the above example, if the from and to addresses are the same, that is, when sending tokens to yourself. According to the sequence of code execution, although the transfer value is first subtracted from the sender's address, the value of newToVal is overwritten with the value of newFromVal later, resulting in the effect that the balance of the account has been increasing, but no deduction has been made. This has led to a loophole in the unlimited issuance of tokens.
From this example, it can be seen that the transaction process between users is implemented by relying on the logic of the contract code, which is finally reflected in the corresponding number update under the address. Its reliability depends on the developer of the contract, and it is difficult to guarantee that some human errors will not occur. In the final analysis, Solidity is a language for blockchain smart contracts, not an asset-oriented language. Digital assets in Solidity are simply numbers that can be added and subtracted without type definition; and the expressiveness of numbers is not enough, and assets should be differentiated.
a) First-class Resource — — realize digital assets
To solve the above problems, Move specifically defines a new data type First-class Resource for digital assets, literally translated as resources are first-class citizens. The meaning of first-class citizens is easy to understand, that is, programming languages should take first-class citizens as the first-class objects to be programmed; as for resources, in short, they are resources that are limited in number and can generate value. Move follows this idea and abstracts two constraints that resources should follow when programming, namely scarcity and access rights.
●Scarcity
Scarcity is an important attribute of valuable physical assets, such as gold bars in the physical world, no matter how many times they have been circulated in the middle, this gold bar will not change from 1 to 2, nor will it disappear suddenly; but digital assets do not There is no inherent physical scarcity. Therefore, Move believes that digital asset calculation rules must programmatically enforce this scarcity. It stipulates that the supply of assets in the system must be limited, assets cannot disappear out of thin air, copying existing assets should be prohibited, and creating new assets should be a privileged operation. The programming method mentioned here refers to the grammatical structure Ability defined by Move. It contains 4 attributes that Move abstracts for various variables, which can be copied (copy), indexed (key), discarded (drop), and stored (store). Developers can use these fields in combination to give variables different Ability. It should be noted that once the variable is declared as a Resource type, it can only use the Key and Store attributes, and cannot be added to Copy and Drop. In this way, Move guarantees the scarcity of resource types from the programming syntax structure;
● Access rights
Asset owners should be able to protect their assets through some kind of access control policy. We know that Ethereum mainly relies on the public key signature mechanism, and Move provides a new Module system on this basis. We will explain the Module in detail later, so let’s not show it here.
In general, Move uses Resource to encapsulate the concept of assets from the bottom layer, making digital assets truly become contract variables, which can not only be stored and assigned, but also used as parameters and return values of functions/procedures; The above reflects the mandatory rules that Move has made on Resource variables, which ensures that assets cannot disappear out of thin air, nor can they be copied arbitrarily, which well avoids security risks such as the above-mentioned infinite copy and additional issuance loopholes.
b) Module — — implements permission control and composability
Module is a module, which is similar to Mod in Rust and Contract in Solitidy. It can declare a series of data types and functions inside, including Resource, Struct, and Function; both Struct and Resource are used to define new data structure types. The difference is that Resource cannot be copied and discarded; as for the Function function, it is similar to most other languages and can be used to create, destroy and update the types declared in the Module. Overall, Module has the following characteristics:
●Strong data abstraction
The reason why Module is a strong data abstraction is because it stipulates that the data type is transparent inside the declared Module and opaque outside, and each Resource object is encapsulated in a specific Module, which is determined by all Control and update the account of the owner, and provide external functions to create, modify and destroy assets in accordance with detailed policies. As mentioned earlier, this feature is also often used for access control of Move. The outside of the Module cannot bypass the Module to directly operate on the internal Resource, and must use the Resource with some restrictions through the provided functions. Reflected in the code, external developers can only call functions of the Public type in the Module, and operate according to the definition inside the module, avoiding potential safety hazards caused by accidental calls.
●Flexibility and statelessness
The module still retains the public interface of the externally provided modules for mutual combination and resource use between contracts during design. This is not much different from the Interface standard used by Solidity in terms of function. The difference is that the modules of the Move language are stateless. Yes, state is kept in global storage. Specifically, the Token implementation of the ERC-20 contract in Solidity is more like a ledger, which records the complete data of each user's interaction with the contract through the state change of the ledger; and Move uses Module to encapsulate assets and store them in accounts Under the address, it's more like a self-contained safe with a label.
c) Ownership system - realize asset ownership
This concept is inherited from Rust, which defines ownership like this:
1. Each value has a corresponding variable called owner;
2. A value has one and only one owner at any time;
3. When the owner goes out of scope, the value is discarded.
Simply put, value can only have a unique owner, where the owner can be a function. When passing a value to a new function, the function becomes the new owner, where passing a value to a function is semantically similar to assigning a value to a variable.
Therefore, looking back at the resource attributes of Resource, although the Resource transaction between users is still added, subtracted and indexed according to the value of the asset, it is different from the forced use of code logic in Solidity to reduce the balance of one address and increase the balance of another address. There is an essential difference between the methods; the transfer process of Resource is more like moving bricks, moving resources from one account to another, and there will be no loss or duplication during the transfer, which better guarantees asset security.
In general, Move clarifies the ownership of data through the concept of linear type, emphasizes resource scarcity, protection and access control, and uses the module system to define the life cycle, storage and access mode of each resource. These features together ensure that digital assets will not be created out of thin air and discarded implicitly, reducing the occurrence of security problems such as double spending and unlimited issuance.
secondary title
2.2 Virtual machine: Runtime Bytecode Verifier — — Look for vulnerabilities during execution
The language design features of Move are introduced above, and developers can use these features to write smart contracts with specific needs. However, both Move and Solidity are high-level programming languages, and computers cannot directly read and execute these source codes, so they need to rely on dedicated executors to implement specific contracts.
Currently, virtual machines are one of the mainstream implementations of smart contracts, and Move is no exception. It can provide programs with a completely transparent execution environment to the bottom layer, and its purpose is to realize the feature of "write once, run everywhere", instead of allowing program developers to write different versions of programs for compatibility with each different server. The reason for this design is that the smart contract runs in a distributed system environment that requires Byzantine fault tolerance to reach a consensus. All nodes must generate the same calculation results according to the rules stipulated in the smart contract, otherwise the result of the contract execution cannot be reached by each node. Consensus ; while the virtual machine can shield the differences in the execution environment of the blockchain nodes themselves, and run consistently on all nodes, realizing the certainty of smart contracts.
The Move virtual machine is a typical stack-based bytecode interpreter. The input is bytecode, plus the current world state, and the output is a change to the world state; it has an independent instruction set to execute and process all of the system. When the state changes, the user can find the corresponding meaning of the command in the bytecode comparison table provided by Move.
●Workflow
The specific workflow of the Move virtual machine is as follows: firstly, the source code is converted into low-level bytecode Bytecode through the compiler and passed to the virtual machine; after receiving the bytecode, the virtual machine first calls the bytecode verifier for verification The verifier can check out various types of errors in the Move source code; finally, the virtual machine interpreter interprets and executes the scripts sequentially, traversing each data or bytecode from left to right. The runtime is based on the stack execution. When data is encountered, it is pushed onto the stack. When bytecode is encountered, the data of the corresponding data is popped up. The bytecode is used for calculation. After the calculation, the calculation result is pushed back to the stack until it exits.
The type errors that may occur when checking the source code through this process mainly include:
i. Stack out-of-bounds check. Check the scope of each function to access the operand stack and whether the stack height is legal. The stack here is the instruction block (basic block) of each bytecode created by the bytecode verifier;
ii. Type&Kind check. Check whether the specific type of the variable in the derivation stack is correct; for example, the stack class cannot use CopyLoc bytecode for the Resource type variable, which is also a direct manifestation of asset scarcity;
iii. Citation Checking. To prevent dangling references, each reference must point to an allocated storage location.
EVM is an isolated and determinable sandbox environment created by chain nodes for smart contracts. Multiple contract programs run in different virtual machine sandboxes in the same process. This means that calls between Ethereum contracts are calls between different smart contract virtual machines in the same process, and security depends on the isolation between smart contract virtual machines.
The Move virtual machine supports parallel execution. The calls between contracts are centrally placed in a sandbox. Under this architecture, the security of the state of the contract is mainly isolated through the internal security of the programming language, rather than relying on the virtual machine for isolation.
secondary title
2.3 Off-Chain Tools: Formal Verification — Finding Vulnerabilities Before Execution
Ideally, Move would be able to find security holes in the contract runtime by running bytecode verification. However, the calculation cost of this kind of on-chain verification is very high, and this kind of calculation often takes up a lot of network resources, affecting the TPS on the chain. Therefore, the strategy that Move hopes to adopt is to only perform lightweight on-chain verification of key security attributes, and rely on off-chain static verification tools for other security issues. Based on this strategy, Move developed the unique Move Prover formal verifier to prevent human errors and improve code security.
The so-called formal verification is to verify the reliability of the program according to certain formal specifications or attributes. These specifications are usually established by establishing mathematical models. No bugs existed before deployment. Compared with traditional manual audit code security, formal verification can solve the drawbacks that manual means cannot exhaustively enumerate possible inputs.
● static calls
It is worth mentioning that Move Prover is a static verification tool, because Move does not support dynamic calls at all from the mechanism design. Dynamic call means that if a program calls another program, the target of the call must be determined at runtime, then this kind of contract call is called dynamic. From the mechanism point of view, it is somewhat similar to the remote call of the server. However, dynamic calls can cause concurrency issues when calling them in a loop. For example, contract A calls contract B, and contract B calls contract A. The previous execution of contract A is not completed and the next execution is performed, resulting in the failure of subsequent executions to read the previous intermediate state, which eventually leads to security vulnerabilities. The famous The DAO accident was caused by the problem of contract dynamic call. Therefore, in the Move design, each function call is static, and developers can know which functions it calls in a certain order before the program runs. This kind of static type system is more suitable for reasoning through formal verification, and exposes the problem before the compilation stage, so as to reduce the possibility of bugs at runtime, and well share the pressure of security checks.
first level title
3. Summary and Outlook
If the transition from Bitcoin Script to Ethereum Solidity is a change in contract expression capabilities, then the transition from Solidity to Move is the evolution of contract security capabilities. Therefore, Move has also been entrusted with higher market expectations.
From the perspective of language mechanism, Move's exploration of asset security is very exciting. It has made innovative changes at the three levels of language design, virtual machine and verification tools. These designs are an organic whole: the asset-oriented programming design makes the Move language naturally adapt to the deployment of decentralized financial applications; linear Features such as logic, access control, static calls, and formal verification also provide multiple guarantees for the security of digital assets.
The biggest focus of this round of new public chain narrative is undoubtedly Move. Whether it can use this shareholder style to make a big difference in the market, we all look forward to it.
References
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/
first level title
Official website:
contact us:
Consulting email: research@huobi.com
Official website:https://research.huobi.com/
Twitter： Huobi_Research
https://twitter.com/Huobi_Research
Medium： Huobi Research
https://medium.com/huobi-research
Telegram： Huobi Research
https://t.me/HuobiResearchOfficial
disclaimer
1. Huobi Blockchain Research Institute does not have any relationship with the projects or other third parties involved in this report that may affect the objectivity, independence, and impartiality of the report.
2. The materials and data cited in this report are all from compliant channels. The sources of the materials and data are considered reliable by Huobi Blockchain Research Institute, and necessary verifications have been carried out for their authenticity, accuracy and completeness , but Huobi Blockchain Research Institute does not make any guarantees about its authenticity, accuracy or completeness.
3. The content of the report is for reference only, and the conclusions and opinions in the report do not constitute any investment advice on relevant digital assets. Huobi Blockchain Research Institute shall not be liable for any losses arising from the use of the contents of this report, unless expressly stipulated by laws and regulations. Readers should not make investment decisions solely based on this report, nor should they lose the ability to make independent judgments based on this report.
4. The information, opinions and speculations contained in this report only reflect the judgment of the researchers on the date of finalizing this report. In the future, based on industry changes and updates of data information, there is a possibility of updating opinions and judgments.
3. The content of the report is for reference only, and the conclusions and opinions in the report do not constitute any investment advice on relevant digital assets. Huobi Blockchain Research Institute shall not be liable for any losses arising from the use of the contents of this report, unless expressly stipulated by laws and regulations. Readers should not make investment decisions solely based on this report, nor should they lose the ability to make independent judgments based on this report.
IOS
Android