Numen

What is Aptos and How Does It Work?

Aptos Logo Graphic

Aptos is a new public chain (proof of stake) developed by former Facebook employees that aims to achieve high throughput and high security for smart contracts built using the Move language. It uses BFT consensus and the Move programming language to build the most secure and scalable Layer 1 blockchain.

Aptos is running on the fourth iteration of its consensus protocol, Aptos BFT, which it claims is the lowest latency and most advanced iteration to date. It separates consensus from execution and greatly reduces transaction execution time by optimizing authentication and data structures. One of the technical characteristics of Aptos is the use of parallel transaction execution, which achieves high scalability.

Most blockchains currently use serial transaction execution, meaning transactions are included in blocks one after another and must wait for the previous transaction to complete before the next one can be made. This approach makes it easy to confirm the status of the transaction, but limits scalability. Parallel execution, on the other hand, means that multiple transactions can be executed at the same time by generally taking a snapshot of the current state and then processing multiple transactions simultaneously.

This improves transaction throughput, but the challenge is how to prevent different transactions from affecting each other. Aptos currently claims that its testnet has more than 20,000 nodes and 10,000 transactions per second (TPS) and its ultimate goal is 100,000 TPS. However, whether this goal can be achieved, and whether the network can operate stably without downtime remains to be seen after the mainnet is online.

Move Language

The Move language is a new smart contract language created by Diem. To attract a large number of developers to create applications for a new ecosystem, it needs to have a language that developers are familiar with. Currently, common programming languages in blockchains are Solidity, used by other EVM chains such as Ethereum, Avalanche, and BSC, and Rust, used by Poka and Solana. Move is a completely new language, which adds a certain learning cost to developers who want to create in Aptos.

The base of developers familiar with the language is limited, and the development tools related to it may not be as complete as more mature languages. However, driven by “Diem” projects such as Aptos and Sui, and with the potential for more projects adopting Diem technology in the future, Move may develop into one of the mainstream blockchain development languages.

The Move programming language was created as a secure and programmable foundation for Aptos’ vision of creating a financial infrastructure that empowers the masses. With that in mind, Move aims to solve the main pain points of the current blockchain languages. As a result, Aptos’ proposed solution can be summarized into four key goals: best-in-class resources, flexibility, security, and verifiability.

The main feature of Move is the ability to define custom resource types, which statistically ensures that resources can only be moved between program storage locations, not cloned or deleted. This implementation significantly improves security by effectively preventing issues such as vulnerabilities. The resources are then managed by mobile modules, similar to smart contracts, which control the process of encoding rules for creating, updating, and deleting declared resources.

The advantage of Move modules over smart contracts is that they enforce data abstraction, meaning that resources are transparent inside their declaration modules and opaque outside of them. In addition, with the help of an expressive canonical language, Move provers can formally verify the characteristics of the Move modules and are efficient enough for continuous integration testing.

The above provides a brief introduction to the features and advantages of Aptos and the Move language. Next, we will have a deeper understanding of Aptos and Move by deploying and invoking actual operations and discuss the security and related issues of Move in comparison with the relatively mature EVM and Solidity.

Before attempting to deploy and invoke, let’s get a rough idea of some of Aptos’ architectures. The first is the account system, the account represents the resources on the Aptos blockchain that can send transactions. Like other blockchains, the account corresponds to an address, which is a 32-byte value, as shown in the following figure:

Each account stores an authentication key. This authentication key is able to rotate the private key associated with the account without changing the account. And during the rotation, the authentication key is updated based on the newly generated public and private key pairs. An account can be generated using Aptos init.

You can see the public key and private key from the above figure. The authentication key is generated from the public key in the following way: auth_key = sha3–256(pubkey_A | 0x00), where ‘|’ represents a connection. ‘0x00’ is a 1-byte signature scheme identifier where ‘0x00’ represents a single signature.

The first 16 bytes of auth_key are the Authentication Key Prefix. The last 16 bytes of the auth_key are the account address. Any transaction that creates an account requires an account address and a verification key prefix, but only an address is required for transactions that interact with an existing account. The above is for single signer, and there is also a multi-signature mode. My understanding of the multi-signature mode is similar to the common multi-signature contract.

According to the above understanding, the authentication key can replace the public and private keys of an account, making it the equivalent of the highest owner of an address. Therefore, the authentication key can be designed as multiple signatures, like the following steps:

  1. Generate a key pair: Generate N ed25519 public keys p_1, …, p_n.
  2. 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

Each transaction of Aptos contains a Move trading script that encodes the logic that the validator executes on behalf of the client. The transaction script interacts with the move resource in the global storage of the blockchain by invoking one or more move modules. The Move module is like a smart contract, which defines some rules for updating the blockchain, and the module must be bound to an account, that is, an address. The trading script can be said to be a tx, which can be a single transaction or a complex transaction called by multiple modules. This transaction script is not stored on the chain, the calling object can only be a module, and the transaction script can only be used once. Let’s try to deploy an Aptos module (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.

This code roughly means a set operation. It defines a MessageHolder structure and a set_message function. set_message is a script function that allows to be called directly by a transaction. After calling it, the function will confirm whether the account has a MessageHolder resource, if not, create one and write the information, and overwrite it if there is. There is also a get command to read the inputs.

The test above is one of our test cases.

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.

Share:

More Posts