From BTC to Sui, ADA and Nervos: The UTXO Model and Extensions

As one of the core design principles of Bitcoin, the UTXO model has been a significant technical paradigm in the blockchain domain since its inception. It plays a crucial role in ensuring transaction security and traceability, providing an alternative path beyond the traditional account balance model. With the continuous evolution and expansion of blockchain technology in recent years, the UTXO model itself has been undergoing constant evolution and extension, such as eUTXO, cell, Strict access list, and others.

This article introduces the UTXO model in plain language, providing a brief overview of the UTXO model and implementation methods of BTC, Sui, Cardano, Nervos, and Fuel.

What is UTXO?

To illustrate the UTXO model, we use an example:

Imagine two individuals, Alice and Bob, each initially having $5. Subsequently, a conflict arises, and Alice was robbed of $2 by Bob. The final holdings for each are as follows:

It is evident that Alice ends up with $3, and Bob ultimately holds $7. This elementary arithmetic-like accounting method is commonly seen in banking systems and is referred to as the “account/balance model.” In this model, the balance of an account exists as a single numerical value.

If we were to adopt a different approach from the account model, such as using UTXO to represent the wealth transfer between Alice and Bob, the illustrative diagram would take on a different appearance:

At this point, Alice still has $3, and Bob still has $7, but these $7 are not represented by a single numerical value. Instead, they are broken down into “$5” and “$2.” Does this unconventional approach feel somewhat unfamiliar? This is the unique accounting method known as UTXO.

The English acronym UTXO stands for Unspent Transaction Output. Under this accounting approach, each on-chain transaction manifests as changes and transfers in UTXOs. For instance, in the mentioned transaction event, Alice’s initially owned “$5” serves as input parameters, labeled as UTXO_0, which will be marked as spent; simultaneously, the system generates “$2” (UTXO_1) and “$3” (UTXO_2) as output parameters. UTXO_1 will be transferred to Bob, and UTXO_2 will be returned to Alice, thus completing the wealth transfer between Alice and Bob.

In the UTXO model, there are no explicit concepts of “accounts” and “balances.” UTXO serves as a data structure that aids in transaction execution, recording information such as the amount it represents and the associated transaction index. Each UTXO represents an unspent transaction input, with a designated owner. When a transaction occurs, certain UTXOs can be used as inputs, and upon their destruction, new UTXOs are generated as transaction outputs.

This is how Bitcoin keeps accounts: with each transaction, old UTXOs are destroyed, and new ones are created. The total amount of destroyed UTXOs equals the amount of newly created UTXOs (with a portion allocated as transaction fees to miners). This ensures that funds cannot be arbitrarily increased.

Comparison between UTXO model and Account/Balance Model

Suppose a group of users initiates a large number of transaction requests simultaneously. How would the situation be handled using the UTXO model compared to the account/balance model?

In the account/balance model, each user has an account with recorded balance information. When a transaction occurs, the corresponding account balance needs to be updated, involving both “read” and “write” operations. However, if two transactions involve the same account, it often results in read-write conflicts, leading to state contention, a situation that must be avoided.

Traditional database systems typically address read-write contention with a “locking” mechanism. In such a scenario, transactions causing contention for the same data often need to queue up, preventing simultaneous execution and reducing transaction processing efficiency. When there is a large number of transactions awaiting processing, this can create significant performance bottlenecks, with transactions in contention facing prolonged wait times without swift processing.

In contrast to the account balance model, Bitcoin’s UTXO model is better equipped to handle data contention issues. In this approach, each transaction’s direct processing entity is no longer a specific “account” but rather individual, independent UTXOs. Since different UTXOs do not interfere with each other, each transaction in the Bitcoin network operates independently. As a result, Bitcoin network nodes can process multiple transactions simultaneously without the need for “locks,” significantly improving system throughput and concurrency performance.

Additionally, in the UTXO model, encrypted wallets typically generate a new address for the user after initiating a transaction. This approach enhances privacy, making it more challenging to associate a transaction with a specific individual. In contrast, the account/balance model, utilizing fixed addresses, is more susceptible to association analysis.

