Sui Jargon Deconstructed

We explain commonly used terms and concepts such as layer 1, permissionless, and proof-of-stake.

Sui Jargon Deconstructed

In online discussions about Sui, you’ll come across phrases such as “proof-of-stake layer 1 blockchain” and “decentralized network,” but not a lot of explanation about what those terms mean. Let’s take a look at what Sui is and how it works.

First of all, we need to understand the term “blockchain.”

Another definition for blockchain is a distributed database or ledger, which still doesn’t help in understanding much. The closest analogue that comes to mind is a cloud service. There are several giants of the industry, such as Google, Amazon, and Microsoft, who provide data storage and computing power to millions of projects and companies all around the world. A cloud is essentially a collection of servers sharing resources to act as a single platform.

However, relying on a centralized cloud service implies several limitations:

  • The server you use can simply shut down
  • You sacrifice privacy

Blockchains, on the other hand, offer decentralization. To put it simply, there is no single person or company controlling the network and data. A blockchain is maintained by all machines, or servers, connected to it. As long as a small number of these servers are still connected and running, the network can’t be turned off. On Sui, we refer to these servers as validators because they verify transactions on the blockchain.

For a deeper understanding of blockchain technology, IBM offers an excellent guide.

The term “layer 1,” when applied to Sui, means that it is a base level blockchain, that its software runs on a collection of independently maintained validators. In contrast, a layer 2 or higher level blockchain is an addition to a layer 1 blockchain. A layer 2 blockchain might be built on top of a layer 1 to increase scalability or add features that don’t exist in the original software.

This diagram of Sui’s network architecture shows how apps send their transactions to validators for verification.

The concept of “proof-of-stake” gets a little more complicated. The validators that support a blockchain must agree on which transactions taking place are valid, a process known as consensus. Consensus isn’t a problem when a single company runs all the servers, but when there are many independent operators, there must be a mechanism for them to agree on approving any transaction. Proof-of-stake is essentially the credential any of those independent operators needs to show they have the authority to approve transactions.

The independent operators running validators that support the Sui blockchain also deserve compensation for their efforts, because running a server costs money. As is common on blockchains, Sui supports a token native to its blockchain network, referred to as SUI, that validator operators can earn for approving transactions. Their stake, as referred to above in the phrase proof-of-stake, is the amount of tokens they hold.

You can also think about Sui as an operating system, similar to Linux, Windows, and macOS. Builders can write applications that run on these operating systems. On Sui, builders use a relatively new programming language called Move. Common programming languages for other blockchains include Rust and Solidity.


You’ve probably heard about non-fungible tokens (NFTs), which are most often associated with giving provenance to unique image files or other digital art forms. On most blockchains, when you get an NFT, you are really getting a file verifying your ownership and an address, similar to a web site URL, that points to the actual image file. Sui also has NFTs, although these fit under the larger category of data objects on the blockchain. Data objects can be just about anything from the digital realm, including a picture, a signature, or a document. Most importantly, Sui stores these objects on the network.

Sui uses concepts of shared and owned objects, a design that allows for more efficient transaction processing. On Sui, if someone owns an object, they can give it directly to another person. This very simple transaction uses very few network resources.

In the Sui Capys prototype, a game launched on Sui Devnet, each Capy exists as an object on the Sui network.

A shared object may belong to multiple addresses. Transactions involving shared objects must be approved by validators on the blockchain, a somewhat more resource intensive process. On most blockchains, all objects are shared, so every transaction must go through this approval process. Many transactions on Sui involve simple one-to-one exchanges, reducing resource cost.

To get a little more technical, each Sui object must have the following fields:

  • Unique ID: Similar to hash or contract ID on Ethereum
  • Version: Showing the objects number of transactions, beginning with 1
  • Transaction digest: Indicating the last transaction that included this object as an output
  • Owner field: Showing the owner, which can be an account address, another object, immutable, or shared

Of course, builders can customize objects by including other fields. Sui allows a great amount of creativity in object design.

As a popular use case, a builder could create a game consisting of objects. For example, in a racing game, a player’s car would be an object. The player would own the object in the context of Sui. Cars in the game could be modified, so players can add paint jobs, better tires, superchargers, and other upgrades to make the car more competitive. Each of those upgrades would be a separate object, and when acquired by the player and added to the car, these objects would be owned by the car object in the context of Sui.


