What is Sui ($SUI)?
Sui is a smart contract platform maintained by a permissionless set of validators that play a role similar to validators or miners in other blockchain systems.
*Learn more in our report discussing in details Sui ($SUI) and other emerging new layer blockchain projects - Beyond Aptos, Sui & Canto | An in-Depth Guide to the Emerging Alt-L1s
Sui claims to offer scalability and unprecedented low-latency for simple use cases. Sui makes the vast majority of transactions processable in parallel, which makes better use of processing resources, and offers the option to increase throughput with more resources. Sui forgoes consensus to instead use simpler and lower-latency primitives for simple use cases, such as payment transactions and assets transfer. Sui also enables a number of new latency-sensitive distributed applications, ranging from gaming to retail payment at physical points of sale.
Sui is written in Rust and supports smart contracts written in the Move programming language to define assets that may have an owner. Move programs define operations on these assets including custom rules for their creation, the transfer of these assets to new owners, and operations that mutate assets.
Who created Sui ($SUI)?
The team of the Sui project is MystenLabs. MystenLabs contains 76 employees as of 27 Sept. 2022. MystenLabs is co-founded by Evan Cheng (CEO), Sam Blackshear (CTO), Adeniyi Abiodun (CPO), and George Danezis (Chief Scientist). They all worked as senior leaders in the Novi (Meta) project and participated in developing the Diem project and Move language.
What is unique about Sui?
Sui’s design is radical and groundbreaking in two ways.
First, Sui records transactions based on objects. Objects can be tokens, smart contracts, or on-chain units. Each object has a list of attributes, including owner address, amount, type, etc. Under Sui’s design, a simple transfer of Object O from User A to User B requires only one update to the Sui state. That is, the owner of O is changed from A to B. In contrast, a typical blockchain must process two transactions. First, O is removed from A’s inventory; second, O is added to B’s inventory. This allows independent transactions to be identified more easily.
While Aptos’ Block-STM takes up the responsibility to differentiate dependent transactions from independent ones, Sui asks users and developers to declare upfront whether a submitted transaction is independent or not. If a transaction is independent, it is processed directly without requiring network nodes to reach a consensus. It goes through Sui’s consensus engine for ordering like a typical blockchain transaction if it is dependent.
What is the consensus of Sui?
Sui’s consensus mechanism is Narwhal & Bullshark. The dual name highlights that Sui’s consensus engine is split into two parts. The Narwhal part is responsible for ensuring the availability of transaction data submitted. The Bullshark part is responsible for agreeing on the ordering of those transaction data. Bullshark replaced Tusk in August 2022 for reduced latency and better support for fairness. Narwhal can also be coupled with an external consensus algorithm such as HotStuff or Tendermint.
By shifting the burden of identifying dependency to developers, the execution engine of Sui should theoretically have better stability than Aptos. Solana currently takes a similar approach where a transaction must declare the “objects” it changes. However, this approach makes developing on top of Sui more complex.
Despite their shared origins, Aptos and Sui are very different in their attempts to solve the scaling problem. While Aptos is more similar to existing designs, Sui is more innovative and thus more complicated to build upon.
What is Sui's token utility (tokenomics)?
Sui has a native token called $SUI, with a fixed supply. The $SUI token is used to pay for gas, and is also used as delegated stake on validators within an epoch. The voting power of validators within this epoch is a function of this delegated stake. Validators are periodically reconfigured according to the stake delegated to them. In any epoch the set of validators is Byzantine fault tolerant. At the end of the epoch, fees collected through all transactions processed are distributed to validators according to their contribution to the operation of the system. Validators can in turn share some of the fees as rewards to users that delegated stake to them.