Guide to Sui

Introduction to Sui

Sui is a Layer 1 blockchain and smart contract platform designed from the bottom up to make digital asset ownership fast, secure, and accessible to everyone. Its object-centric model, based on the Move programming language, enables parallel execution, sub-second finality, and dynamic on-chain assets. With horizontally scalable processing and storage, Sui is designed to support a wide range of applications with speed at low cost. It aims to be a platform for creators and developers to build user-friendly experiences.

What Sui is Solving

Sui aims to solve  some of the main challenges facing web3 developers and users, including bottlenecks in transaction processing, high user network fees, and the capability to work with larger on-chain data loads. 

Performance: Most blockchains are designed to impose total ordering between each transaction which creates a backlog and results in slower processing times. However, many transactions do not have interdependencies and do not need to be ordered relative to each other. To resolve this bottleneck, Sui is designed to have two protocols: one that handles simple transactions without total ordering, and another one (Narwhal and Bullshark) to handle transactions with strongly-held interdependencies.

Low network fees: Sui’s gas price mechanism is built to support “horizontal-scaling” during moments of increased activity on the network – executing all transactions at the same time for non-conflicting transactions, while ensuring that gas fees are still low and predictable for users. The rapid scaling to minimize gas fees allows Sui to accommodate increasing network demands from users who submit high data loads without punishing small users with high gas fees.

Ability to work with onchain data: Sui is designed to make onchain data more tractable. Sui’s development team implemented a mechanism in which anyone using onchain storage would pay proportionally for storage used. This mechanism is made possible with an algorithm that assesses fees based partly on the data needs of a user.

How Sui Works

Objects

Most blockchains have storage centered around accounts and each account contains a key-value store. Sui deviates from this model and centers storage around objects. Objects are smart-contract programmable entities. They are digital entities that store data and are stored on the blockchain.

Smart contracts themselves are objects also called a Move Package. At the time of transactions, objects involved in the transaction get grouped dynamically and processed as that group. 

There are 4 types of ownership for objects in Sui:

1. Owned by an address: Objects owned by an address can be used only by transactions signed by that owner address 

2. Owned by another object: Also called child objects, the owner of the parent object needs to sign transactions accessing child objects

3. Immutable: No one can modify  or own the object, but it can be read. Move Packages are immutable objects

4. Shared: Anyone can interact with and access the object according to the access-control mechanism defined by the smart contract handling the object. These require consensus to sequence reads and writes and can implement their own access control during execution.

Two Protocols

Most blockchains face the bottleneck of needing to impose total ordering between each and every transaction. However, many transactions are not actually competing for the same resources and need not be  ordered relative to each other. To resolve this bottleneck Sui is designed to have two protocols:

1. Byzantine Consistent Broadcast to handle simple transactions

2. Narwhal and Bullshark consensus protocol to handle transactions or set of transactions that have strongly held interdependencies, and can benefit from shared objects where more than one user can mutate those objects via smart contract rules

More specifically, Sui distinguishes between two types of assets to run these consensus mechanisms in parallel

1. Owned objects that can only be modified by their specific owner

2. Shared objects that have no owner and can be modified by more than one user

Sui forgoes consensus on owned objects which it classifies as simple transactions. An example of a simple transaction would be a transfer of an asset to someone. Shared objects, which would be classified as transactions or sets of transactions that have strongly held interdependencies would go through consensus. An example would be a decentralized perpetual exchange. 

Both protocols go through a similar process:

1. Sender broadcasts transaction to all Sui validators

2. Each Sui validator individually checks that the objects for this transaction exist and that there is enough gas. Each vote has a certain weight based on the staked owned by the validator

3. The sender collects a supermajority of these votes in a certificate and broadcasts that back to all Sui validators. All validators verify the certificate and execute the transaction spending the gas. They then reply with a summary of the effect the transaction has on the state.

4. The sender collects a supermajority of replies; this settles the transaction, ensuring finality that the transaction will not be revoked (optional)

The difference in the consensus mechanism is in step 3 where the certificate itself is sequenced through consensus before execution. Below is a diagram of how transactions are processed.

Consensus: Narwhal and Bullshark

Sui uses a novel split mechanism for consensus where Narwhal is Sui’s mempool and Bullshark is Sui’s consensus engine. 

Said another way, Narwhal is responsible for ensuring the availability of data submitted to consensus, and Bullshark’s responsibility is to agree on a specific ordering of that data. 

The Narwhal mempool is a directed acyclic graph (DAG). 

The logic here is that a mempool that reliably distributes transactions is the key to a high throughput blockchain. Thus it should be completely separated from the consensus protocol, and leverage consensus only for ordering.    

Validators broadcast messages in rounds. Each message contains a set of transactions and a set of references to previous messages. Together, all the messages form a DAG that keeps growing where a message is a vertex and the message references are edges. Once a DAG is constructed, each party independently looks at its local view of the DAG and fully orders all the vertices without sending another message. We can view the DAG as a consensus protocol where the vertex is a proposal and an edge is a vote. A round-based DAG system may look something like this:

Bullshark: The Partially Synchronous Version

Then, Bullshark orders the vertices by locally interpreting the DAG without sending any additional messages (also called zero communication overhead consensus). 

The Sui Economic Model

Sui Token

