In-depth Analysis of Public Chain Transaction Lifecycle: Technical Differences between Ethereum, Solana, and Aptos

Comparing the technical characteristics of different public chains can seem complex due to varying perspectives. To quickly and accurately understand the differences between Aptos and other public chains, it is crucial to choose the right analytical angle. This article will use the transaction lifecycle as a starting point, analyzing the complete steps from creation to final state update, including creation and initiation, broadcasting, ordering, execution, and state update, to gain a deeper understanding of the design ideas and technical trade-offs of each public chain.

Aptos: Optimistic Parallelism and High Performance Design

Aptos, as a public chain that emphasizes high performance, has a transaction lifecycle similar to Ethereum, but achieves significant performance improvements through its unique optimistic parallel execution and memory pool optimization.

Create and Initiate

The Aptos network consists of light nodes, full nodes, and validators. Users initiate transactions through light nodes, 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. The system pre-sorts based on rules (such as FIFO or Gas fees) to ensure that there are no conflicts during subsequent parallel execution. This design avoids the high hardware requirements of having to declare read/write sets in advance.

Sorting

Aptos uses the AptosBFT consensus, where the proposer cannot freely order transactions in principle. The memory pool pre-sorting has been completed in advance to avoid conflicts, and block generation relies more on the cooperation among validators.

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 are re-executed. This method leverages multi-core processors to enhance efficiency, with TPS reaching up to 160,000.

Status Update

Validator synchronization status, finality confirmed through checkpoints, with higher efficiency.

Aptos's core advantage 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 an important reference for public chain technology. Its transaction lifecycle provides a foundational framework for understanding other public chains.

Ethereum transaction lifecycle

• Creation and Initiation: Users initiate transactions through the wallet 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, submitting them to proposers after bidding on the relay layer.
• Execution: EVM serially processes transactions, updating the state in a single thread.
• Status Update: Blocks must be confirmed for finality through two checkpoints.

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

Solana: Deterministic Parallelism for Ultimate Optimization

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

Solana transaction lifecycle

• Create and Initiate: Users initiate transactions through their wallets.
• Broadcasting: No public memory pool, transactions are sent directly to the current and the next two proposers.
• Sorting: Proposers package blocks based on PoH, with a block time of only 400 milliseconds.
• Execution: The Sealevel virtual machine adopts deterministic parallel execution, requiring prior declaration of read and write sets to avoid conflicts.
• Status Update: BFT consensus rapid confirmation.

Solana does not use a memory pool, allowing nodes to quickly reach consensus on transaction order, eliminating the need for transactions to queue in the memory pool. 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 the declaration of read-write sets, has a lower node threshold, yet achieves a higher TPS.

Two paths of parallel execution: Aptos vs Solana

Parallel execution is divided into two modes: deterministic parallel execution and optimistic parallel execution. The difference lies in how to ensure that parallel transactions do not conflict.

• Deterministic Parallelism (Solana): The read and write sets must be declared before broadcasting the transaction. The Sealevel engine processes non-conflicting transactions in parallel based on the declaration, while conflicting transactions are executed serially.
• Optimistic Parallel (Aptos): Assuming no conflicts in transactions, Block-STM executes in parallel and then verifies. If there are conflicts, it retries. Pre-sorting in the memory pool reduces the risk of conflicts, resulting in a lighter load for nodes.

Optimistic parallel processing through the memory pool to complete conflict confirmation in advance.

Aptos's optimistic parallelism is not simply based on the assumption that transactions are conflict-free, but rather on proactively avoiding risks during the transaction broadcasting phase. Transactions are pre-sorted after entering the public memory pool to ensure that transactions within a block do not conflict when executed in parallel. This pre-sorting of transactions is key to Aptos's implementation of optimistic parallelism, eliminating the need to introduce a transaction declaration mechanism, thereby significantly reducing the performance requirements on nodes.

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

Aptos shows great potential in the RWA and stablecoin payment sectors:

• RWA: Aptos's Block-STM can process multiple asset transfer transactions in parallel, avoiding confirmation delays caused by network congestion. The modular design and security of the Move language allow developers to more easily build reliable RWA applications.
• Stablecoin Payments: Aptos's Move language prevents double spending through its resource model, ensuring the accuracy of every stablecoin transfer. Low Gas fees make it highly competitive in small payment scenarios.

Aptos's advantages in security lay a solid foundation for the RWA and PayFi narratives. In the future, Aptos can leverage these advantages to shape the "security-driven value network" narrative, becoming a bridge between the traditional economy and blockchain.

Summary: The technical differences of Aptos and future narratives

Aptos's design strikes a clever balance between performance and security. Its memory pool pre-sorting combined with Block-STM's optimistic parallelism not only lowers the node threshold but also achieves a high throughput of 160,000 TPS. This "seeking speed while maintaining stability" approach, along with the resource model of the Move language, endows Aptos with higher security.

Aptos demonstrates tremendous potential in the RWA and PayFi narratives. In the RWA sector, Aptos's high throughput supports large-scale asset on-chain. In PayFi and stablecoin payments, Aptos's low cost, high efficiency, and compliance support micropayments and cross-border settlements, making it a strong candidate for "next-generation payment infrastructure."

In the future, Aptos can connect traditional finance and the blockchain ecosystem with the narrative of a "security-driven value network," continuously strengthening its efforts in the RWA and PayFi fields, and building a new public chain landscape that combines trust and scalability.