Immersion in the Move - Libra blockchain programming language from Facebook
Next, we will examine in detail the main characteristics of the Move language and what are its key differences with another, already popular language for smart contracts - Solidity (on the Ethereum platform). The material is based on the study of the available on-line 26-page whitepaper.
Move is the bytecode executable language that is used to perform user transactions and smart contracts. Pay attention to two points:
Translation is done by the INDEX Protocol project team. Previously, we have already translated a lot of material describing the Libra project , now it’s time for a little more detail to look at the Move language. Translation is made together with coolsiu
')
A key feature of Move is the ability to define custom resource types with semantics based on linear logic: a resource can never be copied or implicitly deleted, only moved. Functionally, this is similar to the features of the Rust language. Values ​​in Rust can only be assigned to one name at a time. Assigning a value to another name makes it unavailable under the previous name.
For example, the following code snippet will generate an error: Use of moved value 'x'. This is because in Rust there is no garbage collection. When variables go out of scope, the memory to which they refer is also freed. Simply put, there can be only one “owner” of data. In this example, x is the original owner, and then y becomes the new owner. Read more about this behavior here .
There are two properties of physical assets that are difficult to digitize:
These two characteristics, which are natural for physical assets, must also be realized for digital objects if we want to consider them as assets. For example, a rare metal has a natural shortage, and only you have access to it (holding, for example) and you can sell it or spend it.
To illustrate how we came to these two properties, let's start with the following sentences:
The above solution has several serious problems:
Now we monitor the situation so that the number of Ka coins is at least equal to n before the transfer transaction. Nevertheless, although this solves the problem of shortage, there is no information about who can send Alice’s coins (so far everyone can do it, the main thing is not to violate the quantity limitation rule).
We solve this problem by using the verify_sig digital signature mechanism before checking the balance, which means that Alice uses her private key to sign a transaction and confirm that she is the owner of her coins.
The existing blockchain languages ​​encounter the following problems (all of them were resolved in the Move (note: unfortunately, the author appeals only to Ethereum in his comparisons, so it’s worth taking them only in this context. For example, most of the following are also solved in EOS )):
Indirect asset representation . An asset is encoded using an integer, but an integer value is not the same as an asset. In fact, there is no type or value representing bitcoin / broadcast / <Any Coin>! This makes it difficult and error-prone to write programs that use assets. Patterns such as transferring assets to / from procedures or storing assets in structures require special language support.
Lack of non-expanding . A language represents only one deficient asset. In addition, the means of protection against shortages are rigidly sewn directly into the semantics of the language itself. The developer, if he wants to create a user asset, must carefully control all aspects of the resource. These are the problems of Ethereum smart contracts.
Users release their assets, ERC-20 standard tokens, using whole numbers to determine both value and total emissions. Whenever new tokens are created, the smart contract code must independently verify compliance with the emission rules. In addition, the indirect presentation of assets leads, in some cases, to serious errors - duplication, double spending, or even total loss of assets.
Lack of flexible access control . The only access control policy currently used is a signature scheme using asymmetric cryptography. As well as protection against shortages, access control policies are deeply rooted in the semantics of language. But how to extend the language to allow programmers to define their own access control policies is often a very non-trivial task.
This is also true for Ethereum, where smart contracts do not have native cryptography support for access control. Developers must manually prescribe access control, for example, using the onlyOwner modifier.
Despite the fact that I am a big fan of Ethereum, I believe that the properties of assets should initially be natively supported by the language for security purposes. In particular, transferring Ether to a smart contract involves dynamic dispatching, which has led to the emergence of a new class of errors, known as re-entrancy vulnerabilities. Dynamic scheduling here means that the code execution logic will be determined at runtime (dynamic) and not at compile time (static).
Thus, in Solidity, when contract A calls contract function B, contract B may run code that was not provided by contract developer A, which could lead to re-entry vulnerabilities (contract A randomly performs the function of contract B to withdraw money before the actual deduction account balances).
Speaking high level, the interaction between modules / resources / procedures in the Move language is very similar to the relationship between classes / objects and methods in OOP languages.
The modules in Move are similar to smart contracts in other blockchains. The module declares resource types and procedures that define rules for creating, destroying, and updating declared resources. But all this is just conventions (“ jargon ”) in Move. We will illustrate this point a little later.
Move adds Libra flexibility through scripts. Each transaction in Libra includes a script, which is actually the main transaction procedure. The script can perform either one specified action, for example, payments for a specified list of recipients, or reuse other resources — for example, by calling a procedure in which the common logic is specified. This is why Move transaction scripts offer more flexibility. The script can use both one-time and repetitive behaviors, while Ethereum can only execute repetitive scenarios (by calling one method the smart contract method). The reason why it is called “multiple” is that the functions of a smart contract can be performed several times. (note: here the moment is very thin. On the one hand, transaction scripts in the form of pseudo-bytecode exist in Bitcoin. On the other hand, as I understand it, Move expands this language, in fact, to the level of a full-fledged language of smart contracts ).
The executable Move format is a byte-code, which, on the one hand, is a language of a higher level than assembler, but lower level than the source code. The byte code is checked in the on-chain for the presence of resources, types and memory security using the byte-code verifier, and then executed by the interpreter. This approach allows Move to provide security that is specific to source code, but without the compilation process and the need to add a compiler to the system. Making Move bytecode code is a really good solution. There is no need to compile it from source, as in the case of Solidity, you do not need to worry about possible failures or attacks on the compiler infrastructure.
We aim to perform as easy checks as possible, since all of this goes on-chain (note: online, in the process of performing each transaction, so any delay will slow down the entire network ), but initially the language design is ready for use and off-chain static verification tools. Although it is more preferable, but so far the development of verification tools (as a separate toolkit) has been postponed for the future, and now only dynamic verification in the on-chain is supported.
Move modules provide data abstraction and localize critical operations on resources. The encapsulation provided by the module, combined with the protection provided by the Move type system, ensures that the properties set for the module types cannot be violated by code outside the module. This is a fairly thoughtful design of abstraction, meaning that the data inside the contract can be changed only as part of the execution of the contract, but not from the outside.
The sample transaction script demonstrates that malicious or careless actions of a programmer outside a module cannot compromise the security of a module’s resources. Next, we will look at examples of how modules, resources, and procedures are used to program the Libra blockchain.
The amount of coins specified in the amount will be transferred from the balance of the sender to the recipient.
There are a few new points here (highlighted in red):
Parse the code: in the first step, the sender calls the procedure named withdraw_from_sender from the module stored in 0x0.Currency . At the second stage, the sender transfers funds to the recipient by moving the value of the coin resource to the deposit procedure of the 0x0.Currency module.
Here are three examples of errors in the code that will be rejected by checks:
Duplication of funds by changing the call move (coin) to copy (coin) . Resources can only be moved. Attempting to duplicate the amount of a resource (for example, by calling copy (coin) in the example above) will result in an error during the bytecode check.
Reuse funds by specifying move (coin) twice . Adding the line 0x0.Currency.deposit (copy (some_other_payee), move (coin)) for example above allows the sender to “spend” coins twice - the first time with the payee, and the second with some_other_payee . This is undesirable behavior, impossible with a physical asset. Fortunately, Move will reject this program.
Loss of funds due to failure to move (coin) . If you do not move a resource (for example, deleting a line containing move (coin) ), a bytecode check error will be triggered. This protects Move programmers from accidental or malicious loss of funds.
Each account can contain 0 or more modules (shown as rectangles) and one or more resource values ​​(shown as cylinders). For example, an account at 0x0 contains a module 0x0.Currency and a resource value of type 0x0.Currency.Coin . The account at 0x1 has two resources and one module; The account at 0x2 has two modules and one resource value.
Some moments:
Module named Currency and type of resource named Coin
Some moments:
This procedure takes the Coin resource as input and combines it with the Coin resource stored in the recipient’s account:
Some moments:
This procedure:
Some moments:
We analyzed the main features of the Move language, compared it with Ethereum, and also familiarized ourselves with the basic syntax of the scripts. In conclusion, I highly recommend looking through the original white paper . It includes many details regarding the principles of designing a programming language, as well as many useful links.
Introduction
Move is the bytecode executable language that is used to perform user transactions and smart contracts. Pay attention to two points:
- While Move is a bytecode language that can be directly executed on a Move virtual machine, Solidity (the smart contract language in Ethereum) is a higher level language that is first compiled into a byte code before execution in EVM (Ethereum Virtual Machine ).
- Move can be used not only for the implementation of smart contracts, but also for user transactions (more on this later), while Solidity is a language for smart contracts only.
Translation is done by the INDEX Protocol project team. Previously, we have already translated a lot of material describing the Libra project , now it’s time for a little more detail to look at the Move language. Translation is made together with coolsiu
')
A key feature of Move is the ability to define custom resource types with semantics based on linear logic: a resource can never be copied or implicitly deleted, only moved. Functionally, this is similar to the features of the Rust language. Values ​​in Rust can only be assigned to one name at a time. Assigning a value to another name makes it unavailable under the previous name.
For example, the following code snippet will generate an error: Use of moved value 'x'. This is because in Rust there is no garbage collection. When variables go out of scope, the memory to which they refer is also freed. Simply put, there can be only one “owner” of data. In this example, x is the original owner, and then y becomes the new owner. Read more about this behavior here .
Representation of digital assets in open systems
There are two properties of physical assets that are difficult to digitize:
- Rarity (Deficiency, in the original - scarcity). The number of assets (emission) in the system must be controlled. It is necessary to prohibit the duplication of existing assets, and the creation of new ones is a privileged operation.
- Access control . The system member must be able to protect assets using access control policies.
These two characteristics, which are natural for physical assets, must also be realized for digital objects if we want to consider them as assets. For example, a rare metal has a natural shortage, and only you have access to it (holding, for example) and you can sell it or spend it.
To illustrate how we came to these two properties, let's start with the following sentences:
Sentence No. 1: The simplest rule without deficiency and access control
- G [K]: = n indicates the update of the number available on the key K in the global state of the blockchain with the new value n .
- transaction “Alice, 100” means setting the balance of Alice's account to 100.
The above solution has several serious problems:
- Alice can receive an unlimited amount of coins simply by sending the transaction “Alice, 100”.
- The coins that Alice sends to Bob are useless, since Bob could send himself an unlimited amount of coins using the same technique.
Suggestion number 2: We consider the deficit
Now we monitor the situation so that the number of Ka coins is at least equal to n before the transfer transaction. Nevertheless, although this solves the problem of shortage, there is no information about who can send Alice’s coins (so far everyone can do it, the main thing is not to violate the quantity limitation rule).
Proposal # 3: Combining Deficit and Access Control
We solve this problem by using the verify_sig digital signature mechanism before checking the balance, which means that Alice uses her private key to sign a transaction and confirm that she is the owner of her coins.
Programming languages ​​blockchain
The existing blockchain languages ​​encounter the following problems (all of them were resolved in the Move (note: unfortunately, the author appeals only to Ethereum in his comparisons, so it’s worth taking them only in this context. For example, most of the following are also solved in EOS )):
Indirect asset representation . An asset is encoded using an integer, but an integer value is not the same as an asset. In fact, there is no type or value representing bitcoin / broadcast / <Any Coin>! This makes it difficult and error-prone to write programs that use assets. Patterns such as transferring assets to / from procedures or storing assets in structures require special language support.
Lack of non-expanding . A language represents only one deficient asset. In addition, the means of protection against shortages are rigidly sewn directly into the semantics of the language itself. The developer, if he wants to create a user asset, must carefully control all aspects of the resource. These are the problems of Ethereum smart contracts.
Users release their assets, ERC-20 standard tokens, using whole numbers to determine both value and total emissions. Whenever new tokens are created, the smart contract code must independently verify compliance with the emission rules. In addition, the indirect presentation of assets leads, in some cases, to serious errors - duplication, double spending, or even total loss of assets.
Lack of flexible access control . The only access control policy currently used is a signature scheme using asymmetric cryptography. As well as protection against shortages, access control policies are deeply rooted in the semantics of language. But how to extend the language to allow programmers to define their own access control policies is often a very non-trivial task.
This is also true for Ethereum, where smart contracts do not have native cryptography support for access control. Developers must manually prescribe access control, for example, using the onlyOwner modifier.
Despite the fact that I am a big fan of Ethereum, I believe that the properties of assets should initially be natively supported by the language for security purposes. In particular, transferring Ether to a smart contract involves dynamic dispatching, which has led to the emergence of a new class of errors, known as re-entrancy vulnerabilities. Dynamic scheduling here means that the code execution logic will be determined at runtime (dynamic) and not at compile time (static).
Thus, in Solidity, when contract A calls contract function B, contract B may run code that was not provided by contract developer A, which could lead to re-entry vulnerabilities (contract A randomly performs the function of contract B to withdraw money before the actual deduction account balances).
Basics of the design of the language Move
First Order Resources
Speaking high level, the interaction between modules / resources / procedures in the Move language is very similar to the relationship between classes / objects and methods in OOP languages.
The modules in Move are similar to smart contracts in other blockchains. The module declares resource types and procedures that define rules for creating, destroying, and updating declared resources. But all this is just conventions (“ jargon ”) in Move. We will illustrate this point a little later.
Flexibility
Move adds Libra flexibility through scripts. Each transaction in Libra includes a script, which is actually the main transaction procedure. The script can perform either one specified action, for example, payments for a specified list of recipients, or reuse other resources — for example, by calling a procedure in which the common logic is specified. This is why Move transaction scripts offer more flexibility. The script can use both one-time and repetitive behaviors, while Ethereum can only execute repetitive scenarios (by calling one method the smart contract method). The reason why it is called “multiple” is that the functions of a smart contract can be performed several times. (note: here the moment is very thin. On the one hand, transaction scripts in the form of pseudo-bytecode exist in Bitcoin. On the other hand, as I understand it, Move expands this language, in fact, to the level of a full-fledged language of smart contracts ).
Security
The executable Move format is a byte-code, which, on the one hand, is a language of a higher level than assembler, but lower level than the source code. The byte code is checked in the on-chain for the presence of resources, types and memory security using the byte-code verifier, and then executed by the interpreter. This approach allows Move to provide security that is specific to source code, but without the compilation process and the need to add a compiler to the system. Making Move bytecode code is a really good solution. There is no need to compile it from source, as in the case of Solidity, you do not need to worry about possible failures or attacks on the compiler infrastructure.
Verifiability
We aim to perform as easy checks as possible, since all of this goes on-chain (note: online, in the process of performing each transaction, so any delay will slow down the entire network ), but initially the language design is ready for use and off-chain static verification tools. Although it is more preferable, but so far the development of verification tools (as a separate toolkit) has been postponed for the future, and now only dynamic verification in the on-chain is supported.
Modularity
Move modules provide data abstraction and localize critical operations on resources. The encapsulation provided by the module, combined with the protection provided by the Move type system, ensures that the properties set for the module types cannot be violated by code outside the module. This is a fairly thoughtful design of abstraction, meaning that the data inside the contract can be changed only as part of the execution of the contract, but not from the outside.
Move overview
The sample transaction script demonstrates that malicious or careless actions of a programmer outside a module cannot compromise the security of a module’s resources. Next, we will look at examples of how modules, resources, and procedures are used to program the Libra blockchain.
Peer-to-Peer Payments
The amount of coins specified in the amount will be transferred from the balance of the sender to the recipient.
There are a few new points here (highlighted in red):
- 0x0 : address of the account where the module is stored
- Currency : module name
- Coin : resource type
- The coin value returned by the procedure is a resource value of type 0x0.Currency.Coin
- move () : value cannot be used again
- copy () : value can be used later
Parse the code: in the first step, the sender calls the procedure named withdraw_from_sender from the module stored in 0x0.Currency . At the second stage, the sender transfers funds to the recipient by moving the value of the coin resource to the deposit procedure of the 0x0.Currency module.
Here are three examples of errors in the code that will be rejected by checks:
Duplication of funds by changing the call move (coin) to copy (coin) . Resources can only be moved. Attempting to duplicate the amount of a resource (for example, by calling copy (coin) in the example above) will result in an error during the bytecode check.
Reuse funds by specifying move (coin) twice . Adding the line 0x0.Currency.deposit (copy (some_other_payee), move (coin)) for example above allows the sender to “spend” coins twice - the first time with the payee, and the second with some_other_payee . This is undesirable behavior, impossible with a physical asset. Fortunately, Move will reject this program.
Loss of funds due to failure to move (coin) . If you do not move a resource (for example, deleting a line containing move (coin) ), a bytecode check error will be triggered. This protects Move programmers from accidental or malicious loss of funds.
Currency module
Each account can contain 0 or more modules (shown as rectangles) and one or more resource values ​​(shown as cylinders). For example, an account at 0x0 contains a module 0x0.Currency and a resource value of type 0x0.Currency.Coin . The account at 0x1 has two resources and one module; The account at 0x2 has two modules and one resource value.
Some moments:
- The atomic transaction script is either completely executed or not.
- A module is a long-lived piece of code, globally accessible.
- The global state is structured as a hash table, where the key is the address of the account
- Accounts can contain no more than one resource value of this type and no more than one module with a given name (an account at 0x0 cannot contain an additional resource 0x0.Currency.Coin or another module named Currency )
- The address of the declared module is part of the type ( 0x0.Currency.Coin and 0x1.Currency.Coin are separate types that cannot be used interchangeably)
- Programmers can store several instances of this type of resource in their account, defining their custom resource - ( resource TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin} )
- You can refer to a resource by its name without conflict, for example, you can refer to two resources using TwoCoins.c1 and TwoCoins.c2 .
Coin Resource Announcement
Module named Currency and type of resource named Coin
Some moments:
- Coin is a structure with one field of type u64 (64-bit unsigned integer)
- Only Currency module procedures can create or destroy Coin values.
- Other modules and scripts can only record or reference a value field through the open procedures provided by the module.
Implementation of the deposit
This procedure takes the Coin resource as input and combines it with the Coin resource stored in the recipient’s account:
- Destroys the input Coin resource and records its value.
- Getting a link to a unique Coin resource stored on the recipient account.
- Change the value of the Coin quantity by the value passed in the parameter when calling the procedure.
Some moments:
- Unpack, BorrowGlobal - embedded procedures
- Unpack <T> is the only way to remove a resource of type T. The procedure takes a resource at the input, destroys it, and returns the value associated with the resource fields.
- BorrowGlobal <T> takes the address as input and returns a link to a unique instance of T published (owned) to that address.
- & mut Coin is a link to a Coin resource.
Implementing withdraw_from_sender
This procedure:
- Gets a link to a unique Coin resource linked to the sender's account.
- Reduces the value of the resource Coin by reference to the specified amount
- Creates and returns a new Coin resource with an updated balance.
Some moments:
- Deposit can be called by anyone, but withdraw_from_sender has access only to coins of the calling account
- GetTxnSenderAddress is similar to msg.sender in Solidity
- RejectUnless is similar to require in Solidity. If this check fails, the execution of the transaction is stopped and all changes are rolled back.
- Pack <T> is also a built-in procedure that creates a new T resource.
- Like Unpack <T> , Pack <T> can only be called inside a module, where the resource T is described.
Conclusion
We analyzed the main features of the Move language, compared it with Ethereum, and also familiarized ourselves with the basic syntax of the scripts. In conclusion, I highly recommend looking through the original white paper . It includes many details regarding the principles of designing a programming language, as well as many useful links.
Source: https://habr.com/ru/post/459990/
All Articles