Sui / Aptos / Near: Next-Generation L1 Comparison

Sui, Aptos and NEAR all try to raise Layer 1 capacity, but they take different routes. Sui represents state as objects, Aptos executes transactions in parallel with Block-STM, and NEAR shards both state and execution through Nightshade.

The three cannot simply be lumped together as one category of fast chain. Sui and Aptos both build on Move yet use different object and storage models, while NEAR relies on an account model, Wasm contracts and asynchronous cross-contract calls.

Why is Sui built around objects?

Sui represents on-chain assets and state as objects, each carrying a unique ID, a version and ownership information. An object can be owned by an address, owned by another object, or shared so that multiple users can access it.

Transactions list their input objects explicitly. Transactions that touch only independently owned objects have clear causal relationships and can be validated and executed in parallel; shared mutable objects need consensus ordering so that different transactions do not write conflicting state at the same time.

The object model suits digital assets and composable ownership, but a contract that funnels every operation through a single shared object still gives up the parallelism advantage.

How does Aptos execute in parallel with Block-STM?

Aptos uses the Move resource model and account state. Block-STM optimistically executes a batch of transactions in parallel, detects the read-write conflicts that actually occur, and re-executes the conflicting transactions so the final result matches a deterministic order.

Developers do not have to supply complete read-write sets in advance the way static scheduling systems require, but high-contention workloads produce more aborts and re-execution. Theoretical parallel capacity is not a direct proxy for the real throughput of a popular application.

Consensus components such as AptosBFT handle transaction ordering and commitment, while the MoveVM handles execution. Account features like Keyless Account and Sponsored Transaction belong to the user experience layer and do not change the fact that the underlying state still has to be agreed on by validators.

How does NEAR shard with Nightshade?

NEAR uses an account model in which every account and contract state belongs to a shard. Nightshade splits the state changes of one logical block into multiple Shard Chunks, and different validators process the data and execution of their corresponding shard.

Cross-account and cross-shard calls use asynchronous Receipts. After a contract issues a call, the result may come back in a later block, so developers have to handle callbacks and partially completed states.

NEAR's named accounts and multiple access keys can improve application login, and the Wasm runtime supports development paths such as Rust and JavaScript. Sharded scaling also adds complexity in routing, state sync and cross-shard debugging.

How should the three chains be compared?

Any comparison should use the same definitions for successful user transactions, finality, node requirements and state growth. Lab peaks, consensus votes or simple transfers do not stand in for complex contract workloads.

For the single-chain parallel execution route, a useful contrast is Solana as a high-performance blockchain, and for the wider positioning of these networks you can return to the 2025 landscape of major Layer 1 ecosystems.

FAQ

Can Sui Move and Aptos Move contracts be deployed directly on each other's chain?

Usually not by straight copying. They share Move as a common language origin, but their frameworks, object or account APIs, standard libraries and deployment tooling differ, so code has to be adapted and tested for the target chain.

Does parallel execution change the determinism of transactions?

It is not designed to trade away deterministic results. A scheduler may attempt execution in parallel, but conflict detection, ordering or object locking has to guarantee that every validator arrives at the same committed outcome.

Do users have to choose a shard themselves on NEAR?

Ordinary users normally interact through accounts and applications, and the protocol handles routing. Developers still need to understand asynchronous cross-shard calls and how to deal with failed Receipts.

Can the TPS of the three chains be compared directly?

Not from a single number. Whether the statistic includes votes, failed transactions and batched operations, together with test hardware, transaction complexity and the definition of finality, all change the result.