IOTA 2.0 Introduction Part 14
In distributed ledgers, there are two primary models for tracking the ownership of digital assets like tokens or NFTs: the Unspent Transaction Output (UTXO) model and the Account model. IOTA 2.0 combines the strengths of both to create a versatile ecosystem for managing digital assets efficiently. Let’s explore each model and how IOTA 2.0 uses them!
The UTXO Model
In the UTXO model, transactions generate outputs, which are registers of the digital assets that were received through the transaction. The same transaction also consumes outputs generated by past transactions. This cycle of generating and consuming outputs enables the easy validation of transactions by identifying conflicts in consumed outputs.
In general, each output is accessible only with the owner’s private key. When issuing a transaction consuming outputs, the owner uses the private key to prove their ownership of the digital assets like tokens, thereby validating the transaction. Consumed outputs are replaced by new ones: the recipient’s output holds the transaction's value, and any leftover value forms another new output.
According to this model, nodes maintain a shared list of all unspent outputs. Whenever a new transaction is included in the ledger, it consumes some outputs and generates new ones.
There are many key advantages to using the UTXO model:
- Parallelism for Transactions: Transactions move funds owned by a single user, so transactions issued by different users consume completely different outputs. Such transactions can be processed in parallel, enabling faster and more efficient transaction validation.
- Simplified Conflict Identification: In the UTXO model, conflicts are easy to classify and identify: If two transactions attempt to consume the same output, it's immediately recognized as a conflict.
Despite these advantages, the UTXO model faces challenges when registering spendable resources such as states that change dynamically (such as exchanging two distinct currencies) or Mana (see our blog post on congestion control). Resources like gas or Mana are necessary to run DeFi applications and smart contracts, but implementing them with a UTXO-based system can be difficult since an asset that represents such a resource could not be spent simultaneously by more than one transaction. The Account model offers a solution to these challenges.
For more insights into the fascinating world of UTXOs, don’t forget to refer to our Wiki article on Data Structures. We also recommend this blog post that includes thoughts on UTXOs by Vitalik Buterin, Co-Founder of Ethereum.
The Account Model
The Account model maintains a list of balances, updating it with each validated transaction or protocol-triggered event, like block rewards. Although it sounds much simpler than using the UTXO model, just keeping balances can lead to complications. For example, conflicts aren’t so simple to identify. Imagine a user with a balance of two tokens attempting to send three transactions of one token each. One of these transactions will be deemed invalid, but which one? By enabling transactions with a more complex logic, the ordering between these transactions starts to matter, and reaching consensus on transaction ordering is an extremely difficult task. So the cost of using the Account model is a more complex consensus module.
In this model, the list of balances is maintained as a global ledger state that is changed by each validated transaction. Even the slightest change in any account, no matter how simple, necessitates an update to the global ledger state, which, as mentioned above, is no easy task. This complexity poses challenges for applications that rely on frequent, dynamic value changes. However, this feature, which enables the modification of an account by issuing a transaction without knowing the current value of the account, can also open up many advantages. For example, one can issue multiple transactions without waiting for one of them to be settled. Such flexibility would be possible in the UTXO model only if the assets of the owner are already separated into different outputs.
Despite the good points of the Account model, we acknowledge the advantages of each model. So building IOTA 2.0 is not simply about choosing one of them, but how to use each to our advantage.
The IOTA 2.0 Model
The IOTA 2.0 protocol extends the UTXO model to enable the flexibility of the Account model. This approach builds on a model introduced in IOTA 1.5, Alias Outputs, and extends it into what we call Account Outputs.
Put simply, Account Outputs are outputs that carry a state within themselves. Instead of a single owner, the output now has two controlling parties: a “state controller” capable of changing the contained state and a “governor” who determines the owner (but can’t change the output’s state). This feature enhances the flexibility of the UTXO model and further enriches the asset management capabilities of IOTA 2.0.
Once conflicts have been efficiently resolved on the DAG and the resulting state has been committed, the state of the Account Output and properties associated with it can be stored as an account state. This account state conforms to the Account model in the sense that its values can be updated independently of any specific output, opening up a wider range of applications possible with a purely UTXO-based system.
IOTA 2.0 enables its users to benefit from the strengths of Account-based models while providing a UTXO-based ledger that enables secure asset management, parallel transactions, and easy conflict identification. Uniting the best of both worlds to achieve true versatility and performance, all to empower our users and achieve digital autonomy!
For a deeper dive into the classification of digital asset ownership models and the differences between UTXO and Account-based models, check out UTXO in Digital Currencies: Account-based or Token-based? Or Both?
The next blog post in this series looks at mempools and how IOTA 2.0’s unique approach limits MEV to protect users against value extraction.
IOTA 2.0 Introduction
Part 11: What Makes IOTA 2.0 Secure?