---
# System prepended metadata

title: 'Aptos Architecture Deep Dive: Consensus, Execution, and Storage'

---

Aptos Architecture Deep Dive: Consensus, Execution, and Storage
===============================================================

Introduction
------------

Aptos is a high-performance Layer-1 blockchain launched in 2022 by the former Meta Diem team.  
Written in Rust, Aptos is designed around **low latency**, **high throughput**, and **strong safety guarantees**, targeting use cases such as real-time trading, payments, and on-chain financial infrastructure 

Aptos overview

|     |     |     |     |
| --- | --- | --- | --- |
| Network Performance | Network Scale | On-Chain Activity | User Cost & Accessibility |
| Live TPS: ~50<br><br>Historical Peak TPS:  22,000+<br><br>Testnet Peak TPS:  30,000+  <br>Finality: Sub-second<br><br>Block Time: ~70ms | Active Validators: ~140<br><br>Geographic Coverage: 23+ countries, 54+ cities<br><br>Network Reliability: High global distribution | Total Accounts: 110M<br><br>Daily Active Users Peak: 15M+<br><br>Smart Contracts Deployed: 3,000+<br><br>Stablecoin Flows: Weekly inflows peaked at $1.58B | Average Gas Fee: ~$0.001 – $0.01 per transaction<br><br>User Experience: Consistently low fees even during high network load |


Rather than optimizing a single component, Aptos takes a **full-stack approach**, rethinking:

-   Consensus and ordering  
-   Execution and parallelism   
-   Storage and state scalability   
-   Account and asset models
    

This post provides a **system-level overview** of the Aptos on-chain architecture, focusing on **consensus, execution, and storage**, with an emphasis on _why_ these design choices matter.

---

High-Level Architecture
-----------------------

At a high level, an Aptos validator is organized as a **modular pipeline**:

`Clients -> P2P Network  -> Mempool & Data Availability ->Consensus (Ordering) ->Execution-> Storage`

Each layer is designed to scale independently and to pipeline with others, enabling sub-second finality and high throughput under load 

![image](https://hackmd.io/_uploads/HkJQfvLQWe.png)



---

Consensus Layer: From Batches to Finality
-----------------------------------------

### Transaction Flow Overview

In Aptos, consensus is not just about blocks—it is about **ordering transaction batches with strong availability guarantees**.

The simplified flow is:

`Mempool   → Quorum Store (batching + availability)   → Consensus (ordering)   → Execution`

This separation allows Aptos to decouple **data availability** from **ordering**, which is critical for scalability 

![image](https://hackmd.io/_uploads/H1QWGD87Zg.png)
---

### Quorum Store: Data Availability First

**Quorum Store (QS)** replaces traditional leader-centric mempools.

Each validator:

-   Locally batches transactions    
-   Broadcasts batch metadata  
-   Collects **2f+1 signatures** to form an _availability proof_
    

Only batches that reach quorum are eligible for ordering.

Key properties:

-   No single leader bottleneck   
-   Data availability is guaranteed _before_ ordering   
-   Validators vote on **batch IDs**, not raw transactions
    

Internally, batch references form a **DAG across rounds**, which consensus later linearizes 

Aptos overview

.

---

### Raptr & VelociRaptr: Prefix Consensus

Aptos’s latest consensus generation is **Raptr**, with **VelociRaptr** as an optimized pipeline version.

Instead of committing blocks one-by-one, Raptr introduces **Prefix Consensus**:

-   Validators propose blocks that reference batch IDs 
-   Validators vote    
-   From overlapping votes, a **common prefix** is extracted    
-   This prefix is _immediately finalized_
    

Important implications:

-   Finality does **not** wait for a specific block    
-   Uncommitted tail blocks can be discarded safely    
-   Prefixes **never roll back**, thanks to quorum intersection
    

VelociRaptr further pipelines:

-   Proposal    
-   Voting    
-   Ordering   
-   Execution
    

This reduces block proposal time to the **tens of milliseconds range** (proposal time, not full network latency) 

Aptos overview

.

---

Execution Layer: Parallelism as a First-Class Citizen
-----------------------------------------------------

The execution layer is where Aptos gains most of its raw throughput.

### Core Components

-   **Move VM** – secure, resource-oriented virtual machine    
-   **Block-STM** – optimistic parallel execution engine   
-   **Shardines** – sharded execution (early stage)
    

 

Aptos overview

---

### Block-STM: Optimistic Parallel Execution

Block-STM executes transactions **in parallel**, assuming conflicts are rare:

1.  Transactions are executed concurrently across threads    
2.  Each transaction tracks its read/write set    
3.  Conflicts are detected after execution    
4.  Conflicting transactions are selectively re-executed   
5.  Final commit order is deterministic
    

Key advantages:

-   Near-linear scaling with CPU cores    
-   No need for developers to declare access lists    
-   Deterministic results across all validators
    

This design is especially effective for heterogeneous workloads (DeFi, payments, gaming) 

Aptos overview

.

---

### Shardines: Scaling Beyond a Single Node

While Block-STM scales **vertically** within a node, **Shardines** targets **horizontal execution scaling**.

Shardines introduces:

-   Multiple executor shards per validator    
-   Each shard runs its own Block-STM instance    
-   A coordinator partitions transactions    
-   A state aggregator merges results
    

Early test results show:

-   ~35–40k TPS per shard    
-   > 1M TPS aggregate throughput    
-   Near-linear scalability with shard count
    

Shardines is **validator-internal sharding**, not cross-validator sharding, and is currently in early testing stages 

Account Model & Move VM
-----------------------

Aptos uses **Resource-Oriented Accounts**, powered by the Move language.

### Key Principles

-   All on-chain assets are **Resources**   
-   Resources cannot be copied, dropped, or forged    
-   Only the defining module can create or destroy them    
-   The Move VM enforces these rules at the bytecode level
    

This eliminates entire classes of bugs common in EVM-based token contracts (e.g., balance inconsistencies, reentrancy-driven asset duplication) 

Each account logically contains:

-   Address    
-   Resources (typed state)    
-   Modules (code)
    

This tight coupling between assets and types also enables more efficient parallel execution.

---

Storage Layer: Scaling State Safely
-----------------------------------

### Core Components

-   **State View** (multi-version)    
-   **Jellyfish Merkle Tree (JMT)**    
-   **RocksDB**    
-   **State Pruner**    

The JMT provides:

-   Efficient proofs    
-   Versioned state access    
-   Deterministic state roots per block
    

 

Aptos overview

---

### Storage Sharding (AIP-97)

To address long-term state growth, Aptos introduces **Storage Sharding**:

-   Logical partitioning into **256 shards**    
-   Each shard maintains its own subtree   
-   Root hash is derived from shard roots
    

This improves:

-   Write amplification    
-   Parallel reads    
-   Long-term state sustainability
    

Storage sharding is transparent to execution and consensus 

Aptos overview

.

---

Toward Aptos 2.0
----------------

Aptos’s longer-term vision is a **real-time on-chain trading engine**, enabled by:

-   Ultra-low-latency consensus (Archon / Raptr evolution)    
-   Namespaces for resource isolation    
-   Sub-30ms proposal times    
-   Deep execution and storage pipelining
    

 

Aptos overview

---

Conclusion
----------

Aptos stands out not because of a single optimization, but because of **tight integration across layers**:

-   DAG-based data availability   
-   Prefix-based consensus finality    
-   Optimistic parallel execution    
-   Resource-safe programming model   
-   Sharded execution and storage roadmaps
    

Together, these design choices position Aptos as one of the most ambitious attempts at building a **globally scalable, low-latency Layer-1**.
