Aptos adopts a novel approach to transaction flow by separating, pipelining, batching, and parallel execution into separate, independent stages. This design maximizes throughput and resource use while reducing complexity. This also improves development cycles, as each stage can be developed as its own distinct entity rather than as a tightly interwoven structure.
Although the ledger’s written state of the LEDGER is temporarily paused during the ordering and batching process, the transaction execution and dissemination are continuously performed by the validators in the background. This means that even though the ledger's state is momentarily paused, transactions are still being processed and disseminated by validators.
Additionally, Aptos requires that all transactions undergo sequencing, regardless of whether they interact with the same assets or not. This means that even if multiple transactions don't have any interactions with one another, they'll still be temporarily paused to be written to the ledger in the same batch of transactions. This approach helps to maintain the universal ledger’s integrity while ensuring transactions are recorded in a consistent and accurate manner.
Source: Aptos white paper
Another noteworthy aspect of Aptos’ unique design approach is the decoupling of the consensus phase from non-agreement tasks, such as transaction dissemination and execution. This reduces operational complexity and allows block metadata and proof ordering to function effectively with lower bandwidth requirements compared to existing models. The result of this design is an increase in network throughput and a reduction in latency.
What is Parallel Execution?
Parallel execution in cryptocurrency refers to the ability to process and execute multiple transactions simultaneously rather than sequentially. In traditional cryptocurrencies, such as Bitcoin and Ethereum, transactions are executed one after the other in a linear order to ensure that one transaction’s outcome does not conflict with the next. Parallel execution is a way to increase a cryptocurrency network’s scalability and can help to reduce latency and improve network performance.
In a parallel execution setup, multiple transactions are grouped together and processed in parallel by different validators on the network. This helps the network to handle a higher TPS, allowing for increased throughput and scalability. To ensure that the transactions are processed in the correct order, the blockchain network may implement consensus algorithms and protocols to establish the transaction order and reach agreement between all participating validators.
Aptos uses parallel execution to achieve a theoretically limitless capacity for scaling network throughput, particularly as demand and use grow. The testnet’s transactional output currently stands at around 4,000 TPS, but Aptos Labs intends to maximize the network’s potential to an estimated 100k+ TPS. This raises questions about how Aptos maintains consensus in regard to transaction order and how it differentiates between independent and conflicting transactions.
Block-STM Technology
Aptos uses a smart contract parallel execution engine called Block-STM that uses software transactional memory to apply database transaction properties that satisfy ACID properties. This allows Aptos to distinguish itself by identifying dependencies without the need for transactions to explicitly state the memory locations that they use. In Block-STM, independent transactions are in a pre-defined order and split into multiple threads that are all executed in parallel. This is similar to Solana’s implementation of Sealevel, another parallel execution engine.
Source: Aptos Whitepaper
There are three main components that makeup Block-STM.:
- Optimistic Concurrency Control
- Dynamic Dependency Estimation
- Collaborative Scheduler
The first of these is Optimistic Concurrency Control, a method that enables multi-thread execution with a very rare probability of conflict. It works by executing transactions in parallel and then rolling back and re-performing the process if any conflicts arise during validation. The final output results in a block commit and the process starts over again. This is similar to optimistic rollups, where the assumption is that the transactions are executed first under the assumption that they're correct but hold the ability to correct the process if there's a problem.
The second core component of Block-STM is Dynamic Dependency Estimation. This works to quickly detect validation errors to minimize any system inefficiencies. It also works to establish guidelines for committing blocks to the chain. If the component detects an issue in a transaction, that transaction is isolated and tagged as an ESTIMATION and it's temporarily skipped. The validation process continues with other confirmed transactions to avoid system redundancies and downtime.
Source: Aptos Whitepaper
The final component is the Collaborative Scheduler, which holds the duties of allocating validation and execution responsibilities to transaction threads. In other words, the Collaborative Scheduler is responsible for pre-defining the order of transaction execution. Together, these components work together to maximize transaction throughput and block validation efficiency while ensuring that the system isn't vulnerable to errors.
The use of Block-STM leads to improved performance when using multiple processor cores, with the magnitude of the speed up depending on the level of interdependence between transactions. The Aptos team's research has shown that an 800% improvement in execution speed can be achieved with 32 cores in cases of high interdependence and a 16x improvement in cases of low interdependence. In the instance where all transactions within a block are dependent, Block-STM results in a minor decrease in performance compared to sequential execution.
