How parallel transaction execution works on aptos with block STM

02 September 2026

Aptos processes transactions using Block-STM. The name stands for Software Transactional Memory, and it is an optimistic approach. The system assumes no conflicts exist between transactions and executes them in parallel right away.

Block-STM works in rounds. Each round picks unexecuted transactions; they run simultaneously. After execution, the system checks for conflicts. A conflict happens when two transactions touch the same state. If none exist, everything commits. If conflicts appear, the transactions that lost the race re-execute. Only the conflicting ones restart. The rest stay valid.

This method works well when conflicts are rare. Most transactions in practice do not collide. The overhead appears only when contention is high, and then re-execution costs accumulate. The system must validate every transaction at least once. That validation step adds work even when nothing conflicts.

Sui under Mysticeti takes a different route. It separates transactions into two categories. Simple owned-object transfers own their objects; no other transaction can touch those objects without permission. The system skips consensus entirely for these. They execute locally on validators, finality comes fast, and no conflict checking is needed because the objects are already exclusive.

Shared objects are different. Multiple transactions may want them, and these objects require ordering. Mysticeti orders them through a DAG-based consensus protocol. Each validator agrees on the sequence, then execution happens in that order. Parallel execution still applies, but only after ordering.

Real-world contention creates bottlenecks. Consider a hot NFT collection on Aptos. Many people mint from the same contract. That contract is a shared resource. Block-STM sees frequent conflicts. Transactions constantly re-execute. Latency climbs. Throughput drops. The optimistic assumption fails.

On Sui, the same scenario looks different. If the mint contract uses shared objects, it hits similar problems. Mysticeti orders those mints, and parallelism is limited by ordering constraints. But Sui offers alternatives. A mint can use owned objects instead. Each user claims a unique token object. No sharing needed. No consensus required. The system scales linearly with validator capacity.

Block-STM handles moderate contention gracefully. It thrives when 90% of transactions are conflict-free, and the remaining 10% re-execute without stalling the whole batch. The system commits progress every round. Validation is the main overhead.

Sui's architecture pushes contention to the edges. It encourages owned objects. Developers design around shared state. The chain rewards thinking about object ownership upfront.

Both chains aim for high throughput. Both use parallelism. But they arrive there through different trade-offs: Aptos bets on optimism and rollback, while Sui bets on structural separation. Each works best in different load patterns.

Which chain handles a real price feed better? A global shared oracle object where every transaction reads it. On Aptos, every block sees conflicts, many re-executions, and throughput degrades. On Sui, that oracle is a shared object. Mysticeti orders reads and writes, contention is explicit, and the system knows where the bottleneck sits. It cannot avoid it either.

No architecture eliminates contention entirely. Both chains acknowledge that some state is inherently hot. Block-STM re-executes hot transactions quickly. Mysticeti orders them deterministically. The difference is philosophical: Aptos optimises for the common case, while Sui structures state to make contention rare. Each works. Neither is perfect for every workload.

Back to sui & aptos