Aptos
block-stm-and-the-move-language">Aptos: Block-STM and the Move Language
When Facebook's Diem project collapsed in 2022 under regulatory pressure, the engineers who had spent years building it did not abandon their work. They took the most technically ambitious parts — a novel smart contract language called Move and a sophisticated parallel execution engine — and built a new blockchain from scratch. The result is Aptos, a Layer 1 blockchain whose whitepaper makes strong claims about transaction throughput and safety that trace directly back to years of engineering inside one of the world's largest technology companies.
Understanding Aptos requires understanding two ideas that its whitepaper puts at the center of everything: Block-STM, a system for executing transactions in parallel, and Move, a programming language designed to make smart contracts provably safe.
The Problem with Sequential Execution
Most blockchains execute transactions sequentially — one after another, in the order they appear in a block. This is the simplest way to guarantee that transactions don't interfere with each other: if only one transaction runs at a time, there's no possibility of two transactions reading and writing the same state simultaneously in conflicting ways.
Sequential execution is also a massive bottleneck. Modern CPUs have dozens of cores that can execute code simultaneously, but a sequentially executing blockchain uses only one of them productively. If you want to increase throughput, you either make the single thread faster (limited by physics) or you find a way to execute multiple transactions at the same time.
Parallel execution is the natural answer, but it introduces a hard problem: what happens when two transactions in the same block try to modify the same account? A naive parallel implementation could produce inconsistent state — the blockchain equivalent of a race condition in multithreaded programming.
Block-STM: Optimistic Parallel Execution
Block-STM, developed by the Aptos team, is an optimistic concurrency control mechanism for blockchain transaction execution. It is adapted from Software Transactional Memory (STM) research from the database and programming languages communities.
How Block-STM Works
The core idea is optimistic execution with validation and re-execution. At the start of each block, the executor speculatively runs all transactions in parallel, using multiple CPU threads simultaneously. Each transaction records what storage locations it read from and wrote to during execution.
After the speculative phase, the system validates each transaction's read set: it checks whether any location that the transaction read was modified by an earlier transaction in the block (one that would execute before it in the canonical ordering). If a conflict is detected — the transaction read stale data — it is re-executed with the correct, updated data.
This process repeats until all transactions have been validated without conflicts. In the common case — when transactions access distinct accounts or contract state — there are no conflicts and all transactions execute fully in parallel. When conflicts do occur, only the affected transactions need re-execution, not the entire block.
Why This Works Well in Practice
On a blockchain, most transactions within a block touch different accounts. A block containing thousands of token transfers between different users has essentially no conflicts: each transfer reads and writes a distinct set of accounts. Block-STM achieves near-linear speedup with the number of CPU cores in this common case.
Conflicts are more likely when many transactions interact with the same popular contract — for example, a high-traffic DeFi protocol. Even here, Block-STM handles the situation gracefully: conflicting transactions are re-executed in dependency order, producing correct results while still parallelizing the independent subset.
The Aptos whitepaper presents benchmarks showing throughput in excess of 100,000 transactions per second under favorable conditions, though real-world throughput depends heavily on transaction complexity and conflict rates.
The Move Language
Move was designed at Facebook specifically for writing financial smart contracts. Its design decisions are motivated by one observation: most high-profile smart contract bugs involve resources — digital assets — being duplicated, destroyed, or accessed by unauthorized parties. Move makes these classes of bugs impossible at the language level.
Resources: Assets as Linear Types
The central concept in Move is the resource type. A resource in Move obeys a linear type system: it can be moved between storage locations, but it cannot be copied or silently dropped. If you have a resource representing a token balance, you cannot duplicate it (creating tokens from thin air) and you cannot lose it (tokens don't vanish from an undefined delete operation). The compiler enforces this at compile time — code that attempts to copy or drop a resource simply does not compile.
This is a profound safety guarantee. The reentrancy attacks and integer overflow bugs that have cost Ethereum users hundreds of millions of dollars often involve unexpected copying or destruction of value. Move's type system eliminates entire classes of these vulnerabilities before deployment.
Modules and Scripts
Move code is organized into modules, which define types and functions, and scripts, which are one-time executable programs that call module functions. This separation mirrors the difference between a deployed contract (module) and a transaction that calls it (script).
Modules are published to the blockchain under the account address of their deployer. Functions within modules can be marked as public (callable by anyone), public(friend) (callable only by specified friend modules), or private. This fine-grained access control is significantly more expressive than Solidity's public/internal/external/private modifiers.
Formal Verification
Move includes a specification language called the Move Prover that allows developers to write formal specifications of their contracts — mathematical statements about what the contract should and should not do — and then automatically verify that the implementation satisfies those specifications. This is a form of formal verification, a technique borrowed from safety-critical software engineering.
For financial contracts where bugs can cause irreversible losses, the ability to prove correctness (not just test it) is genuinely valuable. The Aptos team has applied the Move Prover to the core framework contracts that ship with the blockchain, providing a level of assurance about their safety that is unusual in the smart contract space.
consensus-protocol">DiemBFT Lineage: The Consensus Protocol
Aptos uses AptosBFT, which is a direct descendant of DiemBFT — the consensus protocol developed for Facebook's Diem project, which was itself an evolution of HotStuff, a Byzantine fault-tolerant consensus algorithm from academic research.
HotStuff-family protocols achieve consensus in a small, fixed number of communication rounds using a leader-based approach. In each round, a designated leader proposes a block, and validators vote on it. After collecting enough votes, the leader produces a certificate (a quorum certificate) that proves the block is safe to commit. Three rounds of voting produce a committed block.
AptosBFT adds a reputation mechanism: validators who are frequently offline or slow to respond are demoted in the validator ordering, ensuring that the protocol makes progress even when some validators are underperforming. The leader rotation is pipelined, meaning the next leader can begin proposing while the current round's votes are still being collected.
This results in sub-second finality under normal network conditions — once a block is committed in AptosBFT, it is irreversible.
The Account and Storage Model
Aptos uses an account-based model (similar to Ethereum) rather than the UTXO model used by Bitcoin. However, account storage in Aptos is structured around Move resources. Each account stores a collection of typed resources under its address. To hold a particular type of token, an account must have a resource of that token's type registered in its storage.
This resource-centric storage model aligns naturally with Move's linear type system and makes the ownership of every asset explicit and auditable. There are no hidden allowances or indirect delegations — every asset is stored explicitly under the account that owns it.
Aptos in Context
Aptos launched its mainnet in October 2022, alongside Sui — another blockchain built by Diem alumni using Move. The two projects represent different bets on how Move's ideas should be deployed: Aptos uses a more traditional account model adapted for Move, while Sui uses an object-centric model.
The Aptos whitepaper is unusual in the blockchain space for its depth of technical detail and its direct lineage from academic research (DiemBFT, Block-STM, the Move type system). It represents the most direct transfer of large-scale distributed systems engineering from a major tech company into the open blockchain ecosystem — a rare case where industry resources, academic rigor, and open-source development converged in a single project.