Aptos is an innovative public blockchain (proof of stake) developed by former Facebook employees, with a primary focus on delivering high throughput and robust security for smart contracts developed using the Move programming language. By utilizing a Byzantine Fault Tolerant (BFT) consensus mechanism and the Move language, Aptos establishes itself as a highly secure and scalable Layer 1 blockchain solution.
Aptos has made significant advancements in its consensus protocol, now operating on its fourth iteration called Aptos BFT. This latest iteration boasts the lowest latency and the most advanced features developed to date. Notably, Aptos BFT separates the consensus and execution processes, resulting in optimized authentication and streamlined data structures. These improvements greatly reduce transaction execution time. A key technical feature of Aptos is its utilization of parallel transaction execution, enabling exceptional scalability.
Unlike traditional blockchains that employ serial transaction execution, where transactions are processed one after another, Aptos adopts parallel execution. This approach allows multiple transactions to be executed simultaneously by capturing a snapshot of the current state and processing them in parallel. While serial execution ensures transaction status confirmation, it inherently limits scalability. Aptos addresses this limitation by employing parallel execution, significantly enhancing transaction throughput.
The challenge with parallel execution lies in preventing different transactions from interfering with each other. Aptos has made notable progress in this area and currently reports impressive results on its testnet, with over 20,000 nodes and a transaction processing capacity of 10,000 transactions per second (TPS). Aptos aims to achieve an ultimate goal of 100,000 TPS. However, the actual attainment of this goal and the network’s stability without downtime will be revealed once the mainnet is launched and operational.
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. Similar to other blockchains, each account corresponds to a 32-byte address, as depicted in the following diagram:
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.
In the above diagram, you can observe the public key and private key. 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.
How to Deploy a Contract on Aptos
1. Environment installation: download an Aptos client from github
wget https://github.com/aptos-labs/aptos-core/releases/tag/aptos-cli-v0.3.1a
2. Decompress it
unzip aptos-cli-0.2.3-Ubuntu-x86_64.zip
3. After extracting, it is an executable file, and then configure the environment variables like below, and execute is in the terminal.
vim ~/.bashrc
export PATH=$PATH:/root/aptos/cli
~/.bashrc soure
4. Create a folder : aptos init
5. An account is generated and the account information is saved in the config.yaml file.
6. You can use the default configuration, the approximate directory is as follows:
|. aptos|
|config.yaml
| Move.toml
|sources|
|modules
|tests
Module folder is mainly contract content. Test cases can also be written in the contract content, or be written separately in the test directory. The config.yaml is generated by initialization, including rpc node, private_key and public_key. Move.toml is configuration information for some projects.
Address is the address at the time of initialization.
7. After the above operation is done, start writing the first move contract.
Execute touch command to create a file in the module.
The provided code represents a set operation, implementing a structure called “MessageHolder” and a corresponding function named “set_message.” The “set_message” function serves as a script function that can be directly invoked by a transaction. Upon invocation, the function performs a check to determine if the account already possesses a “MessageHolder” resource. If the resource doesn’t exist, the function creates a new one and writes the provided information. In case the resource already exists, the function overwrites the existing data. Additionally, there is a “get” command available to retrieve the inputs.
The mentioned test case is one of the test scenarios we have executed to validate the functionality.
8. After doing the above, start trying the compilation test:
When discovers that the compilation passes, then deploys it on chain.
The following is the on-chain information returned.You can put it on Aptos exploere.
9. Go to the browser to search for the corresponding hash, and you can see the function interface of the contract, as shown in figure below:
A complete on-chain process is like above description.
10. Then try calling the newly deployed contract, which is the module. A trading script needs to be built. Run below command first and a folder will be created.
Then go to the folder,
A web interface will be launched with a default port of 3000.
In fact, a rpc node is introduced and a front-end page is opened. Open f12 and connect your wallet first.
Then try calling the set_message function.
You can see the result of the call on your browser.
Move Vulnerabilities
1. Overflow issue
This problem is a common problem, u8, u16 these represent data types, take u8 as an example, unsigned integer, so the range is [0,255]. When you meet the picture below:
This situation creates an overflow problem, but move throws this situation at compile time.
Like solidity, for four operations, they will be thrown when compiling, and if the bit operations do not, this place needs to be careful not to rely too much on compilation checks.
2. Denial of Service
When the external parameters are controllable and the type is an indefinitely long array, because the on-chain all need to consume gas, a denial of service will occur, and the parameters and traversal operations should be carefully checked.
3. Function Permissions
For some function calls, the permissions should be carefully divided, because some key functions will involve governance, which will seriously affect the safety of funds, and the call for such function calls should be authenticated for the caller.
4. Reentrancy Vulnerability
In Ethereum, when a transfer is made to a contract address but is not called, it enters the fallback function of the target contract address, thus losing control of the code.
For move, this addr is equivalent to a module, and must be imported and declared when any external module is used, which effectively prevents reentrant.
Summary
Aptos is still a relatively new field, and this is also the initial exploration of Aptos. Move’s language is designed from a security point of view, the main feature of Move is to be able to customize the type of resource, resources can never be copied or implicitly discarded, can only be moved between the storage locations of the program, which also avoids some rug events. For the underlying VM of Move, further analysis will subsequently be carried out .
Numen Cyber Labs is committed to facilitating the safe development of Web 3.0. We are dedicated to the security of the blockchain ecosystem, as well as operating systems & browser/mobile security. We regularly disseminate analyses on topics such as these, please stay tuned or visit our blog here for more!
This blog was originally published on our Medium Account.