We mentioned shared and owned objects above. Let’s go a little deeper into how Sui processes transactions using these different types of objects. We use the term consensus when referring to validators on Sui verifying a transaction. Sui only requires consensus for shared objects. Common transactions, involving owned objects, do not require consensus.

Owned objects are not included in the “blocks” from which the blockchain gets its name. They interact directly with validators on Sui using simplified algorithms. Because of this architecture, owned object transactions occur almost instantaneously. In practical terms, these simple transactions might involve one player giving another a car in a racing game, someone posting a message to a social network, or submitting a vote in a poll.

Sui’s novel consensus mechanism performs both simple and complex transactions, with the former requiring fewer resources and processing very quickly.

In technical terms, here’s how Sui carries out these simple transactions:

  1. A sender broadcasts a transaction to all Sui validators.
  2. Each Sui validator replies with a vote for this transaction. Each vote has a weight based on the validator’s stake.
  3. The sender collects a Byzantine-resistant-majority of votes into a certificate and broadcasts that back to all Sui validators. This action settles the transaction, recording it on Sui and ensuring that the transaction will not be dropped or revoked.

Shared objects follow a more complex transaction, as described in these steps:

  1. The sender broadcasts a transaction to all Sui validators.
  2. Each Sui validator replies with a vote for this transaction. Each vote has a weight based on the validator’s stake.
  3. The sender collects a Byzantine-resistant-majority of votes into a certificate and broadcasts that back to all Sui validators. This time, however, the certificate is sequenced through a process called Byzantine agreement, where the validators have to come to consensus.
  4. Once the transaction has been successfully sequenced, the sender broadcasts the certificate to the validators to settle the transaction.

As pointed out above, single transactions bypass consensus and process almost instantly. Transactions using shared objects must go through consensus. If Sui is processing many transactions at once using shared objects, each consensus must happen sequentially, potentially delaying each transaction. Most other blockchains only allow this latter transaction type, and have no ability to bypass consensus.


Sui’s distributed computing model works more like a traditional cloud service than a typical blockchain. Many blockchains use a tokenomics model to control server load: as load increases, gas fees increase. Higher gas fees reduce the number of transactions, as users can only pay up to a particular amount.

As load increases on Sui, validators can simply add more processing power, similar to how Amazon Web Services might add more servers as a client’s traffic increases. Validators are incentivized to add capacity because they earn more gas fees instead of higher fees.

This model not only lets Sui scale to support increased user traffic, it also maintains flat and stable gas fees, allowing more users to join.

Increasing network capacity in this manner ensures that games run quickly, productivity apps respond reliably, and social media posts globally, as a few examples. Builders can set fees based on subscription models that won’t be overwhelmed by rising gas prices. The network infrastructure won’t succumb to validator gas fee wars or server failures.

Move on Sui

As mentioned above, Move is the native programming language for Sui. The core Move language was created in 2018 specifically for smart contract programming on blockchains. Move’s creators saw the need for first-class abstractions of assets and access control, something not present in previous blockchain programming languages. These abstractions make sense for blockchains, as decentralization puts assets and access control at the center of most activity on the network.

However, as Sui’s founding team began developing this new blockchain, they saw a need to further refine Move. Although Move was designed specifically for programming smart contracts on blockchains, it still lacked native support for blockchain-specific concepts such as accounts, transactions, time, and cryptography. Blockchains needed to build support for these features, which could not only be time-consuming, but also lead to inconsistent implementations of critical features such as security.

Move was designed to incorporate everything a blockchain developer would need to create performant, secure, feature rich applications.


As many others, I’m genuinely excited to build on Sui. After the months of work put in by Sui’s many contributors before its initial launch and its continuing evolution, I believe this Layer 1 blockchain offers innovations not available on other networks.

NFTs and gaming projects using Sui’s unique architecture are among my interests. In my opinion, Sui has the components required for GameFi projects to step into the next level of evolution and adoption within web3. As an open source network, I expect to see many refinements and improvements that will help Sui adapt and lead to mass adoption. I’m happy to be among the first to try it.

The Sui Foundation accepts article contributions from across the Sui community. The views and opinions expressed by community members may not reflect those of the Sui Foundation.