About Sui: “Build without Boundaries”: Part I — Objects

Sui is a layer 1 blockchain developed by Mysten Labs for blockchain mass adoption.

Mysten Labs

Mysten Labs team is composed of former Facebook Diem Projects core members. Among the 5 co-founders, 4 of them are former Facebook, and other team members are primarily from the same members of the Diem project. The entire team is around 35 people.

The similar backgrounds of the teams having its Facebook root and being in the same Move ecosystem, Mysten Labs and Aptos are frequently mentioned together, but the blockchain architecture designs are quite different between the two. Recently, Mysten Labs announced their Series B funding at the amount of $300M with $2B valuation.

Characteristics

How is Sui different from other blockchains?

Previous blockchains group transactions into a block, which then saves to the Distributed Ledger (DLT) by adding each new block to its current state. Such ledger’s state and order are saved in a trustless distributed manner through the consensus mechanism among the nodes of the network. Various networks have developed this consensus protocol on their chain by designing the base Byzantine Fault Tolerant (BFT) consensus algorithm for their own purposes (Practical Byzantine Fault Tolerance, etc.).

* Byzantine Fault Tolerance is a computer system’s ability to continue operating even if some of its nodes fail or act maliciously.

This traditional blockchain network architecture has a limitation in that such a linear mechanism of the system becomes the main bottleneck for achieving high transaction volume scalability. Many so-to-called the Ethereum Killers came up to solve this problem, but there had been no player as of yet that achieved the high scalability without sacrificing the decentralization.

Sui also declares that such linear designs of blockchain networks are not the ultimate solution. Sui rather makes the premise that most of the transactions on chain are not related to one another mostly being unidirectional. Furthermore, they even believe that the transaction orders do not really matter in reality because the transaction originators already decide the order of transactions.

Sui blockchain pursues rather parallel design for processing transactions on the network. And the design is not based on the concept of “block” like other networks where the transaction validation happens at a block level. Rathern, the validation happens at the individual transaction level, minimizing the consensus load on the network by involving consensus when needed for ordering only the “linked” transactions. The consensus-skipped transaction ordering is called casual ordering, while the consensus achieved ordering is called total ordering.

Object

The Object based system is the biggest differentiating factor of Sui compared to other blockchains. Unlike the conventional blockchain architectures where accounts are the base entity units, in Sui, the base units are objects. This makes Sui blockchain a distributed ledger system for managing these individual objects.

Objects in essence are the smart contract programmable entities, called Move Objects. In fact, smart contracts themselves are objects as well (objects of objects), called Move Package.

At the time of transaction execution, objects involved in the transaction get dynamically grouped and processed as a group. This makes Sui a dynamic, object oriented blockchain architecture.

Object Metadata

Every object has Metadata with the following structure:

• Unique ID: a unique id generated by the transaction that created the object, at the time of object creation
• Integer Version — total number of transactions contained in the object.

*Newly created object has the value “1” for version, that being the transaction that created the object.

• Transaction Digest — information of the last transaction that includes this object as one of its outputs
• Owner — ownership information that controls who can “access” the object

Through object metadata, validators or anyone can verify the casual order history of objects on the network.

Object Ownership

There are 4 types of ownership for objects in Sui, and different ownership types have different transaction processing logics.

1. Owned by address: The most common case. After object creation, ownership is granted to a specific address. The object owned by an address can only be interacted only by that address. For example, if an address wants to make a transaction on an NFT, one can only do so the address has the ownership on that NFT. In such scenarios, the “order” of transactions around the “Owned Objects” are solely determined by the owner, thus it does not require network consensus for ordering.
2. Owned by another object: Objects owned by another object as “child objects”. These child objects are still objects on their own, saved to the network like any other objects. Note that this is different from “object wrapping” in Sui, where in wrapping, the wrapped object solely resides in the wrapping object. This such case, the wrapped object does not have a unique ID, and thus is not saved in the network ledger database.
3. Immutable: No one can access or own the object. Move Packages (Smart contracts) are examples of immutable objects. Other objects can also become immutable via freeze_object API.
4. Shared: Anyone can access and interact with the object. Transactions accessing shared objects do require “total ordering” through consensus.

* For an owned object, the transaction originator, who must be also the owner of the object, determines the order. For a shared object, since there is no owner, all transactions accessing the object need to be ordered through consensus.

This ownership structure design enables Sui developers to code more sophisticated logic into their dapps or protocols with fewer security concerns in mind.

On Part II, we will cover Sui Consensus.