Skip to content
Aptos Documentation

Execution

On Aptos, execution is the step where validators apply an ordered block of transactions to ledger state. The output must be deterministic: honest validators that start from the same state and the same block must produce the same write set.

A supermajority of voting power (more than two-thirds) must agree on that result before the block commits. See BFT and consensus.

Execution speed shows up as block time. Aptos does not wait on a fixed slot clock; it proposes the next block as soon as the network allows. Mainnet block times are typically tens of milliseconds. See Blocks.

Why parallel execution?

Section titled “Why parallel execution?”
flowchart TB
  subgraph sequential [Sequential]
    direction LR
    S1[Txn 1] --> S2[Txn 2] --> S3[Txn 3]
  end
  subgraph staticp [Static parallelism]
    direction LR
    D1[Declare access lists] --> D2[Schedule non-overlapping txns]
  end
  subgraph dynamicp [Dynamic parallelism]
    direction LR
    P1[Execute speculatively] --> P2[Detect conflicts] --> P3[Re-execute in preset order]
  end

Executing a block one transaction at a time is simple and does not scale. Long transactions stall everything behind them, so latency and throughput collapse under load.

Parallel execution runs many transactions at once. The hard part is conflicts: two transactions that read or write the same resource cannot both commit as if they ran alone in the wrong order.

Static parallelism

Section titled “Static parallelism”

Static parallelism asks developers (or the runtime, from annotations) to declare which data each transaction will touch. The scheduler then runs non-overlapping transactions together.

That shifts the burden onto application authors. Declared sets are often wider than the data a transaction actually uses, so independent work is forced to run serially.

Dynamic parallelism

Section titled “Dynamic parallelism”

Dynamic parallelism finds conflicts at runtime. Transactions execute speculatively; if two of them collide, the engine re-executes the later one. The committed result must still match executing the block in the preset consensus order.

Developers do not declare access lists. They write ordinary Move, and the engine parallelizes whatever does not conflict.

Block-STM

Section titled “Block-STM”

Aptos executes blocks with Block-STM, a multi-threaded, in-memory engine that combines software transactional memory with a collaborative scheduler. It uses the consensus order as the serial baseline, executes transactions in parallel, and re-executes only the ones that aborted because of a conflict.

Block-STM is the dynamic-parallelism engine originally built by Aptos Labs. Polygon, Sei, Starknet, and other chains have adopted the same approach.

To learn more: