Overview

This doc covers some key Aptos Move programming questions you might face when using Node Service to read and write to the Aptos blockchain. Make sure to also:

• See our Aptos Move Developer Resources doc for a list of helpful developer resources.

How to manage concurrent transactions

Client design

You can design your client to be able to perform a high number of concurrent transactions in two main ways. Both ideas are covered in this Aptos Labs doc on Transaction Management:

1. Scale the number of transactions you can submit at once from the same wallet address.
   1. You can push upwards of 100 transactions in a block from the same address (an account can have up to 100 uncommitted but submitted transactions). This requires having a sequence number generator to ensure that concurrently submitted transactions have differing and valid sequence numbers.
2. Scale the number of addresses that can perform a given transaction.
   1. The above doc shows how to go beyond the "100 submitted but uncommitted transactions per account" limit by using worker accounts that share access to the SignerCap of a shared resource account.

Smart contract design

There are some cases where it's hard to have parallelization of transactions that make the same Move call. An example is an NFT minting function that assigns a number to each NFT (e.g. #17/100). The Aptos team designed Aggregators for this use case. Aggregators are wrappers around integers. They allow for differed reads and writes, allowing transactions that affect the same variable to execute in parallel. In a test, the Aptos team found that Aggregators let them mint a 1,000,000 NFT collection in 90 seconds - an improvement of ~10x!

For more info on their design, abilities, and limitations, see:

• Blog post describing the problems aggregators solve
• Mainnet module - look for aggregator_v2
• Documentation