Parallel

Solana

Aptos

would

when

<h2 id="a-different-bet-on-parallelism">A different bet on parallelism</h2>
Most parallel blockchains ask developers or users to declare, upfront, which data a transaction will touch. <a href="https://x.com/Aptos" rel="noopener noreferrer nofollow">@Aptos</a> takes the opposite approach. Its execution engine, Block-STM, optimistically assumes all transactions in a block are independent and runs them simultaneously without any prior dependency declarations.
<cite>Block-STM optimistically assumes that all transactions are independent and executes them in parallel, recording their read and write sets. Those sets are then used to validate the results, which leads to re-execution if a transaction fails validation.</cite> The final output is identical to what you would get from processing every transaction one at a time in the block's preset order, preserving determinism without sacrificing speed.
<cite>Block-STM enforces that the outcome is consistent with executing transactions according to a preset order, leveraging that order to dynamically detect dependencies. At its core is a novel, low-overhead collaborative scheduler of execution and validation tasks.</cite>
<h2 id="the-trade-off-contention-under-load">The trade-off: contention under load</h2>
The approach works well when transactions are touching different parts of the network state, which covers most everyday activity. <cite>Rather than determining upfront which transactions conflict, Block-STM executes all transactions in a block in parallel speculatively, then detects conflicts after the fact and re-executes only the transactions that touched overlapping state. For workloads where most transactions are independent, this delivers high throughput without requiring explicit ownership tracking.</cite>
The cost emerges during busy periods. <cite>Block-STM achieves great performance for low-contention workloads, but it struggles under high contention due to frequent re-executions.</cite><cite>When shared state is heavily contested, re-execution overhead increases.</cite> This is a trade-off both Aptos Labs and independent researchers acknowledge openly.
The design stands in contrast to the approaches taken by Solana and Sui. <cite>In Software Transactional Memory, there is no need for transactions to explicitly declare dependencies. While users previously had to declare dependencies when creating transactions, Aptos's parallel engine removes this requirement.</cite> Sui, by comparison, <cite>groups transactions by the objects they target and processes these groups in parallel across validator machines,</cite> a model that front-loads conflict resolution rather than resolving it speculatively after the fact.
In benchmark conditions, <cite>Block-STM achieves up to a 20x speedup over sequential execution on low-contention workloads and a 9x improvement on high-contention workloads using 32 threads.</cite> Whether those gains hold up at scale under real-world demand remains the central question for the <a href="https://x.com/search?q=%24APT&amp;src=cashtag_click" rel="noopener noreferrer nofollow">$APT</a> network.
Sources <a href="https://aptos.dev/network/blockchain/execution" rel="noopener noreferrer nofollow">Aptos Official Documentation: Transaction Execution</a> <a href="https://arxiv.org/pdf/2203.06871" rel="noopener noreferrer nofollow">Block-STM Research Paper: Scaling Blockchain Execution (arXiv)</a> <a href="https://arxiv.org/pdf/2510.15122" rel="noopener noreferrer nofollow">NEMO: Faster Parallel Execution for Highly Contended Blockchain Workloads (arXiv)</a>

Aptos runs transactions in parallel first and sorts out the collisions after

Table of Contents

BSCN

Other articles published on Aug 21, 2026

Join our free newsletter for daily crypto updates!