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

Comparing the technical differences between different public chains can seem tedious due to varying perspectives. To quickly and accurately understand the differences between Aptos and other public chains, it is crucial to choose the right entry point. This article will analyze the complete steps of a transaction from creation to final state update based on the transaction lifecycle, including creation and initiation, broadcasting, ordering, execution, and state updating, 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 between Ethereum and Solana.

Aptos: Optimistic Concurrency and High-Performance Design

Aptos is a high-performance public chain that has a 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 ), which forward the transactions to nearby full nodes, and the full nodes then synchronize with the validators.

broadcast

Aptos retains the memory pool, but the memory pools do not share after QuorumStore. Unlike Ethereum, its memory pool is not just a transaction buffer. After transactions enter the memory pool, the system pre-sorts them based on rules ( such as FIFO or Gas fees ) to ensure that transactions do not conflict during subsequent parallel execution. 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 are generally unable to freely order transactions. AIP-68 grants proposers the additional right to fill in delayed transactions. The pre-sorting of the memory pool 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 discovered 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

The validator sync status, finality is 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 not only reduces the performance requirements of nodes but also significantly increases 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 fundamental 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 has entered the public memory pool, waiting to be packed.

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

• Execution: EVM serial processing transactions, single-threaded state updates.

• Status Update: Blocks must be confirmed finality through two checkpoints.

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

Solana: Ultimate 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 pools and execution methods.

Solana transaction lifecycle

• Create and Initiate: Users initiate transactions through the wallet.

• 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 of only 400 milliseconds.

• Execution: The Sealevel virtual machine adopts deterministic parallel execution and requires prior declaration of read and write sets to avoid conflicts.

• Status Update: BFT consensus rapid 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 the order of transactions, 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 overload, transactions may be discarded rather than waiting, and users need to resubmit.

In contrast, Aptos's optimistic concurrency does not require declaring read-write sets, has a lower node threshold, yet achieves a higher TPS.

Two Paths of Parallel Execution: Aptos vs Solana

The execution of a transaction represents an update to the block state; it is the process of transforming the transaction initiation instruction into a final state. How should this change be understood? The node assumes the transaction is successful and calculates 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 computing the network state. In the current market, parallel execution is divided into two types: deterministic parallel execution and optimistic parallel execution. The differences between these two development directions stem from how to ensure that parallel transactions do not conflict—that is, whether there is a dependency relationship between the transactions.

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

• Deterministic parallel ( Solana ): Before broadcasting transactions, it is necessary to declare the read and write sets. The Sealevel engine processes non-conflicting transactions in parallel based on the declarations, while conflicting transactions are executed serially. The advantage is efficiency, and the disadvantage is high hardware requirements.

• Optimistic Parallel ( Aptos ): Assume transactions are conflict-free, Block-STM validates after parallel execution, and if there is a conflict, it retries. Pre-sorting the memory pool reduces conflict risks, making the burden on nodes lighter.

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

Optimistic parallel completion of conflict confirmation 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 a transaction declaration before transaction execution. If a conflict is found during verification 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 actual execution, leading to a slowdown in the operation of the public chain. Therefore, optimistic concurrency does not simply assume that there are no conflicts in transactions, but rather avoids 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 like FIFO and Gas fees ( to ensure that transactions within a block do not conflict during parallel execution. This indicates that the proposer in Aptos does not actually have transaction sorting capability, and there are no block builders in the network. This pre-sorting of transactions is key to Aptos achieving optimistic parallelism. Unlike Solana, which requires transaction declarations, Aptos does not need this mechanism, thus significantly reducing the performance requirements for nodes. Regarding the network overhead to ensure transaction non-conflict, the impact of adding a memory pool on TPS in Aptos is far less than the cost incurred by Solana's introduction of transaction declarations. Therefore, Aptos's TPS can reach 160,000, more than double that of Solana. The effect of transaction pre-sorting increases the difficulty of capturing MEV on Aptos, which has both pros and cons for users, and this will not be elaborated further here.

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

) RWA

Aptos is actively advancing the tokenization of real-world assets and institutional financial solutions. Compared to Ethereum, Aptos's Block-STM can process multiple asset transfer transactions in parallel, avoiding delays in rights confirmation caused by network congestion. On certain public chains, although transaction speeds are fast, the lack of a memory pool design may lead to transaction drops during network overload, affecting the stability of rights confirmation for RWAs. Aptos's memory pool pre-sorting ensures that transactions enter execution in order, maintaining the reliability of asset records even during peak periods. RWAs require complex smart contract support, such as asset fragmentation, 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 programming languages of other public chains may have complexities and vulnerability risks, increasing development costs. Aptos's eco-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 such as bonds and stocks on-chain, leveraging the Move language to create strong compliance standards for tokenization. This "security + efficiency" narrative can help Aptos stand out in the RWA market.

In July 2024, Aptos officially announced the introduction of USDY from a certain financial institution into its ecosystem, integrating it into major DEXs and lending applications. As of March 10, the market capitalization of USDY on Aptos was approximately 15 million USD, accounting for about 2.5% of the total market capitalization of USDY. In October 2024, Aptos announced that a certain asset management company had launched an on-chain U.S. government money market fund represented by the BENJI token on the Aptos Network ###FOBXX(. Additionally, Aptos is collaborating with a certain company to promote the tokenization of securities, bringing multiple investment funds from various investment institutions on-chain 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 status updates are strictly protected to avoid fund loss due to contract vulnerabilities. Additionally, Aptos's low gas fees ### benefit from high TPS that spreads costs (, making it highly competitive in small payment scenarios. The high gas fees of certain public chains limit their payment applications, while others may have low costs but the risk of transaction drops during network overload can 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 with regulatory compliance. The decentralized consensus of AptosBFT reduces centralized risks, 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 model of some public chains and compensates for 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 drive the large-scale adoption of stablecoins, create cross-border payment networks, or collaborate with payment giants to develop on-chain settlement systems. High TPS and low costs can also support micropayment scenarios, such as real-time rewards for content creators. The narrative of Aptos can focus on "next-generation payment infrastructure," attracting dual traffic from businesses and users.

![Understanding the Main Differences between Ethereum, Solana, and Aptos in the Lifecycle of a Transaction])https://img-cdn.gateio.im/webp-social/moments-99c993e92d55b0fc27ffb530d2bce05b.webp(

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 field of RWA, its high security and throughput support asset tokenization and large-scale transactions; in PayFi and stablecoins.