From BTC to Sui, ADA and Nervos: UTXO model and related extensions

Source: Geek web3

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, while providing an alternative to the traditional account balance model. As blockchain technology continues to undergo updates and iterations in recent years, the UTXO model itself is also constantly evolving and expanding (such as eUTXO, cell, Strict access list, etc.).

The purpose of this article is to learn and understand the UTXO model. In an easy-to-understand way, we simply sort out the UTXO models and implementation methods from BTC to Sui, Cardano, Nervos, and Fuel to make it better understood.

What is UTXO?

You can understand the UTXO model through an example:

Suppose there are two people, Alice and Bob, who originally had 5 yuan each. Afterwards, there was a conflict between the two parties, and Alice was robbed of 2 yuan by Bob. The final amount of money held by the two is shown in the figure below:

It is not difficult to see , Alice finally has 3 yuan left, and Bob finally holds 7 yuan. 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". Among them, the balance of the account exists as a single value.

If you use a different method from the account model, such as UTXO to represent the wealth transfer between Alice and Bob, the schematic diagram will look different:

At this time, Alice still has 3 yuan left, and Bob still has 7 yuan left, but these 7 yuan do not use a single value. Instead, it was split into “5 yuan” and “2 yuan”. Does this unconventional approach feel unaccustomed? This is a special accounting method - UTXO.

UTXO’s full English name is Unspent Transaction Output, which refers to “Unspent output”. Under this accounting method, each on-chain transaction will be represented as a change and transfer of UTXO. For example, in the transaction event mentioned above, the "5 yuan" originally owned by Alice was used as an input parameter and was marked as UXTO_0, which will be destroyed later; at the same time, the program will generate "2 yuan" (UTXO_1) and " 3 yuan" (UTXO_2) as the output parameter, UTXO_1 will be transferred to Bob, UTXO_2 will be transferred back to Alice, and the wealth transfer between ALice and Bob is completed.

In fact, in the UTXO model, there is no "account" and "balance" ” These two clear concepts,UTXO is just a data structure that helps transaction execution. It records the amount it represents, its related transaction index and other information. Each UTXO represents a transaction input that could be spent but is not spent, with an identified owner. When a transaction occurs, certain UTXOs can be used as inputs. After they are destroyed, new UTXOs will be generated as the transaction output results.

This is the accounting method of Bitcoin: every transaction will have an old UTXO is destroyed and a new UTXO is generated. The total amount of UTXO destroyed is equal to the amount of newly created UTXO (a certain part of which is the handling fee for miners). This way, no one can issue additional funds out of thin air.

Comparison of UTXO model and account/balance model

Suppose a group of users initiate a large number of transaction requests at the same time. What will happen if the UTXO model and the account/balance model are used to process transactions?

In the account/balance model, each user has an account, which records balance information. When a transaction occurs, the balance of the corresponding account needs to be updated, which involves "read" and "write" operations. However, if two transactions involve the same account, there will often be conflicts in reading and writing, that is, status contention. This is a situation that must be avoided.

Traditional database systems often use the "lock" mechanism to solve the problem of certain parts of the data. read and write contention. In this scenario, multiple transactions that form a data contention relationship are often queued and cannot be executed at the same time, which will reduce transaction processing efficiency. When there are a large number of transactions to be processed, the above situation may cause serious performance bottlenecks. Transactions that have data contention with each other may be waiting for a long time and cannot be processed quickly.

Compared with the account balance model, Bitcoin’s UTXO model can better solve the data contention problem. Because in this way, the direct processing object of each transaction is no longer an "account", but each independent UTXO. Since different UTXOs do not interfere with each other, every transaction in the Bitcoin network does not interfere with each other. Therefore, when processing a large number of pending transactions, Bitcoin network nodes can process multiple transactions at the same time without using "locks", which can greatly improve the system's throughput and concurrency performance< /strong>.

In addition, the encryption wallet of the UTXO model usually starts after the user initiates a transaction. , generating a new address, which allows for privacy protection - it becomes more difficult to associate transactions with a specific person - in contrast, the account/balance model is easier to associate because it uses a fixed address sexual analysis.

However, UTXO also has limitations. Its original design is to implement simple currency transfers, not to handle complex business logic. Although scripting language can be used to implement some simple functions, such as multi-signature, time lock, etc. , but because the status information that Bitcoin's UTXO can record is too simple, it is unable to perform some complex operations.

