In-depth Understanding of Public Chain Transaction Lifecycle: Key Differences Between Ethereum, Solana, and Aptos

When analyzing the differences in public chain technology, choosing the right entry point is crucial. The lifecycle of a transaction provides an ideal perspective to clearly grasp the design ideas and technical trade-offs of different public chains. This article will focus on the five key steps of transaction creation, broadcasting, sorting, execution, and state updating, with an emphasis on analyzing Aptos's unique design and comparing it with Ethereum and Solana.

Aptos: Optimistic Concurrency and High-Performance Design

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

Create and Initiate

The Aptos network is composed of light nodes, full nodes, and validators. Users initiate transactions through light nodes, which are forwarded to validators via full nodes.

broadcast

Aptos retains the memory pool, but the memory pools no longer share after QuorumStore. The system pre-sorts transactions based on preset rules (such as FIFO or Gas fees) to prepare for subsequent parallel execution.

sorting

Aptos adopts the AptosBFT consensus mechanism. The ordering authority of the proposer is limited and mainly relies on the collaboration among validators to complete block generation.

execute

Aptos uses Block-STM technology to achieve optimistic parallel execution. Transactions are assumed to be conflict-free and are processed simultaneously; if a conflict is detected, the affected transactions are re-executed. This approach fully utilizes multi-core processors, achieving a TPS of 160,000.

Status Update

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

Aptos's core advantage lies in the combination of optimistic parallelism and memory pool pre-sorting, which not only reduces the performance requirements for nodes but also significantly enhances throughput.

Ethereum: Benchmark for Serial Execution

Ethereum, as a pioneer of smart contracts, provides a basic framework for understanding the transaction lifecycle of other public chains.

Ethereum transaction lifecycle

• Creation and Initiation: Users initiate transactions through wallets via relay gateways or RPC interfaces.
• Broadcast: The transaction enters the public memory pool waiting to be packed.
• Sorting: Block builders package transactions based on the principle of profit maximization and submit them to proposers after bidding in the relay layer.
• Execution: EVM processes transactions serially, 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 limit its performance, with a block time of 12 seconds per slot and a relatively low TPS.

Solana: Ultimate Optimization of Deterministic Parallelism

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

Solana transaction lifecycle

• Create and Initiate: Users initiate transactions through their 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 a block time of only 400 milliseconds.
• Execution: The Sealevel virtual machine uses deterministic parallel execution and requires the declaration of read and write sets in advance to avoid conflicts.
• Status update: BFT consensus rapid confirmation.

Solana abandons the memory pool to improve performance, but this may lead to transaction loss when the network is overloaded, requiring users to resubmit. In contrast, Aptos's optimistic concurrency does not require declaring read-write sets, lowering the threshold for nodes while achieving higher TPS.

Two Paths of Parallel Execution: Aptos vs Solana

Parallel execution is divided into two ways: deterministic parallelism and optimistic parallelism, with the core difference being how to handle potential conflicts between transactions.

• Deterministic Parallelism (Solana): The read and write set must be declared before broadcasting the transaction, and the Sealevel engine processes non-conflicting transactions in parallel, while conflicting transactions are executed serially.
• Optimistic Concurrency (Aptos): Assuming transactions have no conflicts, Block-STM executes in parallel and then verifies. If there are conflicts, it will retry. Pre-sorting in the memory pool reduces the risk of conflicts.

Aptos's optimistic parallel solution offers greater flexibility and scalability, with stronger adaptability.

Optimistic parallel conflict confirmation completed in advance through the memory pool

The optimistic parallelism of Aptos is not merely based on the assumption that transactions are conflict-free, but rather it mitigates risks in advance through pre-sorting in the memory pool during the broadcast phase. This design allows Aptos to avoid introducing a complex transaction declaration mechanism, reducing the performance requirements for nodes while ensuring high TPS.

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

RWA (Real World Assets)

Advantages of Aptos in the RWA field:

• Block-STM supports parallel processing of multiple asset transfers, avoiding confirmation delays caused by network congestion.
• The memory pool pre-sorting ensures that transactions are executed in order, maintaining the reliability of asset records.
• The modular design and security of the Move language facilitate the development of complex RWA applications.

Aptos has partnered with institutions such as Ondo Finance, Franklin Templeton, and Libre to promote asset tokenization and fund on-chain.

stablecoin payment

Advantages of Aptos in the payment field:

• The resource model of Move language prevents double spending and ensures transaction security.
• Low Gas fees are suitable for small payment scenarios.
• The memory pool pre-sorting and Block-STM ensure the stability and low latency of payment transactions.
• AptosBFT consensus and modular architecture support developers in embedding compliance checks.

Aptos has the potential to become the "next-generation payment infrastructure," supporting scenarios such as cross-border payments and micropayments.

Summary: The Technical Differences of Aptos and Future Narratives

Aptos achieves a balance between performance and security in the design of its transaction lifecycle. Its memory pool pre-sorting combined with Block-STM's optimistic parallelism lowers the node threshold while achieving a high throughput of 160,000 TPS. Compared to Ethereum, Solana, and Sui, Aptos has found a unique position in terms of security, performance, and versatility.

Based on the combination of security and high performance, Aptos shows great potential in the RWA and PayFi fields. In the future, Aptos can leverage the narrative of "security-driven value network" to connect traditional finance with the blockchain ecosystem, continuously making efforts in the RWA and PayFi fields, and building a new pattern of public chain that combines trust and scalability.