The basis of any financial system is the asset management method. It is impossible to work with assets without a clear understanding of available balance. Double-entry bookkeeping, as applied in classic accounting, or triple-entry bookkeeping, favored in decentralized systems accounting, would not be applicable to blockchain platforms, if platforms did not allow tracking the user balance.
Currently, two popular balance models are: Unspent Transaction Output (UTXO) and the Account Model. The first model is a directed graph of assets moving between users, the second is a database with the current network state.
UTXO vs Account Model
A key advantage of the first model is the uniqueness of every coin, while the second model provides a simpler smart contracts implementation. As both aspects are important for a modern system, it is not reasonable to choose one model above the other. This is confirmed by solutions applied for popular products. Tab. 1 presents the models used by the most popular blockchains.
Popular Blockchain Design Comparison
| | Balance Model | Consensus | Smart Contracts |
| Bitcoin | UTXO | PoW | - |
| Ethereum | Account | PoW/PoS | + |
| EOS | Account | DPoS | + |
| Tron | UTXO+Account | DPoS | + |
| Qtum | UTXO+AAL | PoS | + |
| ICON | Account+? | LFT (BFT) | + |
Tab. 1. Popular Blockchain Design Comparison
It should be noted, that nearly all new systems have a hybrid balance model, while Ethereum and EOS use a pure account model.
Pros and Cons of UTXO and Account Models
- Higher degree of privacy for new addresses, the coin does not have an owner
- More easily scaled through sharding
- Hard to work with smart contract states
- Allows using multi-threading for computations
- Complete transparency of asset movements
- Need to store all accounts states
- More efficient storage usage
- Intuitively clear approach
- Light clients can analyze the states more easily
- High degree of fungibility; harder to track assets
- To prevent the state machine from storing nonce, unused addresses are deleted
- Inconvenient tracking of internal transactions in a public blockchain
- Every transaction must have a nonce
- Higher degree of privacy. If user utilizes a new address for each transaction they receive, it will often be difficult to link accounts to each other. This greatly affects currencies, and less the arbitrary DApps, as the latter are often required to keep track of complex bundled state of users. Therefore, user state partitioning scheme is not as straightforward as with currencies.
- Feasible scalability paradigms. In theory, UTXOs are more compatible with certain kinds of scalability paradigms, as it’s possible for only the owner of some coins can maintain a Merkle proof of ownership. This means that even if everyone (including the owner) decides to discard this data, then only the owner himself is at harm. In an Account paradigm, losing the portion of a Merkle tree corresponding to an account would make it impossible to process messages that refer to that account, including even incoming transactions. However, there are other non-UTXO-dependent scalability paradigms.
Account paradigm pros
- Large storage economy. For example, if an account has 5 UTXO, then switching from a UTXO model to an Account model would reduce the space requirements from (20 + 32 + 8) * 5 = 300 bytes (20 for the address, 32 for the txid and 8 for the value) to 20 + 8 + 2 = 30 bytes (20 for the address, 8 for the value, 2 for a nonce (see below)). In reality, savings are nowhere near this massive since accounts need to be stored in a Patricia tree (see below), but they are remarkable nonetheless. Additionally, transactions can be smaller (e.g. 100 bytes in Ethereum vs. 200–250 bytes in Bitcoin) because every transaction requires to make only a single reference, signature and to produce just one output.
- Greater fungibility. Since there is no blockchain-level concept of the source of a specific set of coins, it becomes less practical, both technically and legally, to institute a redlist/blacklisting scheme and to draw a distinction between coins based on where they come from.
- Simplicity. Account model is easier to code and comprehend, especially given more complex scripts are being used. Although it is possible to shoehorn arbitrary decentralized applications into a UTXO paradigm, via two following concepts. First being providing the scripts an ability to restrict what kind of UTXO a given UTXO can be transferred to. And second, also requiring the spends to include Merkle tree proofs of change-of-application-state-root that scripts evaluate. However, this makes such a paradigm much more complicated and ugly compared to simply using the accounts.
- Constant light client reference. Light clients can at any point access all data related to an account by traversing the state tree in a specific direction. In a UTXO paradigm, the references change with each transaction, which is a particularly burdensome issue for long-running DApps that try to use the above mentioned state-root-in-UTXO propagation mechanism.
Account paradigm cons
One weakness of the account paradigm is that in order to prevent replay attacks, every transaction must have a “nonce”. The account keeps track of nonces used and only accepts a transaction if its nonce is sequential to the last nonce used. This means that even no-longer-used accounts can never be pruned from the account state. A simple solution to this problem is to require transactions to contain a block number, making them un-replayable after some period of time, and reset nonces periodically. Miners or other users will need to “ping” the unused accounts in order to remove them from the state, as it would be too expensive otherwise with a full sweep as part of the blockchain protocol itself.
It is observed that both models are roughly identical. Each one has its clear pros and cons. This is once again proved by the community opinion demonstrating even preference to both types. However, a popular trend nowadays is to use a hybrid paradigm. It is reasonable to consider a hybrid model with UTXO being used for balances and States for contracts. We also suggest learning the AVL+ tree from Improving Authenticated Dynamic Dictionaries, with Applications to Cryptocurrencies [https://eprint.iacr.org/2016/994.pdf] in regards to using the optimized model of proof.
HashEx website: https://hashex.org
Connect with me via LinkedIn https://www.linkedin.com/in/dmitrymishunin/