The Sui blockchain stores its state data not in accounts, but in objects and these objects are organized in a Directed Acyclic Graph (DAG). In this article, we will look at what a DAG is and what the benefits of doing this are.
Before we get into any of that though, it is best that we quickly outline what a Sui object actually is. A simple example of an object could be a token balance object. All objects require a unique identifier (UID). Furthermore, for our token object, we will also need its token type, the balance, and the owner. This implies that any user can be the owner of many token objects of the same kind.
A DAG is essentially a graph that can not have a circular path - meaning that only new nodes can be added, and there must never be an edge pointing back. When we look at Sui objects, instructions can create new nodes from existing ones. For instance, think of a token object with a balance of 100 tokens which is then split into two token objects, each with a balance of 50. We might do that in order to transfer one of the token objects to someone else by updating the owner of the object to the recipient's address.
DAGs are not new in the blockchain space and a number of projects run them in production. One of the, perhaps, more well-known ones is IOTA. DAGs do not need conventional blocks, as they extend onward from one node to the next - a transaction is a node in the graph. This also means that there is no need to wait for a specific block time.
However, due to the complexities that they introduce, DAGs have not exactly taken the blockchain space by storm, and some newer approaches, such as the one chosen by Massa, restrict the width of the graph by essentially turning it into a sharding/threading approach.
The great promise of DAGs is their speed with transaction finality being archived quickly and Sui heavily focuses on single-owner objects for that reason. Our token object has one owner and the owner is, of course, the only one who can modify the data. All these single-owner objects in Sui do not require consensus to the same degree as shared ownership objects would. Therefore, a transfer of a token object from one user to another can be done in direct communication with the validator nodes. By acquiring the majority of votes from the validators, the transaction is guaranteed to become irrevocable. So depending on network bandwidth and latency, such transactions can possibly settle in a second or even less.
Since finality can be archived so quickly, Sui could be an interesting choice for latency-dependent applications such as games. It is also possible for application developers to provide a gateway service that handles transaction submissions on behalf of their users (think users of bandwidth-limited mobile devices). This service would not require access to any private keys.
For shared ownership objects that depend on the total ordering of events, Sui does offer consensus with Narwhal and Bullshark, which is a complex topic of its own.
Sui, like Aptos, uses the Move language for smart contract development. Some changes had to be made to the language in order to accommodate Sui's object store and the language is referred to as Sui Move.
First and foremost, the Move global storage, which uses addresses, becomes a global storage for objects based on GUIDs (Globally Unique Identifiers) in Sui Move.
With that, the key ability used in Move becomes a marker for objects in Sui. Any struct with the key ability must start with the field id: UID.
Sui Move also introduces a constructor function called init with one parameter: fun init(ctx: &mut TxContext). This constructor could, for example, be used to create singleton objects holding some relevant contract state.
If you want to learn more about Sui development, check out the Sui Move Book