Original English link: https://medium.com/nervosnetwork/my-comparison-between-the-utxo-and-account-model-821eb46691b2
In the current blockchain world, there are two main ways of keeping records, the UTXO model (Unspent Transaction Output) and the Account model. Bitcoin uses the UTXO model, and Ethereum uses the Account model.
Bitcoin was originally designed as a peer-to-peer electronic cash system. In Bitcoin, each transaction consumes the UTXO generated by the previous transaction and then generates a new UTXO. The balance of an account is the set of all unspent UTXOs belonging to the address, and the global state of Bitcoin is the set of all currently unspent UTXOs. Ethereum intends to create a more general protocol that supports Turing-complete programming languages, on which users can write smart contracts and create various decentralized applications. Due to the shortcomings of the UTXO model in state preservation and programmability, Ethereum introduced the Account model.
Below we further expand on the advantages and disadvantages of the two models.
UTXO Model
In the UTXO model, transactions only represent changes in the UTXO set. The concepts of account and balance are higher abstractions on the UTXO set, and the concepts of account and balance only exist in the wallet.
advantage:
The calculation is off-chain, and the transaction itself is both the result and the proof. The node only needs to verify, and no additional calculation is required for the transaction, and there is no additional state storage. The calculation of the output UTXO of the transaction itself is completed in the wallet, so the calculation burden of the transaction is completely borne by the wallet, which reduces the burden on the chain to a certain extent.
Except for Coinbase transactions, the input of a transaction is always linked to a UTXO. Transactions cannot be replayed, and the order and dependencies of transactions are easy to verify, and whether the transaction has been consumed is also easy to prove.
The UTXO model is stateless and easier to process concurrently.
For P2SH type transactions, there is better privacy. The inputs in the transaction are unrelated to each other, and technologies such as CoinJoin can be used to increase privacy.
shortcoming:
It is impossible to implement some complex logics, and the programmability is poor. For complex logic or contracts that need to save state, it is difficult to implement, and the state space utilization rate is relatively low.
When the input is large, the witness script will also increase. The signature itself consumes more CPU and storage space.
Account Model
For the Account model, the Account model saves the world state. The state of the chain is generally agreed upon in the form of StateRoot and ReceiptRoot in the block. The transaction is just the event itself and does not contain the result. The consensus of the transaction and the consensus of the state can be isolated in nature.
advantage:
The contract is stored in the Account in the form of code, and the Account has its own state. This model has better programmability, is easier for developers to understand, and has a wider range of scenarios.
The cost of batch transactions is low. Imagine that a mining pool pays a handling fee to a miner. Because each Input and Out in UTXO requires a separate Witness script or Locking script, the transaction itself will be very large, and signature verification and transaction storage will consume valuable resources on the chain. The Account model can greatly reduce costs through contracts.
shortcoming:
There is no dependency between Account model transactions, and the replay problem needs to be solved.
For the implementation of Lightning Network/Raiden Network, Plasma, etc., user evidence requires a more complex Proof mechanism, and the state migration from the sub-chain to the main chain requires a more complex protocol.
UTXO VS Account
Let's do some analysis and comparison on the above advantages and disadvantages.
First, questions about calculation
UTXO transactions themselves do not have complex calculations for the blockchain. This simple statement is actually not completely accurate. There are two reasons. First, most of Bitcoin's transactions are P2SH, and the Witness script is not Turing complete, and there are no loop statements. For the Account model, such as Ethereum, since most of the calculations are on the chain and are Turing complete, the calculations are generally more complicated, and the security of the contract is likely to become a relatively large problem. Of course, whether it is Turing complete has no direct correlation with whether it is an account model. However, after the introduction of the account model, the contract can exist as an independent entity that is not controlled by anyone, which is of great significance.
Second, the issue of UTXO being more prone to concurrency
In the UTXO model, the world state is the collection of UTXOs. In order to verify transactions faster, nodes need to store the indexes of all UTXOs in memory, so UTXOs are very expensive. UTXOs that are not consumed for a long time will always occupy the node's memory. Therefore, for this model, in theory, users should be encouraged to reduce the production of UTXOs and consume more UTXOs. However, if UTXOs are to be used for parallel transactions, more UTXOs are required as inputs, and more UTXOs must be generated to ensure concurrency, which is essentially a dust attack on the network. And because transactions are constructed in the wallet, a more complex wallet design is required. In contrast, in the Account model, each account can be regarded as a separate state machine that does not affect each other, and accounts communicate through messages. So in theory, when a user initiates multiple transactions, when these transactions do not call the same Account, the transactions can be executed concurrently.
Third, regarding the transaction replay issue of the Account model
Ethereum uses a method of adding nonce to the Account. Each transaction corresponds to a nonce, and the nonce increases each time. Although this method is intended to solve the replay problem, it also introduces a sequential problem and makes it impossible to process transactions in parallel. For example, in Ethereum, if a user sends multiple transactions and the first transaction fails to be packaged, it will cause subsequent transactions to fail to be packaged. In CITA, we use a random nonce solution, so that there is no sequential dependency between users' transactions, which will not cause serial failures, and it is possible to process transactions in parallel.
Fourth, storage issues
Because in the UTXO model, the state can only be saved in the transaction. The state of the Account model is saved in the node, and is stored in Ethereum using MPT. Only consensus StateRoot is required in the Block. In this way, for on-chain data, the Account model is actually smaller, the amount of network transmission is smaller, and the state is saved locally in the node using MPT, which is more efficient in space usage. For example, if A transfers money to B, if there are 2 Inputs and 2 Outputs in UTXO, 2 Witness scripts and 2 Locking scripts are required; in the Account model, only one signature is required, and the transaction content only includes the amount. After the latest implementation of segregated witness, the amount of Bitcoin transaction data has also been greatly reduced, but in fact, the verification node and full node still need to transmit and verify the Witness script.
Fifth, for light nodes to obtain the status of a certain address, UTXO is more complicated
For example, in a wallet, it is necessary to request all UTXOs about a certain address from the full node. The full node can send some UTXOs. It is difficult for the wallet to verify whether the UTXO has been consumed, and it is difficult for the wallet to prove that the UTXO is a complete set rather than a partial set. For the Account model, it is much simpler. According to the address, the corresponding state in the State is found, and the State Proof of the current state can prove the authenticity of the contract data. Of course, for UTXO, the root of UTXO can also be verified in each block. This is related to the current Bitcoin implementation and is not a feature of UTXO.
in conclusion
In summary, the Account model has more advantages in terms of programmability and flexibility; in simple business and cross-chain, UTXO has its very unique and pioneering advantages. The choice of model should be based on specific business scenarios.
