In the current blockchain world, there are two ways to record and save state:
UTXO model (Unspent Transaction Output) — Bitcoin
Account model — Ethereum, CITA
Bitcoin was initially designed to realize a peer-to-peer electronic cash system. In the Bitcoin system, each transaction takes UTXOs generated by the previous transactions, then ‘spends’ them to create new UTXOs. The ‘balance’ of an address at any given time is the sum of all the UTXOs currently spendable by that address. The global state at any given time is the set of all spendable UTXOs.
Ethereum forms a more general protocol and supports a Turing-complete programming language that allows developers to compile smart contracts and create decentralized applications. Because the UTXO model is weak in saving state and programmability, Ethereum employs the account model.
In this post we will review the advantages and disadvantages we have found with these two models:
UTXO Model
In the UTXO model, transactions represent changes in the UTXO set. Concepts of account and balance are handled by higher abstractions, like wallets, which locate all UTXO’s under control of an address and aggregate them to display an ‘account balance’.
Advantages of UTXO Model-based systems:
The Calculation is off-chain and transactions are both results and proofs.
Nodes verify the integrity of a transaction and place it into the blockchain, with no more calculation of the transaction or extra state storage (other than storage for transactions and blocks) necessary. Calculation of outputs in a transaction is done by a wallet and to some degree, this eases the computational burden on the blockchain.
2. Transaction inputs always link to existing UTXOs (except for new coins that are created in miners’ coinbase transactions)
Because of this link, transactions can’t be replayed in the same chain and sequence order/dependency is easily authenticated. It is also easy to verify if a UTXO has been spent.
3. In UTXO model transactions can easily be processed in parallel.
4. In the UTXO model’s stateless environment, users are encouraged to use new addresses for every transaction, improving privacy to some degree.
Disadvantages of UTXO Model-based systems:
1. A UTXO model-based blockchain is weak in programmability, complex computation is almost impossible.
Implementation of complex logic or any stateful contract on a UTXO-model based blockchain is complicated, resulting in high storage cost and low state space utilization.
2. As the number of UTXO inputs grow, the number of associated witness scripts increase accordingly as well. Verifying these scripts and storing witness data increases the computational and storage burdens on a UTXO-based blockchain.
Account Model
In the account model, world state is stored on nodes locally, not transferred with blocks. Nodes reach agreement on the state by comparing StateRoot (the Merkle root of the global state).
Transactions are interpreted as events to the blockchain state machine and the Ethereum Virtual Machine computes the state transition result of these events based on prior blockchain state. In this model, input data (transactions) that affect blockchain state are syntactically separated from the result of transactions (output data).
Advantages:
1. Accounts are stateful, providing an overall account balance and giving developers an abstraction that is easy to understand, interact with and build applications for.
2. Bulk transactions are more efficient. Let’s contrast with an example of a mining pool paying mining rewards to a number of addresses:
In the UTXO model, each input requires a single witness script and each output requires a single locking script. Transfers to many addresses will create a large amount of transaction data and verification/storage of this data will become expensive.
In the Account model, the mining pool can create one contract to share mining profits and with just one transaction (requiring only one signature) can create many transfers.
Disadvantages:
1. Because Ethereum account model transactions contain only an event, not a specified input and output state, they must be evaluated for correctness (given the prior blockchain state) by the EVM and any protocols built on top. Besides adding complexity, this approach does not provide certainty to the user that a proposed state transition will be valid prior to evaluation by the state machine.
2. To establish a Lightning/Raiden network or Plasma on an account model-based blockchain, new proof verification mechanisms are required to prove state transition validity, this is unnecessary in the UTXO-based model. Additionally, child chains in a Plasma-like construction require their own complex protocols to initiate proper state transitions on parent chains.
UTXO Model Vs. Account Model
With an analysis of the pro’s and con’s of each model above, we have made some comparisons:
1. About calculation:
While it has been stated that UTXO transactions are computationally simpler compared to account-model transactions, this description is not entirely accurate for two reasons:
(1) Most bitcoin trades use Pay to Script-Hash(P2SH) transactions
(2) Witness scripts are not stateful or Turing-complete. Without persistence or a looping statement, some scripts expand in size/complexity while others are not possible to implement.
In Ethereum, the EVM is a Turing-complete state machine and has more powerful programming ability than Bitcoin. While the capabilities of a Turing-complete blockchain may present more security issues, Turing-completeness does not directly relate to the account model. We can also, for example, implement a Turing-complete UTXO-based blockchain or a Non-Turing complete account model-based blockchain.
Account model-based blockchains like Ethereum utilize complex calculations, and smart contracts in the account model can exist as independent entities outside of anyone’s control. We find the account model’s ability to utilize smart contracts with the persistent state to increase the capabilities of the blockchain.
2. Addressing transaction replay in the Account model
Ethereum adds a ‘nonce’ value in the Account and a nonce is included in every transaction. With each new transaction by the account, the nonce is incremented.
Though this method solves the replay problem, a sequential ordering problem is introduced by the solution, making it impossible for a user to create transactions in parallel. If the first of several transactions by a particular account fail and are not included in a block, subsequent transactions will fail as well.
Nervos AppChain is an account model-based blockchain that applies a similar strategy, with one important difference, the utilization of a random nonce. This approach removes sequential order on transaction creation, improves parallelism and makes serial failures less likely.
3. Storage
In the UTXO model, the state is only saved in transactions, while in the Account model state is saved on the nodes.
Ethereum uses a Merkle Patricia Tree (MPT) to store data and consensus is required on a block’s StateRoot value (the hash of the root node of the state trie). Consequently, messages passed in the network protocol are smaller and the required network transmission amount is less.
To further demonstrate differences in storage requirements:
In the UTXO model, suppose Alice creates a bitcoin transaction utilizing two inputs to transfer an amount to Bob and refund herself an amount (creating two outputs). This transfer requires two input witness scripts and two output locking scripts.
In the Account model, this same transaction would require only an amount and one signature from Alice.
After the implementation of Segwit, the amount of data transmission required for Bitcoin consensus decreases greatly, however full nodes still require witness script specific transmission and verification to prove block validity.
Conclusion
In the UTXO model, transaction calculation is done off-chain by clients and transactions link to existing UTXO’s. In this model, every transaction includes proofs to spend existing UTXOs and parallel computation is made possible. Because the concept of ‘account’ does not exist in this model, one-time address use is encouraged, strengthening privacy.
In contrast, the account model provides in-protocol account balances and persistent scripting, providing superior programmability and enabling new applications to be built on-chain in a way that would not be possible in the UTXO model. The account model also allows for efficient processing of bulk transactions, requiring only a signed message proposing an event to the state machine. With this construction, a large number of transactions can be propagated through the network with a much less input/output data transmission that would be needed for UTXO transactions.
The advantages of each approach are clear. The choice of UTXO vs. Account model for a base protocol or blockchain application can be made based on the qualities described and what is best for a given business scenario.
References:
[1]：Thoughts on UTXOs by Vitalik Buterin
[2]：What are the pros and cons of Ethereum balances vs. UTXOs?
[3]：Mastering Bitcoin 2nd Edition — Programming the Open Blockchain
[6]：Why is EVM-on-Plasma hard?
Thanks for input from Jan Xie and Matt Quinn from Starfish Mission.