However, the UTXO model has its limitations. It was initially designed to facilitate simple currency transfers and is not well-suited for handling complex business logic. While basic functionalities such as multi-signature and time locks can be implemented using scripting languages, the minimal state information that Bitcoin’s UTXO can record makes it less capable of handling more intricate operations.

The limitations of Bitcoin’s UTXO indirectly contributed to the emergence of “Ethereum.” Vitalik, one of the earliest contributors to Bitcoin Magazine, was well aware of Bitcoin’s shortcomings. The account/balance model, which is easier for most people to understand, addresses the challenges UTXO faces in handling rich-state applications. As Vitalik stated in the Ethereum whitepaper:

UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex “stateful” contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible.

Application, Optimization and Extension of the UXTO model

Before delving into various applications and optimizations of the UTXO model, let’s analyze the areas for improvement while preserving its advantages. These can be summarized as follows:

1. Abstracting the meaning of the state stored in UTXOs.

2. Abstracting ownership of the state.

3. Resolving state contention issues when sharing UTXOs.

In BTC, the state’s sole meaning is the token quantity, ownership is typically defined using public keys, and state contention is not extensively addressed as BTC was not designed for dApps.

Sui

Sui provides developers with two types of objects: OwnedObject and SharedObject. The former is akin to UTXO (specifically an enhanced version), while the latter is comparable to the account/balance model. Both can be used simultaneously.

An Object can be shared, meaning anyone can read or write to that Object. Unlike the mutable OwnedObject (with only one writer), SharedObject requires consensus to order reads and writes.

In other blockchains, every Object is shared. However, Sui developers can typically choose to use OwnedObject, SharedObject, or a combination of both to implement specific use cases. This choice may impact performance, security, and implementation complexity.

In Sui, Owned Objects are similar to UTXOs, and only their owner can operate on them. Objects also have version numbers, and a version of an object can only be spent by its owner once. Therefore, a version of an object essentially corresponds to a UTXO.

Regarding state contention issues, Sui addresses them through special handling (local ordering, similar to Fuel) in SharedObjects.

Cardano

Cardano utilizes an extended UTXO model known as eUTXO. eUTXO supports increased programmability while retaining the advantages of the Bitcoin UTXO model.

In Cardano, the meaning of the state is further expanded through scripts, and ownership of the state is defined in a more generalized manner. UTXO sets are used to minimize state contention issues. Specifically, eUTXO is enhanced in two aspects:

1. The eUTXO model includes more generalized addresses. These addresses are not solely based on the hash of public keys but can be defined based on any logic specifying the conditions under which eUTXO can be spent, enabling programmability of state ownership.

2. In addition to addresses and values, outputs can carry (almost) any data, allowing for programming the meaning of the state through scripts.

More specifically, eUTXO allows users to add arbitrary data in a JSON-like format to UTXOs, referred to as Datum. Datum enables developers to provide state-like functionality for scripts, associated with specific UTXOs.

Moreover, transactions on Cardano can carry parameters related to specific users, known as redeemers. Redeemer allows the initiator of the transaction to define how UTXOs are utilized and can be employed by dApp developers for various purposes.

When a transaction is validated, the validation script operates using Datum, Redeemer, and the context containing transaction data. This script includes the logic for using UTXOs when conditions are met.

It’s worth noting that eUTXO still achieves extension tasks through scripts and differs significantly from the traditional notion of “smart contracts” (Charles Hoskinson, the founder, suggests calling it a “programmable validator,” but the term “smart contracts” is more widely accepted in the market).

Nervos

In Nervos (CKB), the meaning of the state is abstracted by TypeScript, and ownership of the state is abstracted by a lockscript. A simple UTXO optimization model in the form of a cell code is as follows:

pub struct CellOutput {

    pub capacity: Capacity,

    pub data: Vec<u8>,

    pub lock: Script,

    pub type_: Option<Script>,

}

As for the issue of state contention, CKB is currently advancing research on Open Transaction, where users can propose a partial UTXO specifying the transaction’s purpose, and then matchmakers aggregate them into a complete transaction.

Nervos’ cell model is a “generalized” version of UTXO, and Jan provided a detailed explanation on the Nervos forum:

The focus of Layer1 is on state, and with Layer1 as the design target, CKB naturally focuses on state.