The limitations of Bitcoin UTXO indirectly promoted the birth of "Ethereum" - Vitalik, as one of the earliest contributors to Bitcoin Magazine, is very aware of the shortcomings of Bitcoin. The account/balance model is not only easier to understand for most people, but can also solve the dilemma of UXTO's difficulty in handling rich-state applications, as he said in the "Ethereum White Paper":

UTXO can be spent or unspent; there is no chance of a multi-stage contract or script holding any other internal state. This makes multi-stage options contracts, decentralized exchange offers, or two-stage cryptographic commitment protocols (which are required to securely calculate bounties) difficult to create. This also means that UTXO can only be used to build simple one-time contracts, rather than more complex "stateful" contracts such as decentralized organizations, making meta-protocols difficult to implement. The binary state combined with the value blind spot also means that another important application - withdrawal limits - is not possible.

Application, optimization and extension of UXTO model

Before introducing various applications and optimizations of UXTO, we must first analyze the improvement points of UTXO while maintaining its advantages, which are briefly summarized as follows:

1. Abstract the meaning of the state stored in UTXO.

2. Abstract ownership of state.

3. Resolve the state contention problem of shared UTXO.

In BTC, the only meaning of status is the number of tokens, and ownership is usually defined by public keys. As for status contention, BTC is not designed for dapp, so there is no problem. Be more involved.

Sui

Sui is developed The staff provides two object types: OwnedObject and SharedObject. The former is equivalent to UTXO (more specifically, an enhanced version of UTXO), and the latter is equivalent to the account/balance model. Both can be used at the same time. Here is a reference to Sui technical documentation. Explanation:

An Object can be shared, which means that anyone can read or write to the Object. In contrast to a mutable OwnedObject (which can only have one writer), a SharedObject requires consensus to order reads and writes.

In other blockchains, every Object is shared. However, Sui programmers can often choose to use OwnedObject, SharedObject, or a combination of both to implement a specific use case. This choice may have implications for performance, security, and implementation complexity.

In Sui, Owned Objects are similar to UTXO. Only its owner can operate it, and Objects have version numbers. "A certain version of an object can only be operated by its owner." "Spend once", so "a certain version of an object" is essentially equivalent to UTXO.

As for the problem of state contention, it can be achieved through special processing (local sorting, similar to Fuel) SharedObject.

Cardano

Cardano uses extended UTXO model, abbreviated as eUTXO. eUTXO supports higher programmability while combining the advantages of the Bitcoin UTXO model.

In Cardano, the meaning of state is further expanded through scripts, and the ownership of its state is defined in a more general way, while using UTXO sets to try to avoid state contention problems. Specifically summarized, eUTXO has been strengthened in two aspects:

1. There are more general addresses in the eUTXO model. These addresses can not only be based on the hash of the public key, but can also be defined based on any logic. Under what conditions eUTXO can be spent, that is, the ownership of the state can be programmed.

2. In addition to addresses and values, outputs can carry (almost) arbitrary data, i.e. the meaning of the status can be programmed through scripts.

Specifically, eUTXO allows users to add arbitrary data similar to JSON format to In UTXO, this data is called Datum. Datum allows developers to provide state-like functionality to scripts, which is associated with a specific UTXO.

At the same time, transactions on Cardano can carry parameters related to specific users, called for Redeemer. Redeemer allows transaction originators to define how UTXOs are used, which can be used by dapp developers for various purposes.

When a transaction is verified, the verification script operates using Datum, Redeemer, and a context containing the transaction data. The script contains the logic to use UTXO when the conditions are met.

It should be noted that eUTXO still uses scripts to complete expansion tasks, which is very different from "smart contracts" in the traditional sense (the founder Charles Hoskinson believes that the actual name should be "smart contracts"). Programming Verifier", but the term "smart contract" is more easily accepted by the market).

Nervos