The total supply of SUI is capped at 10B tokens. Tokens serve four purposes:

1. Users can stake SUI to participate in consensus

2. Asset denomination for paying gas fees to execute and store transactions on the network

3. Used in DApps

4. The ability to participate in future governance.

Gas Price Mechanism

The gas price mechanism in Sui aims to incentivize validators to optimize their transaction processing operations. This will, in turn, help deliver to users low and predictable transaction fees. A byproduct of this is also to prevent DoS attacks. 

At the start of every epoch, validators agree on a network-wide Reference Price. This Reference Price serves as an anchor when users submit their transaction. The expectation is that transactions submitted with gas prices close to Reference Price will be executed in a timely manner. 

The gas price mechanism is meant to align incentives among SUI token holders, users, and the network’s operators. 

It is important to note that users pay separate fees for transaction execution and for storing data with each transaction (see the Storage Fund section). 

How It Works

Gas Price Survey

The Goal: The gas price survey is supposed to set the reference price in which validators are willing to process transactions.

At the beginning of each epoch, all validators are surveyed to submit their reservation price. The protocol then orders these and chooses the reference price from the 2/3rd percentile by stake. 

Tallying Rule

The Goal: Create a community-enforced mechanism for encouraging validators to honor the reference gas price. 

Throughout each epoch, validators obtain signals of the operations of other validators. Each validator uses these signals to build a subjective evaluation of the performance of every other validator. 

Incentivized Stake Reward Distribution Rule

The Goal: Incentivize validators to obtain more stake by lowering gas fees and pricing out inefficient validators.

Storage Fund

A challenge when it comes to blockchain is that if users only pay gas fees for computation, then validators will have to fund their current operations and storage overhead with gas fees from current computations. This is effectively a tax on the system because current users don't internalize the storage cost they're imposing on future validators. In addition, the validator set constantly changes which implies that validators in the active set in the future will have to store data associated with past transactions that they might not have earned rewards from. Sui's solution is to charge users storage fees upfront. A user submitting a transaction must pay for both current execution and for future storage. 

Their storage fund has 3 features:

• It is funded by past transactions. It functions as a tool for shifting gas fees across different epochs. This is to guarantee that validators in future epochs are compensated for their storage costs by past users who created storage requirements.

• The storage fund pays out only on the return on its capital and does not distribute principal. Validators do not receive funds directly from the storage fund so that the fund never loses its capitalization. 

It includes a deletion option. Users would obtain a storage fee rebate whenever they delete previous stored onchain data.   Delegated Proof of Stake

Beginning of the Epoch

At the beginning of each epoch:

1. SUI token holders stake some of their tokens to validators and a new validator committee is formed

2. The reference prices are set as described in the Gas Price Mechanism

3. The storage fund’s size is adjusted using the previous epoch’s net inflow

After this, the Sui protocol computes the total amount of stake as the sum of staked SUI plus the storage fund.

During the Epoch

Users interact with the Sui platform via dapps and other methods, and validators process those interactions. Users will have to pay the associated computation (gas) fees and the storage fees. 

There are cases where users will get a partial rebate of their storage fees when they delete previous transaction metadata. 

During this time, validators continue to measure each other’s performance as noted in the tallying rule part of the gas price mechanism

End of the Epoch

The Sui protocol distributes rewards to consensus participants in two steps:

1. Total amount of staked rewards = sum of all computation fees accrued throughout the epoch + the epoch’s stake reward subsidies 

2. The total amount of staked rewards is distributed across the various entities

Participation in Sui

Validators in Sui operate similar to most PoS blockchains with a few key differences related to throughput and scaling.

• Validators process transactions throughout the epoch period.

• Validators have the voting power over how the transaction proceeds proportional to the amount of stake they have. This incentivizes validators to perform well and earn more delegated power and rewards. 

• At the end of each epoch, staking rewards plus a share of transaction fees are paid out to the validators and delegators in a cycle that rewards performing validators and disincentives poorly performing validators. 

• Validators set the gas price collectively for each epoch, communicating the new gas price to all the participants including end users. With horizontal scaling, the gas price will remain low even with major transaction spikes.

Validators are required to stake SUI in order to be eligible for the validation rewards. Token holders who want to participate in consensus and earn rewards, but don’t want to run their own validator, can delegate tokens to validators. 

Users can withdraw delegated tokens after each 24 hour epoch. During each epoch, the delegated tokens are locked until the epoch is over. 

Three processes occur for each epoch:

1. SUI holders can delegate tokens to validators and a new committee forms

2. The gas price algorithm sets the reference gas price

3. The storage fund’s size is adjusted based on the previous epoch’s inflow

This economic model keeps the validators efficient, rewards the users for delegating tokens, and maintains funding for storage, scaling, and transaction overhead costs.

Why Stake With Coinbase Cloud?

• Multi-cloud, multi-region infrastructure: Our infrastructure is multi-cloud and multi-region to support competitive uptime.

• Experience running nodes in high-throughput, high-performance networks: We have deep experience running nodes in high-throughput networks including Aptos, Solana, Ethereum, Algorand, Flow, and more.

• Enterprise security: We uphold high standards for the quality, reliability, and security of our products.

Contact us to learn more about staking your SUI or other tokens with Coinbase Cloud.