Move Language
Introduction to the Move Language
The Move language is a cutting-edge smart contract language developed by Diem. In order to attract a wide range of developers to build applications for the new ecosystem, it’s crucial to have a language that developers are already familiar with. Currently, popular programming languages in the blockchain space include Solidity, used by Ethereum, Avalanche, and BSC, as well as Rust, used by projects like PolkaDot and Solana. Move, being a brand-new language, introduces a learning curve for developers interested in creating on Aptos.
The existing pool of developers proficient in Move is limited, and the associated development tools may not be as comprehensive as those available for more established languages. However, driven by projects like Aptos and Sui within the “Diem” ecosystem, and with the potential for further adoption of Diem technology in the future, Move has the potential to evolve into one of the mainstream blockchain development languages.
The Move programming language was specifically designed as a secure and programmable foundation for Aptos’ vision of creating an inclusive financial infrastructure. With this objective in mind, Move aims to address the main pain points of existing blockchain languages. As a result, Aptos’ proposed solution can be summarized by four key goals: exceptional resource handling, flexibility, security, and verifiability.
Features and Advantage of the Move Language
One of the prominent features of Move is the ability to define custom resource types, ensuring that resources can only be moved between program storage locations, rather than being cloned or deleted. This approach significantly enhances security by effectively mitigating vulnerabilities. These resources are then managed by Move modules, akin to smart contracts, which govern the encoding rules for creating, updating, and deleting declared resources.
Move modules possess an advantage over smart contracts as they enforce data abstraction. This means that resources are transparent within their respective declaration modules but opaque outside of them. Additionally, leveraging an expressive canonical language, Move provers can formally verify the properties of Move modules, providing efficient support for continuous integration testing.
The above overview provides a concise introduction to the features and advantages of Aptos and the Move language. Next, we will delve deeper into Aptos and Move by deploying and invoking real operations, as well as discuss the security and related considerations of Move in comparison to the more mature EVM and Solidity ecosystems.
Before we proceed with deployment and invocation, let’s gain a basic understanding of some of Aptos’ architectural components. The first component is the account system, which represents the resources on the Aptos blockchain capable of initiating transactions.
Every account contains an authentication key, enabling rotation of the associated private key without changing the account itself. During rotation, the authentication key is updated based on the newly generated public and private key pairs. An account can be created using Aptos init.
The authentication key is derived from the public key using the following formula: auth_key = sha3–256(pubkey_A | 0x00), where ‘|’ denotes concatenation. ‘0x00’ represents a 1-byte signature scheme identifier, where ‘0x00’ signifies a single signature.
The first 16 bytes of the auth_key correspond to the Authentication Key Prefix, while the last 16 bytes represent the account address. Any transaction that creates an account requires both an account address and a verification key prefix, whereas transactions interacting with an existing account only require the address. The aforementioned explanation pertains to single-signer mode, but there is also a multi-signature mode available. Multi-signature mode functions similarly to conventional multi-signature contracts.
Based on the above understanding, the authentication key can replace the public and private keys of an account, effectively acting as the highest owner of the address. Consequently, the authentication key can be designed to support multiple signatures, as outlined in the following steps:
- Generate a key pair: Generate N ed25519 public keys p_1, …, p_n.
- Derive a 32-byte authentication key: calculate auth_key = sha3–256 (p_1 | … | p_n | K | 0x01). Derive the address and authentication key prefix as described above. K represents the K-of-N required to validate transactions. 0x01 is a 1-byte signature scheme identifier where 0x01 represents a multi-signature.
Move Overview
In Aptos, each transaction encompasses a Move trading script that encodes the logic executed by validators on behalf of clients. The transaction script interacts with Move resources stored in the global storage of the blockchain by invoking one or more Move modules. These Move modules function similarly to smart contracts, defining rules for updating the blockchain, and they must be associated with an account, represented by an address.
The trading script, often referred to as a “tx,” can be either a single transaction or a complex transaction invoked by multiple modules. It is important to note that the transaction script itself is not stored on the blockchain. Additionally, the calling object for the transaction script can only be a module, and the script itself can only be utilized once.
Now, let’s explore the process of deploying an Aptos module, also known as a contract.
great job and thanks 