Aptos is a L1 Proof-of-Stake (PoS) blockchain with a high focus on scalability, safety, reliability, and upgradeability. The Aptos chain operates using a PoS consensus mechanism with Byzantine fault tolerance (BFT). The network is divided into full nodes and light clients, allowing for different levels of participation. To maximize transaction throughput, Aptos employs a parallel transaction engine with BlockSTM, enabling multiple transactions to be processed simultaneously. The platform utilizes the Move language, which offers flexibility and simplicity for creating custom smart contracts while ensuring security and auditability. With a modular design, changes can be implemented at the node level, allowing for faster development and updates. The logical data model employed by Aptos ensures that resources cannot be discarded, promoting data integrity. All key stages of transaction processing, from dissemination to execution and certification, occur concurrently, further enhancing efficiency. The scaling of validators is facilitated through a structured approach, enabling the network to access additional compute, network, and storage resources.

The Aptos chain also emphasizes unified state sharing, enhancing the performance of validators by facilitating efficient data synchronization. In the following sections, we will discuss how transactions are processed and how the parallel transaction engine increases the throughput of the network. To understand this we shall need a refresher on a few key concepts of the Aptos Blockchain.

Before you continue further, we suggest you to read our overview of the Aptos ecosystem and familiarize yourself with concepts fundamental to understanding the operations on the network.

The ledger state of the Aptos blockchain captures the collective state of all accounts. Versioning is accomplished through a 64-bit integer reflecting the number of executed transactions. Modification of the ledger state is open to anyone through transaction submission. Each transaction generates a corresponding output, comprising write sets for manipulating the ledger state, event vectors, gas consumption details, and the transaction’s execution status. A signed transaction contains the transaction authenticator, sender address, gas price, maximum gas amount, sequence number, expiration time, and chain ID. The transaction authenticator includes digital signatures for authentication. The sender address represents the account of the transaction sender. Gas price denotes the payment per unit of gas for executing the transaction. The maximum gas amount specifies the maximum units of gas the transaction can consume. The sequence number ensures transaction order and prevents replay attacks. Expiration time defines the validity period of the transaction. The chain ID identifies the blockchain for which the transaction is intended, enhancing security.

A Move module in the Aptos blockchain consists of Move bytecode and declares data types (structs) and procedures. It is identified by the account address and module name. Modules can have dependencies on other on-chain modules, enabling code reuse. Each account can declare at most one module with a given name. Module identifiers are unique to their respective accounts. Modules are organized into packages located at the same address. The package, including bytecode and metadata, is published on-chain by the package owner. Package metadata determines whether it can be upgraded or is immutable. Upgradable packages undergo compatibility checks to ensure existing entry point functions remain unchanged and no resources are stored in memory while allowing the addition of new functions and resources.

During transaction execution on the Aptos blockchain, events are emitted by Move modules. Each module can define its events and determine when to emit them. Events have unique keys and can be queried to retrieve event details. Account addresses in Aptos are 256-bit unique identifiers. New accounts can be created using the create_account function, and transactions can automatically create accounts if needed. Transactions generate events but cannot read them, ensuring execution is based on the current state and inputs. Account addresses are derived from public verification keys, and users can sign transactions using associated private keys. Multiple accounts can be managed in a single wallet, offering pseudonymity and increased concurrency. Aptos is designed for future privacy-enhancing features.

Account addresses in the Aptos blockchain can have associated data values, with each value corresponding to a specific type. Only one value of each type is allowed per account. Generic types can also be used, treating different instantiations as distinct types. The module defining the data type determines the rules for mutation, deletion, and publication of values. Move’s safety and verification rules restrict direct manipulation of data types defined in other modules. The limitation of having only one top-level value of each type can be overcome by using wrapper types with internal fields. It’s important to note that not all data types can be stored on-chain, as the key ability is required for top-level values and the store ability is needed for nested values. Data types possessing both abilities are known as resources.