Ethereum separates transaction history and state history into two dimensions, where blocks and transactions represent events triggering state transitions rather than the state itself. In contrast, the Bitcoin protocol merges transactions and states into a single dimension—transactions are the state, and the state is the transaction. It is an architecture centered around the state.

At the same time, CKB aims to verify and preserve not just nValue as the state but any data deemed valuable and consensus-approved for long-term preservation. Bitcoin’s transaction output structure is inadequate for this purpose, but it has provided us with ample inspiration. By generalizing nValue and transforming it from a space storing integers into a space capable of holding any data, we obtain a more generalized “CTxOut” or Cell.

In a Cell, nValue becomes two fields: capacity and data. These fields jointly represent a storage space, where capacity is an integer indicating the size of the space in bytes, and data is where the state is stored and can accommodate any byte sequence. The scriptPubKey becomes lock, just a change in name, expressing who the owner of this consensus space is—only the person who can provide parameters (such as a signature) to make the lock script execute successfully can “update” the state in this Cell. The total number of bytes occupied by the entire CellOutput must be less than or equal to the capacity. CKB has numerous Cells, and their collection forms the complete current state of CKB, storing shared knowledge rather than just a specific digital currency.

Transactions still represent changes/migrations of the state. The change in state or the “update” of cell content is actually accomplished through destruction and creation (not by directly modifying the content of the original cell). Each transaction effectively destroys a batch of cells while simultaneously creating a new batch of cells. The newly created cells have new owners and store new data, but the total capacity destroyed is always greater than or equal to the total capacity created, ensuring that no one can arbitrarily increase the capacity. Because capacity can be transferred but not arbitrarily increased, possessing capacity is equivalent to owning a corresponding amount of consensus state space. Capacity is the native asset in the CKB network. The destruction of a cell merely marks it as “destroyed,” similar to how unspent Bitcoin UTXOs become spent and are not physically removed from the blockchain. Each Cell can only be destroyed once, just like each UTXO can only be spent once.

The characteristics of this model are:

1. State is of primary importance.

2. Ownership is an attribute of the state, with each state having a single owner.

3. States are continually destroyed and created.

Therefore, a cell is a generalized version of UTXO.

Fuel

Fuel adopts the Strict Access List model, which is an UTXO optimization based on the concept of Contract UTXO.

As introduced earlier, traditional UTXO in BTC only has two attributes: coin quantity and owner. In contrast, Contract UTXO provides additional fundamental properties, including coin quantity, contract ID, contract code hash, and storage root.

If using a stateless execution model, only Contract UTXO requires contract code hash and storage root. In a stateful execution model, these fields can be omitted in Contract UTXO, but a separate Storage Element UTXO type is needed. The UTXO ID, a unique identifier for each UTXO serving as a key in a key-value storage database, is generated from the output point of the UTXO or its variant (e.g., hash of the output point and its fields).

In this model, Contract UTXO, similar to smart contracts, can be called by anyone.

It’s essential to note that Fuel provides functionalities closer to smart contracts rather than scripts. The limitations of the UTXO model itself make application development with a VM challenging, especially in handling UTXO contention issues. There are generally three solutions: first, process off-chain, such as in rollup; second, pre-sequencing additional work, which Fuel employs; third, the above-mentioned Open Transaction in CKB, where each user can propose partial transactions, and a matchmaker (similar to a sequencer) combines them into complete transactions. The corresponding solution in BTC is PBST.

Conclusion

From this article, we have gained an understanding of the fundamental principles of UTXO, recognized the strengths and weaknesses of its model compared to Ethereum’s account/balance model, and obtained a clearer insight into the concept of UTXO and its related extensions.

As one of the core design principles of Bitcoin, the UTXO model plays a crucial role in ensuring the security and traceability of transactions. With the continuous evolution and expansion of blockchain technology, the UTXO model has been developing (such as EUTXO, cell, Strict Access List), providing more possibilities for the transaction and management of digital assets. Through in-depth research and understanding of the UTXO concept and its related extensions, we can better grasp the essence of blockchain technology, laying a more solid foundation for future innovations and applications.

Disclaimer：

1. This article is reprinted from [极客 Web3], All copyrights belong to the original author [0xAyA]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.