This article aims to learn and understand the UTXO model. It uses an easy-to-understand way to simply sort out the UTXO models and implementation methods from $BTC to $SUI. I will provides a comprehensive overview, which we expand here for clarity and depth, ensuring a professional and thorough analysis.

As one of the core design principles of Bitcoin, the UTXO model has become an important technical paradigm in the blockchain field since its birth. It plays an important role in ensuring transaction security and traceability, and provides another path besides the traditional account balance model.

As blockchain technology has been continuously updated and iterated in recent years, the UTXO model itself has also been constantly evolving and expanding.

Introduction to UTXO and Its Origins

The UTXO model, or Unspent Transaction Output, is a fundamental concept in Bitcoin, where each transaction output that hasn’t been spent is tracked as a UTXO. This model treats transactions like cash, where spending involves selecting specific UTXOs to cover the amount, as opposed to modifying a single balance.

The example: Alice and Bob each start with 5 dollars. In the account model, if Bob robs Alice of 2 dollars, Alice’s balance becomes 3, and Bob’s becomes 7. In the UTXO model, Alice’s 5-dollar UTXO is spent to create two new UTXOs: 2 dollars to Bob and 3 dollars back to Alice, with Bob now holding his original 5-dollar UTXO and the new 2-dollar one, totaling 7 dollars.

This approach, as detailed in Understanding UTXO: A Comprehensive Guide, ensures transparency and prevents double-spending, with each UTXO publicly tracked on-chain while preserving privacy through anonymous addresses.

It is not difficult to see that Alice is left with 3 dollars and Bob is left with 7 dollars. This accounting method, which is similar to elementary school addition and subtraction, frequently appears in the banking system and is called the account/balance model. In it, the balance of an account exists as a single value.

If a different approach from the account model is used, such as UTXO to represent the wealth transfer between Alice and Bob, the diagram will look different:

Comparison with Account/Balance Model

The account/balance model, common in banking, maintains a single balance per account, updated with each transaction Its simplicity but notes state contention issues when multiple transactions modify the same account, often requiring locks and causing performance bottlenecks, especially under high transaction volumes. In contrast, the UTXO model, as explained in Exploring the UTXO Model: What Sets It Apart in the Blockchain World?, avoids this by processing transactions on independent UTXOs, enabling parallel execution without locks, thus improving throughput and concurrency.

Privacy is another advantage, with crypto wallets generating new addresses per transaction, making it harder to link to individuals, unlike the account model’s fixed addresses, which are more susceptible to correlation analysis. However, the UTXO’s limitations in handling complex business logic, such as multi-stage contracts, which led to Ethereum’s account-based model, as mentioned in What is a UTXO? Unspent Transaction Output Explained .

SUI’s Object Model: Bridging UTXO and Account Models

SUI, as detailed in the X post and supported by Object Model | Sui Documentation, centers storage around objects, not accounts, with two key types: OwnedObject (address-owned) and SharedObject.

The OwnedObject enhanced UTXO, where only the owner can operate, and each version is spent once, aligning with UTXO’s principles. For instance, an address-owned object can only be modified by its owner, similar to spending a UTXO.

SharedObject, conversely, is accessible to everyone, akin to the account model, but requires consensus to order reads and writes, addressing state contention, as noted in Sui Components | Sui Documentation. This is managed through special processing like local sorting. The Sui's Object-Oriented Approach highlights how SUI’s model impacts scalability, security, and user experience.

Ownership Types in SUI

Ownership type	Description	Accessibility
Address-owned	Owned by a specific 32-byte address (account address or object ID)	Only accessible to its owner
Immutable	Can't be mutated, transferred, or deleted; no owner	Accessible to anyone
Shared	Shared using 0x2::transfer::share_object function	Accessible to everyone
Wrapped	Organizes data structures by putting a field of struct type in another	Not specified

Owned objects include address-owned, aligning with UTXO, while shared objects are explicitly accessible to all, fitting the account model’s broader access.

My conclusion and Future Considerations

The transition from Bitcoin’s UTXO to SUI’s object model represents a significant evolution, offering flexibility and addressing UTXO’s limitations in complex logic through SharedObject, while retaining UTXO’s concurrency benefits via OwnedObject.

This dual approach, as explored in Exploring Sui’s Object-Centric Model and the Move Programming Language, positions SUI as a versatile platform, potentially setting a new standard for blockchain data models.