In the Move VM, each account is composed of values and key-value data structures known as table entries. This data layout enables efficient operation on both small amounts of data across numerous accounts and large amounts of data in a few accounts. Move modules are stored separately under their namespace. The genesis ledger state defines the initial set of accounts and their associated state during blockchain initialization. As adoption and technology progress, Aptos plans to scale by introducing multiple shards to increase throughput and support cross-shard asset transactions. Each ledger state will maintain on-chain assets for its respective shard, offering a fine-grained, key-value data store with consistent storage access costs.

To optimize throughput and concurrency while reducing complexity, the transaction processing on the Aptos blockchain is divided into separate stages. These stages operate independently and can be executed in parallel, similar to modern superscalar processor architectures. This approach not only improves performance but also enables new forms of validator-client interaction. Clients can receive notifications when specific transactions are included in a batch of persisted transactions, indicating imminent commitment. They can also be informed when a batch of transactions has been ordered, allowing them to execute transactions locally for faster results. Additionally, clients can choose to wait for certified transaction execution by validators and synchronize their state based on attested results. The modular design of Aptos facilitates faster development and targeted changes to individual modules, promoting scalability by leveraging additional computing, networking, and storage resources.

Batch processing is a key optimization technique used throughout the various phases of operation in the Aptos blockchain. Transactions are grouped into batches by validators during dissemination, and these batches are further combined into blocks during consensus. The execution, storage, and ledger certification phases also operate in batches, enabling reordering, reducing duplicate computations or signature verifications, and facilitating parallel execution. Although batching can introduce some latency, such as waiting for a certain period or accumulating a specific number of transactions before dissemination, it is configurable to balance latency and efficiency. This flexibility allows the decentralized network to automatically optimize batching based on parameters like maximum waiting period and batch size. Batching also supports efficient fee markets, enabling transaction prioritization and preventing unintended denial-of-service attacks caused by excessive client requests.

In the Aptos blockchain, transaction dissemination is separated from the consensus process. Validators continuously stream batches of transactions to each other concurrently, utilizing available network resources. Each validator persists the received batches and sends back a signature on the batch digest to the originating validator. To prevent denial-of-service (DoS) attacks caused by infinitely persisting batches and exhausting storage resources, each batch is associated with a timestamp. This timestamp allows efficient garbage collection at each validator. Additionally, a per-validator quota mechanism is implemented to protect against running out of storage space, even in extreme scenarios like potential Byzantine attacks. Batches also undergo sizing constraints validation before being agreed upon for persistence to stable storage. Furthermore, optimizations such as transaction de-duplication and caching reduce storage costs and ensure efficient integration with the parallel execution engine.

Block metadata ordering

The Aptos blockchain introduces innovations to address the misconception that consensus is slow and the primary bottleneck for blockchain throughput and latency. By decoupling non-agreement-related tasks, such as transaction dissemination, execution/storage, and ledger certification, from the consensus phase, Aptos achieves high transaction throughput and minimized latency.

Once consensus block metadata is ordered, transactions can be executed by any validator, full node, or client. Honest validators continuously receive transaction batches over time. ensuring that even if they haven’t received the batches at the execution stage, they can download them from the validators with higher weightage at stake. Parallel execution is a crucial objective for the Aptos blockchain. It promotes parallel execution from both the data model and the execution engine, allowing for efficient and simultaneous processing of transactions.

The Move data model supports global addressing of data and modules, enabling parallel execution of transactions that do not have conflicting data and accounts. Reordering transactions can reduce conflicts and improve concurrency in the pipelined design of the Aptos blockchain. Even when transactions modify the same data, the Aptos blockchain introduces delta writes, which is a new concept to describe modifications to the account state rather than the final state. This allows parallel processing of transactions, and conflicts are resolved by applying delta writes in the correct sequence to ensure deterministic results. The Aptos blockchain will continue to enhance the data model to improve concurrency and developer experience, leveraging features like read/write hints and platform-specific functionality at both the language and platform levels.