In Nervos ( (i.e. CKB), the meaning of the state is abstracted by typescript, and the ownership of its state is abstracted by lockscript. A simple UTXO optimization model-cell code is as follows:

    pub struct CellOutput {

        pub capacity: Capacity,

        pub data: Vec<u8>,

        pub lock: Script,

        pub type_: Option<Script>,    }

For status contention As for usage issues, CKB is currently promoting research on Open Transaction. Users can propose a partial UTXO to indicate the purpose of the transaction, and then the matchmaker will match it into a complete transaction.

The cell model of Nervos is a "generalized" version of UTXO. Its detailed popular science Jan explained on the Nervos forum:

Layer 1's attention The focus of CKB design with Layer 1 as the design goal is naturally the state. Ethereum divides transaction history and state history into two dimensions. Blocks and transactions express events that trigger state migration rather than the state itself. However, transactions and states in the Bitcoin protocol are integrated into one dimension. Transactions are states, and states are Transaction is an architecture with status as the core.

At the same time, the state that CKB wants to verify and preserve for a long time is not just a simple number (nValue), but any consensus-based data that people think is valuable. Obviously Bitcoin's transaction output structure cannot meet this demand, but it has given us enough inspiration: we only need to generalize nValue and change it from a space for storing integers to a space that can store arbitrary data, and we will get A more general "CTxOut", or Cell.

In Cell, nValue becomes two fields: capacity and data. These two fields together represent a piece of storage space. Capacity is an integer, indicating how big the space is (in bytes). (number is the unit), data is the place where the state is saved, and any byte can be written; scriptPubKey has become lock, just changed a name, which expresses who the owner of this consensus space is - only those who can Only the person who provides parameters (such as signature) to successfully execute the lock script can "update" the state in this Cell. The number of bytes occupied by the entire CellOutput must be less than or equal to capacity. There are many Cells in CKB, and the collection of all these Cells forms the complete current state of CKB. What is stored in the current state of CKB is arbitrary common knowledge, no longer just a certain digital currency.

Transactions still represent state changes/migrations. The change of state, or the "update" of Cell content is actually accomplished through destruction and creation (it does not actually modify the content in the original Cell). Each transaction actually destroys a batch of Cells and creates a new batch of Cells; the newly created Cells will have new owners and store new data, but the total capacity of the destroyed ones is always greater than or equal to the new ones. The total amount of capacity created ensures that no one can issue additional capacity at will. Because capacity can be transferred and cannot be issued additionally, owning capacity is equivalent to owning a corresponding amount of consensus state space. Capacity is a native asset in the CKB network. The destruction of a Cell only marks it as "destroyed". Similar to Bitcoin's UTXO, it changes from unspent to spent and is not deleted from the blockchain. Each Cell can only be destroyed once, just like each UTXO can only be spent once.

The characteristics of such a model are:

1. The state is primary.

2. The owner is an attribute of the state, and each state has only one owner.

3. State is continuously destroyed and created.

So, Cell is a generalized version of UTXO.

Fuel

Fuel adopts Based on the UTXO optimized Strict access list model, this model defines a new UTXO - contract UTXO.

As introduced above, UTXO in BTC has only two attributes: the number of coins and the owner, while contract UTXO provides more basic attributes, including: number of coins, contract ID, contract code hash and storage root.

If using a stateless execution model, the contract code hash and storage root are only required in the contract UTXO. In a stateful execution model, contract UTXOs can omit these fields, but a separate storage element UTXO type is required. A UTXO ID (a unique identifier for each UTXO that can be used as a key in a key-value store database) is the output point that produced the UTXO, or a variation thereof (e.g., a hash of the output point and its fields).

In this model, contract UTXO, like smart contracts, can be called by anyone.

It should be noted that Fuel provides functions that are closer to smart contracts rather than scripts, and the limitations of the UTXO model itself cause countless troubles when applying based on VM. The most typical one is It is the UTXO contention problem. Generally speaking, there are three solutions: one is to process it off-chain such as Rollup; the other is to do additional sorting work in advance, and Fuel uses the latter; the third is just mentioned in the CKB section Open Transaction, that is, each user can submit part of the transaction, and then the matchmaker (similar to the sequencer) will match it into a complete transaction. The corresponding solution for BTC is PBST.

Ending

By combing, Understand the basic principles of UTXO, know the advantages and disadvantages of its model and the account/balance model of ETH, and have a clearer understanding of the UTXO concept and its related extensions.

As one of the core design principles of Bitcoin, the UTXO model plays an important role in ensuring the security and traceability of transactions. With the continuous development of blockchain technology, the UTXO model is also constantly developing. Evolution and expansion (such as EUTXO, cell, Strict access list, etc.) provide more possibilities for the transaction and management of digital assets. Through in-depth study and understanding of the UTXO concept and its related extensions, you can better grasp the blockchain technology essence and lay a more solid foundation for future innovation and application.