Aptos vs. Sui - Protocol Comparison

Posted on | In
Aptos and Sui are exceptionally fast (over 100,000 tps) and scalable layer 1 smart contract platforms.

Aptos vs. Sui: Protocol Comparison

Aptos and Sui are exceptionally fast (over 100,000 tps) and scalable layer 1 smart contract platforms. Both use the Move language, originally developed for Meta’s Diem project, and count Diem executives among their founders. Let’s see how they compare in terms of technology, performance, available dApps, and more.

Move Language

Diem is dead, but the most valuable assets that were created for it — Move and the virtual machine Move VM — are open-source, so other projects can use them.

Move is a very safe and efficient language that helps developers avoid many of the coding errors that can result in exploits. In turn, Move VM is an alternative to Ethereum Virtual Machine — a secure and portable environment for running smart contracts.

Both Sui and Aptos use a similar model of the Move programming language, originally developed for Diem. Note that while Diem was supposed to be a permissioned network, Sui and Aptos are decentralized and permissionless: anyone will be able to join them as a validator. While Aptos has continued to use the original Move language, Sui has deviated to their own version of “Sui Move”.

Here is a summary of key differences:

  • Sui uses its own object-centric global storage
  • Addresses represent Object IDs
  • Sui objects have globally unique IDs
  • Sui has module initializers (init, optional)
    • A module init is executed (once) at the time of module publication for the purpose of pre-initializing module-specific data
  • Sui entry points take object references as input

Both the permissioned nature of Diem and certain implementation details of the Diem blockchain (particularly the storage model) make the implementation of some fundamental smart contract use cases in the original Move difficult. In particular, the original designs of Move and Diem predated the popularity explosion of NFTs and have some quirks that make NFT-related use cases especially tricky to implement. Example scenarios include:

  • Frictionless mass asset creation
  • Native asset ownership and transfers
  • Bundling heterogenous assets (In Sui, an object can be owned by another object)

Architecture and consensus

AptosBFT: a consensus model based on HotStuff

Consensus is a mechanism that allows blockchain nodes (validators) to come to an agreement on the validity of transactions and blocks. At the core of both Aptos and Sui, there is a consensus concept called BFT, or *Byzantine Fault Tolerance. Its main idea is that even if some (up to one third) of the validators go offline or become malicious, the network can still operate normally.

  • BFT: A Byzantine fault (also Byzantine generals problem) is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed.

In a Byzantine fault, a component such as a server can inconsistently appear both failed and functioning to failure-detection systems, presenting different symptoms to different observers. It is difficult for the other components to declare it failed and shut it out of the network, because they need to first reach a consensus regarding which component has failed in the first place. Byzantine fault tolerance (BFT) is the resiliency of a fault-tolerant computer system to such conditions.*

Aptos relies on an advanced version of BFT consensus called HotStuff. It was modified by Diem to produce DiemBFT, and Aptos has further improved on it under the name AptosBFT. Here is the high level overview of the Aptos consensus:

  • In HotStuff, there is a leader who suggests a new block, and the rest of the validators vote on it.
  • Since all the validators communicate with the leader, the total number of messages sent out in every round is much lower than if the validators also communicated with each other.
  • Once everyone agrees that a block is valid, it becomes final — this fast finality is a key advantage of Aptos over blockchains like BNB Chain, where finality takes 30 seconds, or Solana, where it’s around 6 seconds.
  • The leader changes with every round of voting, with a new leader selected in a verifiably random way.
  • The leader can work on several blocks at the same time (one in the Pre-Commit stage, another in the Commit stage, etc.) — this is called pipelining.

Note that other than the last characteristics of pipelining, other features are similar to those of pBFT (practical BFT) consensus implemented by a few layer 1 blockchains such as Harmony Protocol.

Block-STM: Aptos’ parallel execution engine

  • Block-STM, where STM stands for ‘Software Transactional Memory’, is a system created by Aptos to process up to 160,000 transactions per second. It is a parallel execution engine for smart contracts, built around the principles of Software Transactional Memory.

The STM Approach

Software Transactional Memory (STM) instruments memory accesses to detect and manage conflicts. STM libraries with optimistic concurrency control record memory accesses during execution, validate every transaction post execution and abort and re-execute transactions when validation surfaces a conflict.

In layman’s terms, in the context of blockchain, transactions are first executed by the nodes in parallel and only then validated. If there is a problem at this stage, a transaction can be aborted and re-executed or discarded. During the process, Block-STM determines the dependencies between transactions with its “dynamic dependency estimation” mechanism, so if an operation cannot be validated, those that depend on it will also be re-executed.

Finally, once all the conflicts have been resolved, all the transactions in a block are committed to the blockchain together (so-called lazy commit). Block-STM thus avoids the synchronization cost of committing transactions individually.

Sui: getting rid of consensus for simple transactions

Sui distinguishes between two types of assets (i) owned objects that can be modified only by their specific owner, and (ii) shared objects that have no specific owners and can be modified by more than one user. This distinction allows for a design that achieves very low latency by forgoing consensus for simple transactions involving only owned objects.

Sui assumes the typical blockchain transaction is a user-to-user transfer or asset manipulation and optimizes for such owned-object transaction scenarios. The protocol design achieves very low latency by forgoing consensus for simple transactions involving only owned objects. Thsu, simple transfers of tokens by their owner to a different address, without any other transactions depending on them, are confirmed virtually instantly. The sender broadcasts the transaction, collects validators’ votes (handshakes), and receives a so-called certificate of validity.

In Sui, this consensus protocol is required only when the transaction involves shared objects. For this, Sui offers the *DAG-based mempool, Narwhal and efficient Byzantine Fault Tolerant (BFT) consensus, Bullshark.

  • DAG: directed acyclic graph. A directed acyclic graph or DAG is a data modeling or structuring tool typically used in cryptocurrencies. It is more efficient at data storage with a tree-like structure of interconnected nodes as its ‘branches.’ Since each node can have more than one parent root, the model allows for more transactions to be validated simultaneously. That is, users do not have to wait for transactions to complete before processing a new one.

During Narwhal, the Sui validators play the role of more active validators in other blockchains to totally order the transaction with respect to other transactions accessing shared objects.

Based on such DAG-based, totally ordered transaction mempool from Narwhal, the Bullshark consensus operates on the guarantees that transaction processing obeys eventual consistency in the classical sense. This breaks down in two parts:

  • Eventual delivery - if one honest validator processes a transaction, all other honest validators will eventually do the same.
  • Convergence - two validators that have seen the same set of transactions share the same view of the system (reach the same state).

Also, in contrast to a blockchain, Sui does not stop the flow of transactions in order to witness the convergence.

aptos-sui aptos-sui


Conclusion

Scalability has been a common topic of conversation within the space over the past few years. It’s become apparent that many widely used blockchain systems aren’t inherently optimized to support blockchain technology’s continuous growth and adoption. Like Solana, both Aptos and Sui attempt to address blockchain limitations through horizontal, rather than vertical scaling.

Cumulatively, the chains represent the culmination of years of distributed ledger scalability research. Through innovative mempool and consensus protocols, Sui and Aptos aim to outperform existing vertical throughput architectures. With that said, both protocols are very early in their developmental stage, and until the actual implementation of Aptos’ and Sui’s respective designs are live and time-tested, there isn’t enough measurable data to confidently conclude that one model is superior to the other.