The BlockSTM (Block Software Transactional Memory) parallel execution engine in the Aptos blockchain allows for maximum parallelism by detecting and managing conflicts in ordered transactions. It uses optimistic concurrency control and a multi-version data structure to handle conflicts and avoid write-write conflicts. Batches of transactions are executed optimistically in parallel and validated post-execution, with unsuccessful validations leading to re-executions. BlockSTM achieves significant speedup in execution, up to 16x with low contention and over 8x with high contention. It dynamically extracts parallelism from workloads without requiring upfront knowledge of data locations, enabling more complex transactions to be executed concurrently. Transaction reordering can further optimize concurrency, as long as it is deterministic across validators. BlockSTM and transaction reordering work together to increase execution parallelism, and transaction read/write access hints can be used for additional concurrency.

Batch storage

During the parallel execution phase of the Aptos blockchain, write sets for all transactions in a group are generated. These write sets can be stored in memory, serving as a cache for subsequent blocks or sets of blocks to be executed. By caching the write sets in memory, overlapping writes only need to be written to stable storage once, reducing the number of storage operations. If a validator fails before storing the in-memory write sets, it can simply resume parallel execution from the block metadata ordering phase. This decoupling of write set batching from parallel execution ensures efficient operation and allows for resumption in case of failures. Batching write sets not only reduces storage operations but also enables more efficient and larger input/output (I/O) operations. The amount of memory allocated for write set caching can be manually configured on each machine, providing a natural back-pressure mechanism. This configuration allows for tuning the system based on specific I/O and memory environments. The granularity of the write set batches can also be adjusted independently from the granularity of parallel execution blocks, offering flexibility in optimizing the system’s performance and resource utilization.

At this stage of the pipeline, each validator has computed the updated state for a committed block of transactions. However, to support verified light clients and state synchronization effectively, the Aptos blockchain incorporates ledger certification for both the ledger history and the ledger state. Notably, ledger certification is not a critical step in transaction processing and can be performed separately, even if it is desired to be completely independent of the main process.

Perfectly Apt

With the advent of BlockSTM in the Aptos network, cross-node communications are touted to witness a surge of up to a whopping 160K TPS. Unlike Solana or Sui, there is no need to specify which data to access in a transaction. This novel approach toward transaction processing has helped Aptos generate significant traction from the developer community. Aptos’ recent partnerships with finance Goliaths such as Mastercard is signalling the dawn of a new era of idenity backed by Web3. Supported by an active and vibrant community, as well as a dedicated team, Aptos continues to deliver on its promises. We are witnessing the transformative power of Aptos firsthand, and we can’t wait to see what comes next! https://twitter.com/Aptos_Network/status/1658903134859837440

About Luganodes

Luganodes is a Swiss-operated institutional-grade non-custodial staking provider born out of Lugano Plan B Program, an initiative driven by Tether and the city of Lugano. Currently, they are the world’s fastest growing provider with AUM ~$700 million worth of staked assets live on 20+ PoS networks. Luganodes is one of the top validators on Polygon and Tron, making them the leading block producers in every ecosystem.

Luganodes is a verified staking provider with AAA ratings given by Staking Rewards, showcasing their expertise in blockchain infrastructure space amongst the world’s Top 5 verified providers.

If you hold the APT token, you can enhance your portfolio by staking to earn rewards. Leverage Luganodes' institutional-grade infrastructure to stake your holdings and create a passive income. Staking with us ensures ease of use, support, and safety while you earn, and also contribute to the security of the Aptos chain.

Learn how to stake APT tokens using this guide. You can learn more about staking on our website, and feel free to contact us for any queries!

About Luganodes

Luganodes is a world-class, Swiss-operated, non-custodial blockchain infrastructure provider that has rapidly gained recognition in the industry for offering institutional-grade services. It was born out of the Lugano Plan B Program, an initiative driven by Tether and the City of Lugano. Luganodes maintains an exceptional 99.9% uptime with round-the-clock monitoring by SRE experts. With support for 40+ PoS networks, it ranks among the top validators on Polygon, Polkadot, Sui, and Tron. Luganodes prioritizes security and compliance, holding the distinction of being one of the first staking providers to adhere to all SOC 2 Type II, GDPR, and ISO 27001 standards as well as offering Chainproof insurance to institutional clients.