Sui Series: Part I - Objects and Ownership
As previously mentioned in the Sui introduction article, Sui is the first decentralized blockchain platform for the vibrant asset economy with high throughput, low latency and an asset-oriented programming model powered by Move. It is known as a high performance, horizontally scalable blockchain with no theoretical limits utilizing extremely low computation resources per transaction.
This part I of the deeper technical dive series into the Sui blockchain architecture. We will start from the object-centric architecture of Sui, designed from the ground-up to facilitate instant settlement, delivering the high throughput, low latency, and low cost needed to power applications for billions of users.
Background
Traditional blockchains, most notably Ethereum 1.0, group transactions into a block, which then saves to the Distributed Ledger (DLT) by adding each new block to its current state. The state and order are saved in a trustless distributed manner through the consensus among the nodes of the network.
Consensus is a mechanism that allows blockchain nodes (validators) to come to an agreement on the validity of transactions and blocks. At the core of most proof-of-stake (PoS) blockchains, there is a consensus concept called BFT, or *Byzantine Fault Tolerance. Its main idea is that even if some (up to one third) of the validators go offline or become malicious, the network can still operate normally.
*BFT: A Byzantine fault (also Byzantine generals problem) is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed.
In a Byzantine fault, a component such as a server can inconsistently appear both failed and functioning to failure-detection systems, presenting different symptoms to different observers. It is difficult for the other components to declare it failed and shut it out of the network, because they need to first reach a consensus regarding which component has failed in the first place. Byzantine fault tolerance (BFT) is the resiliency of a fault-tolerant computer system to such conditions.
All transactions are sequenced linearly to be executed one at a time. Such linear architecture of blockchain, however, fundamentally limits the level of network scalability, blocking mainstream adoption of blockchain that requires high throughput (TPS) and storage efficiency.
Second generation blockchains still rely on the similar linear distributed ledger architecture, with each different improvements to achieve *vertical scalability or *limited horizontal scalability.
*Vertical scaling (“scaling up”) adds more compute power to the nodes/instances, while horizontal scaling (“scaling out”) adds the additional capacity in a system by adding more instances, sharing the processing and memory workload across multiple devices.
*Limited horizontal scaling approaches include techniques like sharding, which is the process of splitting the entire network horizontally to spread the load. Another example are layer 2 rollups, where computations occur off-chain and finalized on the main chain.
Under the linear blockchain architecture context, the level of scalability improvements that can be achieved has been fundamentally limited. Different trade-offs made by the second generation blockchains have either demonstrated bounded scalability improvements or sacrificed security and decentralization, failing to support the adoption of mainstream users to web3.
Sui Blockchain
Sui is the first blockchain to completely defy the linear structure of the conventional distributed ledger design. Sui’s innovation is that they will organize data into independent objects, and transactions are executed in parallel at the individual transaction level.
The intuition is that if a series of transactions are not related to one another (i.e., unidirectional), then the transaction orders do not matter in reality and can be parallelized. For the transactions that are not linked or shared, nodes execute them without going through the consensus with the rest of the nodes in the network.
Below is an analogy made by Evan Cheng, the founder & CEO of Sui.
Figure 2. https://twitter.com/EvanWeb3
Let’s dive deeper into the concept of Sui objects and how it is the core fundamental of what differentiates Sui from all other blockchains as the first object-centric, *DAG-based blockchain with theoretically “limitless” level of scalability.
*DAG: directed acyclic graph. A directed acyclic graph or DAG is a data modeling or structuring tool typically used in cryptocurrencies. It is more efficient at data storage with a tree-like structure of interconnected nodes as its ‘branches.’ Since each node can have more than one parent root, the model allows for more transactions to be validated simultaneously. That is, users do not have to wait for transactions to complete before processing a new one.
Object
At its core, Sui is a distributed ledger that stores a collection of programmable objects that each has a globally unique ID. Unlike the conventional blockchain architectures where accounts are the base entity units, in Sui, the base units are objects. Each object is owned by a single address, and each address can own an arbitrary number of objects. Move Objects in essence are the smart contract programmable entities, and smart contracts are objects as well (objects of objects), called Move Package.
Each object has:
- Unique ID (like hash or contract ID in Ethereum)
- Version (how many times this object was included in transactions, starting from 1)
- Transaction digest (indicates the last transaction that included this object as an output)
- Owner field (showing the owner: account address, another object, immutable or shared)
At a high-level, at the time of transaction execution, objects involved in the transaction get dynamically grouped and processed as a group. This makes each transaction “idempotent”, meaning that these transactions retain their end states no matter how many times they are repeated. This makes these grouped transactions parallel-processable. The Sui blockchain achieves great speed and scalability through optimization for such simple, idempotent transactions.
Every owned object is owned and can be accessed by a single address, and each address can own an arbitrary number of objects. However, shared objects can be accessed by several addresses.
Sui uses this distinction to forgo consensus for owned objects, resulting in very low latency for simple transactions since the client receives confirmation of finality immediately, effectively removing the concept of a block time. This is achieved via multi-lane (parallel) processing, which eliminates the need for transactions to wait for completion of a previous transaction.
Object Ownership
There are 4 types of ownership for objects in Sui, and different ownership types have different transaction processing logics.
Owned by address
This is the most common case. After object creation, ownership is granted to a specific address. The object owned by an address can only be interacted by that address. For example, if an address wants to make a transaction on an NFT, one can only do so if 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.
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. With object wrapping, the wrapped object (again, not a child object) is not stored as a top-level object in Sui storage, and it is not accessible by object ID. In fact, for wrapped objects, there is no unique ID. Instead, it is simply part of the serialized bytes content of the wrapper object.
1 | |
Figure 3. B is a wrapped object of A, the wrapper object. But this is different from B being a child object of A.
When an object is owned by another object, it is not wrapped. Rather, the child object still exists independently as a top-level object and can be accessed directly in the Sui storage. The ownership relationship is only tracked through the owner field of the child object. For example, a multi-sig wallet (which is a smart contract, an immutable object in Sui) owning a set of assets (objects) as child objects. This can also be useful if you still want to observe the child object or be able to use it in other transactions, enabling more sophisticated logic implementation per transaction. There is also a library API to make an object owned by another object.
Immutable Ownership
This means an object is immutable and cannot be mutated by anyone. Because of this, such an object does not have an exclusive owner. Anyone can use it in their Move transaction calls.
All Move packages such as smart contracts on Sui are immutable objects: once published, they cannot be changed. A Move object can be turned into an immutable object through the freeze_object library API. Since these immutable objects cannot be mutated by anyone, they can only be passed as read-only references in Move calls.
Shared Ownership
Lastly, an object can be shared, meaning that anyone can read or write this object. In contrast to mutable owned objects (which are single-writer), shared objects require consensus to sequence reads and writes.
The transaction-object DAG: Relating objects and transactions
Transactions take objects as input, read/write/mutate these inputs, and produce mutated or freshly created objects as output. And as discussed above, each object knows the (hash of the) last transaction that produced it as an output. Thus, a natural way to represent the relationship between objects and transactions is a directed acyclic graph (DAG) where:
- Nodes are transactions.
- Directed edges connect transaction output objects to transaction input objects and are labeled with object references.
To construct this graph, Sui adds a node for each committed transaction and draws a directed edge labeled with object reference O from transaction A to transaction B if A produces object O (i.e., created or mutated O) and transaction B takes object O as an input.
The root of this DAG is a genesis transaction that takes no inputs and produces the objects that exist in the initial state of the system. Note that unlike the traditional blockchain structure where there is only one single genesis state, or root, in the DAG-based blockchain Sui, there are multiple genesis roots. The DAG can be extended by identifying mutable transaction outputs that have not yet been consumed by any committed transaction and sending a new transaction that takes these outputs (and optionally, immutable transaction outputs) as inputs.
The set of objects that are available to be taken as input by a transaction are the live objects, and the global state maintained by Sui consists of the totality of such objects. To be more specific, the live objects for a particular Sui address A are all objects owned by A, along with all immutable objects in the system.
When this DAG contains all committed transactions in the system, it forms a complete and cryptographically auditable DAG view of the system’s state and history. In addition, Sui uses the scheme above to construct a DAG of the relevant history for a subset of transactions or objects (e.g., the objects owned by a single address).
Conclusion
The platform claims to offer unprecedented low latency and scalability for straightforward use cases. As the previous sections explored, Sui utilizes the concept of object and different ownership structure around objects to open up the capability for Sui to bypass consensus regarding straightforward transactions.
Consequently, Sui can use processing resources more efficiently through parallel execution of transactions, thus reducing latency drastically and allowing validators to leverage the totality of their CPU cores. This is the core mechanism behind how Sui platform can operate at network speed without waiting for system timeouts between protocol steps.
Compare this to traditional blockchains that need to wait for predefined timeouts before validating and committing transactions, or the block time. The DAG-based architecture with its object-centric modeling enables Sui to completely defy the concept of block time. Such a parallel nature of the network also enables Sui validators to leverage more machines or devices per validator to increase performance, while more conventional blockchain systems usually run on only one machine per validator.
However, there could also be drawbacks to this design. Compared to other blockchains where every object is shared, Sui programmers often have the choice to implement a particular use-case using shared objects, owned objects, or a combination. While it does open up more sophisticated logic to be implemented on Sui Move smart contracts, this choice can also be an additional load on the developers to manage as it has implications for performance, security, and implementation complexity.
In addition, the dual-protocol system, where one is based on consensus-bypassed handling of simple transactions, and the other on handling transactions with shared objects, is a much larger codebase to be maintained by the development team.
Lastly, transactions involving shared objects take a longer time (2-3s) to achieve finality due to an overhead required for clients on the Sui network before submission to the consensus protocol.
Despite these potential drawbacks, with its promisingly innovative design, Sui does achieve extremely high-performance, being horizontally scalable without a theoretical limit. In tests carried out by Mysten Labs, the test network has managed to achieve a peak throughput of 160,000 tx/sec with a 3-sec latency, which is largely maintained even under faults.
The concept of objects, ownership, and the DAG-based structure of the Sui blockchain is the fundamental of understanding other differentiating features of Sui. In the next section of the article, we will continue our deep dive by covering the next significant differentiator, its unique consensus layer.