Solana vs Aptos vs Sui: The Battle for the Fastest Layer 1

The Race Beyond Ethereum

By 2021, it was clear that Ethereum's execution throughput was the binding constraint on blockchain adoption. While Ethereum's Layer 2 ecosystem was developing, a new class of Layer 1 blockchains emerged with a specific thesis: rather than inherit Ethereum's sequential execution model and retrofit scaling solutions, design for high throughput from first principles.

Solana had demonstrated that hardware-oriented design could achieve dramatically higher throughput. But Solana's architecture came with specific tradeoffs — particularly around programming model complexity and outage frequency. A subsequent wave of high-throughput L1s, including Aptos and Sui (both founded by former Meta/Diem engineers) and Sei (purpose-built for trading), approached the throughput problem with different technical tools and different tradeoffs.

Understanding these systems requires examining how each approaches the core bottleneck: transaction execution. All four have moved beyond the sequential, single-threaded execution model that limits Ethereum's throughput. But they arrive at parallel execution through different paths.

proof-of-history-and-sealevel">Solana: Proof of History and Sealevel

Solana's whitepaper, authored by Anatoly Yakovenko in 2017, identifies the root cause of blockchain throughput limitations as the cost of establishing a shared clock among untrusted nodes. Every consensus round requires validators to agree on the ordering of events — without a trusted time source, this coordination is expensive.

Proof of History (PoH) solves this by creating a verifiable, unforgeable sequence of time using a SHA-256 VDF (verifiable delay function). The sequence proves that specific events occurred in a specific order at specific points in time, without requiring consensus about those timestamps. Validators can use the PoH sequence as a shared clock reference, reducing coordination overhead.

Sealevel, Solana's parallel smart contract runtime, exploits this architecture by allowing transactions that touch different accounts to be processed simultaneously. A transaction in Solana declares upfront which accounts it will read and write; transactions that don't share accounts can run in parallel without coordination. The number of parallel threads is bounded only by available CPU cores.

The programming environment is Rust-based, with the anchor framework providing a higher-level interface. The required account declaration — while enabling parallelism — creates a programming model that is more complex than Ethereum's implicit state access. Developers must reason carefully about account ownership and borrow patterns.

Real-world Solana throughput in 2024 reaches 2,000-4,000 non-vote transactions per second under normal conditions, with capacity for significantly higher peaks. Average transaction fees are fractions of a cent. The tradeoff has been a history of network instability during extreme demand and high hardware requirements for validators.

block-stm-and-the-move-language">Aptos: Block-STM and the Move Language

Aptos was founded by former Meta engineers Avery Ching and Mo Shaikh, drawing on the Diem blockchain research. Aptos launched mainnet in October 2022 and introduced two significant technical contributions: the Block-STM parallel execution engine and the Move programming language.

Block-STM (Software Transactional Memory) takes a different approach to parallelism than Solana's declared accounts model. Rather than requiring developers to declare state access upfront, Block-STM executes transactions speculatively in parallel, detects conflicts through a software transactional memory layer, and re-executes conflicting transactions in dependency order. The system learns which transactions conflict and can pre-sort them optimally.

The advantage over Solana's model is developer experience: Solana developers must correctly declare all account dependencies or face transaction failure. Block-STM requires no such declaration — conflict detection is automatic. The cost is some overhead from speculative execution and conflict detection, which is minimal when transaction conflict rates are low (the common case for well-designed applications).

Move is a Rust-inspired programming language designed at Meta (then Facebook) for the Diem blockchain. Its distinguishing features are first-class "resources" — types that can be moved but not copied or discarded, enforced by the language's type system. This resource model eliminates an entire class of smart contract bugs: in Ethereum's EVM, tokens are represented as integers in a mapping, and vulnerabilities arise when that representation is manipulated. In Move, tokens are resources with ownership semantics enforced by the compiler; you cannot duplicate or lose a token through a programming error.

