In-Depth Understanding of the Differences in Public Chain Technology: A Transaction Lifecycle Perspective

Comparing the technical characteristics of different public chains can seem complex due to varying perspectives. To quickly and accurately grasp the differences between public chains, it is crucial to choose the right entry point.

This article will take the lifecycle of a transaction as a starting point to analyze the complete process from creation to final status update, including five steps: creation and initiation, broadcasting, sorting, execution, and status update. This approach clearly demonstrates the design thinking and technical trade-offs of public blockchains. Based on this, we can understand the core concepts of different public blockchains and explore how to develop market-attractive applications on specific public blockchains.

All blockchain transactions revolve around these five steps. This article will focus on analyzing the unique design of Aptos and compare it with Ethereum and Solana.

Aptos: Optimistic Concurrency and High-Performance Design

Aptos is a high-performance public chain that, although its transaction lifecycle is similar to that of Ethereum, achieves significant performance improvements through unique optimistic parallel execution and memory pool optimization. The key steps in the Aptos transaction lifecycle are as follows:

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, whose 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 no conflicts during subsequent parallel execution. This design avoids the high hardware requirements of needing to declare read/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 delayed transactions. The memory pool pre-sorting has been completed in advance to avoid conflicts, and block generation relies more on collaboration 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: A Benchmark for Serial Execution

As the pioneer of smart contracts, Ethereum is the origin of public chain technology, and its transaction lifecycle provides a foundational framework for understanding 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 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.

• Execution: EVM processes transactions serially, updating the state in a single thread.

• Status update: Blocks must pass two checkpoints to confirm finality.

Ethereum's serial execution and memory pool design limit its performance, with a block time of 12 seconds per slot and 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 notably different from Aptos, especially in terms of the memory pool 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 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.

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, eliminating the need for transactions to queue in a memory pool, allowing transactions to be almost instantly completed. However, this also means that during network overload, transactions may be dropped rather than waiting, and users must resubmit them.

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

Two Paths of Parallel Execution: Aptos vs Solana

The execution of a transaction represents the update of the blockchain state, which is the process of converting the transaction initiation command into a definitive state. Nodes assume the transaction is successful and calculate its impact on the network state; this calculation process is known as execution.

Parallel execution in blockchain refers to the process of multi-core processors simultaneously computing the network state. Currently, parallel execution in the market is divided into two methods: 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.

The timing of determining conflicts in parallel transaction dependencies distinguishes between the two development directions of deterministic parallel execution and optimistic parallel execution. Aptos and Solana have chosen different directions:

• Deterministic parallelism (Solana): The read-write set must be declared before broadcasting transactions. 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 Concurrency (Aptos): Assumes no conflicts in transactions, Block-STM executes in parallel and verifies afterward; if there is a conflict, it retries. Pre-sorting the memory pool reduces the risk of conflicts, leading to a lighter load on nodes.

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 them in order; Aptos, upon discovering insufficient balance after parallel execution, adjusts accordingly. 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 does not need to submit a transaction declaration before executing the transaction. 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 dependencies of the transaction are not confirmed in advance for conflicts, a large number of errors may occur during the actual execution, leading to congestion in the operation of the public chain. Therefore, optimistic concurrency is not simply assuming that there are no conflicts in transactions, but rather it mitigates risks in advance at a certain stage, which is the transaction broadcasting stage.

On Aptos, after transactions enter the public mempool, they are 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 the proposers in Aptos 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 realization of optimistic parallelism. Unlike Solana, which needs to introduce transaction declarations, Aptos does not require this mechanism, thus significantly reducing the performance requirements for nodes. In terms of ensuring that transactions do not conflict, the impact of the mempool on TPS in Aptos is much smaller than the cost of introducing transaction declarations in Solana. Therefore, Aptos's TPS can reach 160,000, more than double that of Solana.

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

RWA

The advantages of Aptos in the RWA field:

• Block-STM can process multiple asset transfer transactions in parallel, 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 Move language facilitate the construction of reliable RWA applications.
• A combination of security and performance, suitable for collaboration with traditional financial institutions to put high-value assets on the blockchain.

Aptos's progress in the RWA field:

• In July 2024, introducing USDY from Ondo Finance, with a market cap of approximately 15 million USD.
• In October 2024, Franklin Templeton launched the BENJI token on Aptos.
• Collaborate with Libre to promote the tokenization of securities and bring multiple investment funds on-chain.

stablecoin payment

Aptos's advantages in the stablecoin payment sector:

• The Move language prevents double spending through a resource model, ensuring transaction accuracy.
• Low Gas fees make it competitive in small payment scenarios.
• The memory pool pre-sorting and Block-STM ensure the stability and low latency of payment transactions.
• AptosBFT's decentralized consensus reduces centralization risks while supporting embedded KYC/AML checks.

The potential of Aptos in the PayFi and stablecoin payment sectors:

• Promote the large-scale adoption of stablecoins and create a cross-border payment network.
• Collaborate with payment giants to develop an on-chain settlement system.
• Supports micropayment scenarios, such as real-time tipping for content creators.

Summary: The Technical Differences of Aptos and Future Narrative

Aptos's design strikes a balance between performance and security. 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. This "seeking speed while maintaining stability" approach, along with the resource model of the Move language, grants Aptos higher security.

Aptos has shown great potential in the RWA and PayFi narratives. In the RWA field, Aptos's high throughput supports large-scale asset onboarding and has collaborated with multiple financial institutions. In PayFi and stablecoin payments, Aptos's low cost, high efficiency, and compliance support micropayments and cross-border settlements.

In the future, Aptos can leverage the narrative of "security-driven value networks" to connect traditional finance with the blockchain ecosystem, continuously making strides in the RWA and PayFi fields, and build a new public chain landscape that combines trust and scalability.