Thread by @TheSpartanLabs

While @SuiNetwork $SUI and @AptosFoundation $APT share many similarities like TPS and programming language, the two upstart Layer 1 chains are far from the same.

Here are 3 KEY severely overlooked differences and the reasons why we're building on #Sui 🧵 👇

1/ Parallel Execution

As smart contract platforms increase in adoption, smart contract execution increasingly becomes a major bottleneck for blockchain throughput.

To achieve higher TPS, both Aptos and Sui apply parallelization at the execution layer.

'Parallel Execution' refers to the approach where on-chain transactions are executed in parallel for improved performance, rather than executing sequentially which does not scale well.

With that said, both Aptos and Sui employ different methods which stems from its architecture.

Aptos employs the Byzantium Fault Tolerance (BFT) algorithm where parallelization is implemented by detecting dependencies and execution tasks using its Block-STM execution engine.

medium.com/aptoslabs/bloc…

In essence, that means transactions made are assumed to be valid (optimistic) while its Block-STM execution engine detects conflicting transactions.

Conflicts are re-executed and re-validated through a queue and then synchronized on the blockchain's final state.

On the other hand, Sui employs Narwhal and Tusk, a Directed Acyclic Graph-based mempool (DAG) and BFT consensus algorithm where it can process transactions both in parallel or sequentially depending on the complexity of the transaction.

docs.sui.io/devnet/learn/a…

The breakthrough here is that Sui enables transactions to be committed to the blockchain by validators using Byzantine Consistent Broadcast.

A novel technique to eliminate overhead by forgoing global consensus without compromising on safety and liveness.

Essentially, Sui is very well optimised and is able to perform simple transactions instantaneously, or as fast as the slowest validator on the network.

For more complex transactions with shared objects, it can be executed sequentially through global validator consensus.

2/ Objects

Most modern blockchains typically store their data in the form of 'accounts'.

In Ethereum's case, accounts are separated into two types: Externally Owned Accounts (EOA) and Contract Accounts.

One controlled by a private key and can send transactions, and one controlled by its associated code which can execute when it receives a transaction from an EOA.

Aptos structures their data in a similar way with accounts except tokens, NFTs or any asset is represented as a 'Resource', while code is represented as 'Modules'.

One containing data but no code, and the other containing code but no data.

Sui stores its data as 'Objects' which can be classified as owned/shared or mutable/immutable.

This approach is clean as ownership can be determined a lot more clearly as compared to many other blockchains, a testament to the blockchain's design.

However, the interesting implementation here is the ability to have 'shared objects'.

This means anyone can read or write this 'shared object', in contrast to an 'owned object' which can only be accessed by a single writer.

While on blockchains like Ethereum, every object is shared (any account can interact with any contract), Sui developers have the choice to implement specific use-cases which utilize both owned and shared objects.

docs.sui.io/learn/objects

As explained above with parallel execution, Sui's superpower here is that 'owned objects' or simple transactions can be posted to the blockchain without going through network-wide consensus.

In essence, developers can think of owned objects as a "latency-booster" as smart contracts can be designed in a way where certain steps that do not require 'shared objects' and consensus can be 'skipped'.

@suidotfish explains it well here 👇

https://twitter.com/suidotfish/status/1585619577525792769

3/ Scalability

Both Sui and Aptos employs heterogeneous validators which maximize on network capacity, similar to Solana.

However, the bottleneck here is likely 'state growth', or the higher CPU and storage requirements required to store the blockchain's entire history.

As the blockchain continues to operate, the data of its history will expand, requiring validator fullnodes to continuously upgrade their system's hardware.

Sui addresses this issue by sharding storage efficiently through the horizontal scaling of network resources.

Through its Narwhal consensus protocol, the network is able to scale by increasing the number of machines run by its validators.

arxiv.org/abs/2105.11827

In that sense, the Sui network is able to achieve greater scalability as more validators are validating the network.

@EvanWeb3 breaks it down well here 👇

https://twitter.com/EvanWeb3/status/1569414569319362560

While the @SuiNetwork is still in its devnet, we at @TheSpartanLabs believe that Sui has great potential to compete as one of the top smart contract ecosystems in the space.

We are currently building @suidotfish on Sui, come follow us and ride the #SUINAMI!

We hope you found this thread insightful!

Follow us at @TheSpartanLabs for more takes on Web3, NFTs, DeFi and more!

Like/RT the first tweet below to help spread the word:

https://twitter.com/TheSpartanLabs/status/1585981462129483778