In-Depth Analysis of the Transaction Lifecycle: Technical Differences between Ethereum, Solana, and Aptos

Comparing the differences in blockchain technology may seem tedious due to varying analytical perspectives. To quickly and accurately understand the distinctions between different public chains, choosing the right entry point is crucial. This article will analyze the complete steps of a transaction's lifecycle, from creation to final state update, including creation and initiation, broadcasting, ordering, execution, and state update, in order to grasp the design philosophy and technical trade-offs of each public chain.

All blockchain transactions revolve around these five steps. This article will focus on Aptos, analyzing its unique design and comparing the key differences with Ethereum and Solana.

Aptos: Optimistic Concurrency and High-Performance Design

Aptos is a high-performance public chain that emphasizes transaction lifecycle similar to Ethereum, but achieves significant improvements through unique optimistic parallel execution and memory pool optimization. The following are the key steps in the transaction lifecycle on Aptos:

Create and Initiate

The Aptos network consists of light nodes, full nodes, and validators. Users initiate transactions through light nodes ( such as wallets or applications ), and the light nodes forward the transactions to nearby full nodes, which then synchronize with the validators.

broadcast

Aptos retains a memory pool, but memory pools do not share after QuorumStore. Unlike Ethereum, its memory pool is not just a transaction buffer. After a transaction enters the memory pool, the system pre-sorts it based on rules ( such as FIFO or Gas fees ) to ensure that there are no conflicts when transactions are executed in parallel afterward. This design avoids the high hardware requirements of Solana that need to declare read and write sets in advance.

sorting

Aptos adopts the AptosBFT consensus, where proposers cannot freely order transactions. AIP-68 grants proposers the additional right to fill in delayed transactions. The memory pool pre-sorting has been completed in advance to avoid conflicts, and block generation relies more on cooperation among validators rather than being led by proposers.

execute

Aptos uses Block-STM technology to achieve optimistic parallel execution. Transactions are assumed to be conflict-free and processed simultaneously; if a conflict is detected after execution, the affected transactions will be re-executed. This method leverages multi-core processors to enhance efficiency, with a TPS of up to 160,000.

Status Update

Validator synchronization status, finality confirmed through checkpoints, similar to Ethereum's Epoch mechanism, but more efficient.

The core advantage of Aptos lies in the combination of optimistic parallelism and memory pool pre-sorting, which reduces node performance requirements while significantly increasing throughput.

Ethereum: Benchmark for Serial Execution

Ethereum, as the pioneer of smart contracts, is the origin of public chain technology, and its transaction lifecycle provides a foundational framework for understanding Aptos.

Ethereum transaction lifecycle

• Creation and Initiation: Users initiate transactions through their wallets via relay gateways or RPC interfaces.

• Broadcast: The transaction enters the public memory pool, waiting to be packaged.

• Sorting: After the PoS upgrade, block builders package transactions based on the principle of profit maximization, and submit them to the proposer after bidding in the relay layer.

• Execute: EVM serial processing transactions, single-threaded state update.

• Status update: The block must be confirmed by two checkpoints for finality.

The serial execution and memory pool design of Ethereum limits performance, with a block time of 12 seconds per slot and low TPS. In contrast, Aptos has achieved a qualitative leap through parallel execution and memory pool optimization.

Solana: Extreme Optimization of Deterministic Parallelism

Solana is known for its high performance, and its transaction lifecycle is significantly different from Aptos, especially in terms of memory pool and execution methods.

Solana transaction lifecycle

• Create and Initiate: Users initiate transactions through their wallets.

• Broadcast: No public memory pool, transactions are sent directly to the current and the next two proposers.

• Sorting: Proposers package blocks based on PoH(Proof of History), with block time only 400 milliseconds.

• Execution: The Sealevel virtual machine adopts deterministic parallel execution and requires the read and write sets to be declared in advance to avoid conflicts.

• Status Update: BFT consensus quick confirmation.

The reason Solana does not use a memory pool is that it could become a performance bottleneck. Without a memory pool and with Solana's unique PoH consensus, nodes can quickly reach consensus on transaction order, avoiding the need for transactions to queue in a memory pool, allowing transactions to be executed almost instantly. However, this also means that during network congestion, transactions may be discarded rather than waiting, and users need to resubmit.

In contrast, Aptos's optimistic parallelism does not require the declaration of read-write sets, has a lower node threshold, and yet achieves higher TPS.

Two Paths of Parallel Execution: Aptos vs Solana

The execution of a transaction represents an update to the block state and is the process of transforming the transaction initiation instruction into a state with finality. How should this change be understood? Nodes assume the transaction is successful and calculate its impact on the network state; this calculation process is the execution.

Therefore, parallel execution in blockchain refers to the process of multi-core processors simultaneously calculating the network state. In the current market, parallel execution is divided into two types: deterministic parallel execution and optimistic parallel execution. The difference between these two development directions lies in how to ensure that parallel transactions do not conflict—that is, whether there are dependencies between transactions.

It can be seen that the timing of determining the dependencies of concurrent transaction conflicts during the transaction lifecycle determines the divergence between deterministic parallel execution and optimistic parallel execution. Aptos and Solana have chosen different directions:

• Deterministic parallelism ( Solana ): Before broadcasting transactions, the read-write set must be declared. The Sealevel engine processes non-conflicting transactions in parallel based on the declaration, while conflicting transactions are executed serially. The advantage is efficiency, while the disadvantage is high hardware requirements.

• Optimistic parallel ( Aptos ): Assuming transactions have no conflicts, Block-STM performs validation after parallel execution; if there are conflicts, it will retry. Pre-sorting in the memory pool reduces conflict risks, making the node's burden lighter.