Move's type system also enables formal verification of smart contracts at a practical level — the language was designed from the start to support automated proofs of contract properties. Several high-profile Ethereum vulnerabilities (reentrancy attacks, integer overflows) would be prevented at the language level in Move.

Aptos has demonstrated mainnet throughput of 150,000+ TPS in benchmark conditions, though real-world mainnet throughput during typical load is substantially lower. The Move ecosystem remains smaller than Solidity's but has grown steadily, with DeFi protocols, NFT marketplaces, and payment applications deploying.

Sui: Object-Centric State and Narwhal/Bullshark

Sui, also founded by former Meta/Diem engineers (Evan Cheng, Adeniyi Abiodun, Sam Blackshear, George Danezis, and Kostas Chalkias), shares Move with Aptos but implements it with a fundamentally different state model and consensus architecture.

Ethereum and Solana treat blockchain state as a global key-value store — a mapping from addresses (or account public keys) to state data. Transactions modify entries in this global store. Sui instead adopts an object-centric state model. Every piece of state on Sui is an explicit object with a unique ID and an owner (either an address, another object, or the network itself). Transactions operate on specific objects, and the type system tracks object ownership.

This object model enables a powerful optimization: simple transactions that involve only objects owned by a single user don't require full consensus. Sui's consensus architecture (Narwhal for transaction dissemination and Bullshark for ordering) allows these "simple" transactions to be finalized through a fast-path process that bypasses the full consensus round. Only transactions involving shared objects (owned by multiple parties or the entire network) require full consensus sequencing.

For the typical DeFi user experience — swapping tokens in a personal wallet, minting an NFT, transferring assets — the transactions often involve only user-owned objects and can achieve sub-second finality through the fast path. Shared object transactions (interacting with a shared liquidity pool, for example) take longer but still benefit from Narwhal's high-throughput data dissemination layer.

Sui's throughput benchmarks show similar peak numbers to Aptos. The architectural difference is in how throughput scales with transaction mix: Sui's fast path provides particularly low latency for single-owner transaction workloads, while shared-object workloads use the full consensus path.

Both Aptos and Sui use Move, but with different implementations and different object models. Aptos Move and Sui Move are similar but not identical — code written for one does not directly run on the other, though the conceptual model transfers.

Sei: Optimized for Trading

Sei takes a narrower approach: rather than building a general-purpose high-throughput L1, Sei optimizes specifically for trading and order matching workloads. Built using the Cosmos SDK, Sei implements several trading-specific optimizations: order bundling (aggregating matching orders into single transactions), native order book primitives at the protocol level, and parallelization targeted at the access patterns of trading applications.

Sei's consensus uses Twin-Turbo consensus (a modification of Tendermint) with optimistic block processing — validators begin processing the next block before the current block is finalized, reducing effective latency. Sei V2 introduced a parallel EVM alongside the native environment, making Ethereum tooling directly available on Sei.

The narrow optimization strategy means Sei achieves competitive performance for trading workloads but doesn't have the general throughput story of Solana, Aptos, or Sui. It targets a specific ecosystem — DeFi traders, DEX operators, derivatives platforms — rather than a broad application developer base.

Comparing the Approaches

The key insight across all four systems is that sequential execution is the bottleneck, not consensus. All four have moved beyond it, using different parallelization strategies that reflect different assumptions about typical transaction workloads and different priorities in developer experience. Solana's account declaration model is maximally explicit; Block-STM is transparent to developers; Sui's object model encodes parallelism in the state representation itself.

The Move vs Solidity/Rust language choice has ecosystem implications that may prove more durable than consensus mechanism differences. Move's resource safety and formal verification potential position it well for high-value financial applications, while Solidity's existing developer base and tooling represent a network effect that is difficult to overcome. Both paths have reached sufficient maturity that protocol choice for new applications is now a genuine technical and ecosystem decision rather than a default toward Ethereum.