For example: Account A has a balance of 100, transaction 1 transfers 70 to B, transaction 2 transfers 50 to C. Solana confirms conflicts in advance through declarations and processes them in order; Aptos, after parallel execution, readjusts if it finds insufficient balance. The flexibility of Aptos makes it more scalable.

Optimistic parallelism to complete conflict confirmation in advance through memory pool

The core idea of optimistic concurrency is to assume that transactions processed in parallel will not conflict, so the application side does not need to submit transaction declarations before transaction execution. If a conflict is found during validation after transaction execution, Block-STM will re-execute the affected transactions to ensure consistency.

However, in practice, if the transaction dependencies are not confirmed in advance for conflicts, a large number of errors may occur during the actual execution, leading to congestion in the public chain. Therefore, optimistic parallelism is not simply assuming that transactions have no conflicts, but rather avoiding risks in advance at a certain stage, which is the transaction broadcasting stage.

On Aptos, once a transaction enters the public memory pool, it is pre-sorted according to certain rules ( such as FIFO and Gas fees ) to ensure that transactions within a block do not conflict during parallel execution. It can be seen that Aptos's proposers do not actually have the ability to sort transactions, and there are no block builders in the network. This pre-sorting of transactions is key to Aptos's implementation of optimistic parallelism. Unlike Solana, which needs to introduce transaction declarations, Aptos does not require this mechanism, significantly reducing the performance requirements for nodes. In terms of ensuring no conflicts in transaction-related network overhead, the impact of the memory pool on Aptos's TPS is much less than the cost of introducing transaction declarations in Solana. Therefore, Aptos's TPS can reach 160,000, which is more than double that of Solana.

The narrative based on security is the development direction of Aptos.

RWA

Aptos is actively advancing the tokenization of real assets and institutional financial solutions. Compared to Ethereum, Aptos's Block-STM can process multiple asset transfer transactions in parallel, avoiding the confirmation delays caused by network congestion. On some public chains, although the transaction speed is fast, the lack of a memory pool design may result in the loss of transactions during network overload, affecting the stability of RWA confirmation. Aptos's memory pool pre-sorting ensures that transactions enter execution in order, maintaining the reliability of asset records even during peak periods. RWA requires complex smart contract support, such as asset segmentation, revenue distribution, and compliance checks. The modular design and security of the Move language allow developers to more easily build reliable RWA applications. In contrast, the complexity of programming languages and vulnerability risks on other public chains increase development costs or impose higher learning curve requirements on developers. Aptos's ecological friendliness is expected to attract more RWA projects to land, forming a positive cycle. The potential of Aptos in the RWA field lies in the combination of security and performance. In the future, it can focus on collaborating with traditional financial institutions to bring high-value assets like bonds and stocks on-chain, leveraging the Move language to create a strong compliance tokenization standard. This "security + efficiency" narrative can enable Aptos to stand out in the RWA market.

In July 2024, Aptos officially announced the integration of Ondo Finance's USDY into its ecosystem, and it was integrated into major DEXs and lending applications. As of March 10, the market value of USDY on Aptos was approximately $15 million, accounting for about 2.5% of USDY's total market value. In October 2024, Aptos announced that Franklin Templeton had launched a U.S. government money market fund represented by the BENJI token on the Aptos Network (FOBXX). In addition, Aptos partnered with Libre to promote the tokenization of securities, bringing on-chain investment funds from Brevan Howard, BlackRock, and Hamilton Lane to enhance access for institutional investors.

stablecoin payment

Stablecoin payments need to ensure the finality of transactions and the security of assets. Aptos's Move language prevents double spending through a resource model, ensuring the accuracy of each stablecoin transfer. For example, when users pay with USDC on Aptos, the transaction state updates are strictly protected to avoid loss of funds due to contract vulnerabilities. In addition, Aptos's low Gas fees ( benefit from high TPS shared costs ), making it highly competitive in small payment scenarios. Ethereum's high Gas fees limit its payment applications, while some public chains have low costs, the risk of transaction drops during network congestion may affect user experience. Aptos's mempool pre-sorting and Block-STM ensure the stability and low latency of payment transactions.

PayFi and stablecoin payments need to balance decentralization and regulatory compliance. AptosBFT's decentralized consensus reduces centralization risk, while its modular architecture supports developers in embedding KYC/AML checks. For example, a stablecoin issuer can deploy compliance contracts on Aptos to ensure transactions comply with local regulations without sacrificing network efficiency. This is superior to the centralized relay models of certain public chains and addresses potential compliance shortcomings dominated by other public chain proposers. Aptos's balanced design makes it more suitable for financial institutions to enter the market.

Aptos's potential in the PayFi and stablecoin payment sectors lies in the "security, efficiency, and compliance" trinity. In the future, it will continue to promote the large-scale adoption of stablecoins, build cross-border payment networks, or collaborate with payment giants to develop on-chain settlement systems. High TPS and low costs can also support micro-payment scenarios, such as real-time tipping for content creators. The narrative of Aptos can focus on "next-generation payment infrastructure" to attract dual traffic from enterprises and users.

The advantages of Aptos in terms of security—memory pool pre-sorting, Block-STM, AptosBFT, and the Move language—not only enhance its resistance to attacks but also lay a solid foundation for the RWA and PayFi narratives. In the RWA field, its high security and throughput support asset tokenization and large-scale transactions; in PayFi and stablecoin payments, low costs and efficiency drive real-world applications. Compared to the robustness of other public chains.