Blockchains are state machines - they track state (for example, how much BTC each wallet holds) and state changes across time. Every transaction (and therefore every block) alters the state of the blockchain. The two most popular ways of tracking and managing state in blockchains are the Unspent Transaction Output (UTxO) model and the account model. The UTxO model was pioneered by Bitcoin and can be intuitively thought of as cash-like (which will be elaborated further below) while the account model was popularized by Ethereum and can be intuitively thought of as bank-account-like. As with all engineering and design decisions the UTxO and account models have tradeoffs. For example, the account model enables more expressiveness than the UTxO model but has worse determinism properties (it’s more likely that transactions fail when the underlying blockchain uses an account model).
The team at IOHK, the science and research arm behind the Cardano project, have innovated a new state-management system they call the Extended UTxO model (eUTxO). The eUTxO model is the synthesis of the UTxO and account models, it combines the expressiveness of the account model with the privacy, safety, concurrency and determinism of UTxOs.
There are many articles comparing the UTxO model and the Account model but there are few articles that expand that comparison to the eUTxO model. This article will quickly cover the basics of the UTxO and Account models and attempt to thoroughly explain the eUTxO model.
Let’s start by building some intuition for the UTxO model that Bitcoin pioneered. Remember that UTxO stands for Unspent Transaction Output. Let’s start with an example that builds on the above mentioned intuition that the UTxO model is cash-like.
Suppose Alice has a $100 bill and she needs to pay Bob $3. Alice will give her $100 bill to Bob and Bob will return $97. In this example, Alice started with an Unspent Transaction Output (UTxO) with a value of $100. She then spent/consumed that output (the $100 bill) in a transaction which resulted in 2 new Unspent Transaction Outputs (UTxOs), one worth $3 (which is owned by Bob) and one worth $97 (which Alice owns). Notice now that the original $100 UTxO cannot be consumed/spent again.
Each UTxO can only be spent once and can generate one or more new UTxOs. Each transaction in the UTxO model takes a list of input UTxOs, consumes them, and creates a list of new UTxOs which can later be consumed/spent in new transactions. Another property of the UTxO worth noting is that the value of inputs for a transaction must always equal the value of outputs (minus any fees charged by the blockchain for processing the transaction).
The UTxO model has great concurrency properties because state is local (compared to the global state of the account model described below). This notion of local state derives from the fact that UTxOs are specific to each wallet. If Alice makes a transaction to Charlie, that cannot possibly affect the ability of Bob to transact since Alice cannot consume Bob’s UTxOs. This is not the case in the account model and will be elaborated in the next section. Because there cannot be any dependence between transactions made by Alice and Bob, their transactions can be parallelized more effectively.
There are arguments that the UTxO model has better privacy properties but I’m not yet convinced. It’s claimed that the UTxO model has better privacy because users can use a new wallet for each transaction and when receiving change for transactions they initiate (ie: $97 change Alice gets in an above example). While the Account model doesn’t have a notion of change, users can opt to create a new wallet for every transaction in the Account model as well. One benefit of the UTxO model when creating a new wallet for each transaction is that value distributed across many wallets can be far more easily consolidated than in the Account model. Consolidation in the UTxO model can be theoretically done in a single transaction because all of the UTxOs can be consumed at once to create a single output (however practical limitations of block size will limit this to, for example, a max of 6 UTxOs being consumed at once).
One downside of the UTxO model is the size of transactions. In the UTxO model, each transaction specifies a list of inputs and a list of outputs. This means that some transactions which have many inputs and outputs can become quite large. Transactions are smaller in the account model and this will be described in more detail below. Another big disadvantage is the conceptual difficulty of the model - most people have an easier time understanding and conceptualizing the account model than the UTxO model which means there’s more room for both user and developer error. The final problem with the UTxO model is that it has limited smart contracting capabilities. Bitcoin does have limited support for smart contracts like multisig, time-locked transactions and P2SH. However, the Bitcoin UTxO model does not support Turing-complete scripts.
In contrast to the UTxO model, the account model can be intuitively thought of as bank-account-like. Transactions in the account model specify debits and credits as opposed to consuming and creating UTxOs. Let’s again suppose Alice has $100 and wants to send Bob $3, though this time the money isn’t in cash form, it’s in a bank account. For Alice to send this money to Bob she requests her bank to debit her account $3 and credit Bob’s account $3. Notice how there’s no concept of change and how it’s the bank that manages these credits and debits.
We mentioned above how the UTxO model is less intuitive for most users, hopefully this example clarifies why that is. It is conceptually difficult to think in terms of Unspent Transaction Outputs but very easy to think in terms of credits and debits. We also mentioned how transactions in the UTxO model can become quite large when there are many inputs and outputs. Transactions in the account model are much simpler and smaller because each transaction specifies a simple credit/debit scheme - “send x ETH to Bob”.
In contrast to the UTxO model, the account model is far more expressive. The account model enables long lived contracts on the blockchain which can keep their own state for each account in the ecosystem. The UTxO model supports long lived contracts, but the primitives of the UTxO model do not allow for Turing-complete expressiveness. For example, Alice can write a smart contract on an account model blockchain which issues a token and acts as a bank tracking every wallet that holds the token and performing debits and credits when token holders transact with the token.
This idea that the smart contract acts a bank managing and mediating transactions significantly affects the concurrency properties of the account model. Since there’s a notion of a central mediator (the smart contract acting as a bank), it’s possible that a transaction Alice makes to Charlie affects Bob’s ability to transact.
As a contrived example, a smart contract may have a clause which prevents anyone from transacting if all account balances are less than 10. Suppose that Alice has a balance of 11 and Bob has a balance of 5. Also suppose that both Alice and Bob want to send 2 coins to Charlie. If Alice’s transaction is executed first, Bob’s transaction would fail because Alice would have a balance of 9, Bob a balance of 5 and Charlie a balance of 2 and this distribution would violate the “all balances must be 10 or more” condition of the smart contract. However, if Bob’s transaction executed first, it would succeed because Alice would have more than 10 coins. Bob’s successful first transaction would not affect Alice’s ability to transact because there will be still one person (Alice) with a balance greater than 10. This demonstrates how Alice’s transactions can affect Bob’s ability to transact (in contrast to the UTxO model) which means that transactions in the account model cannot be parallelized as effectively as the UTxO model. The order of transactions in an account model matter far more than in a UTxO model.
Another consequence of the account model is that it makes multitoken transactions more difficult than the eUTxO model (which we’ll elaborate on in the next section). If Alice has 10 AliceCoin and 10 BobCoin and wants to send 5 of each coin to Bob, she will typically do that with 2 separate transactions, one transaction to send 5 AliceCoin and another transaction to send 5 BobCoin. This happens because AliceCoin and BobCoin are both managed by independent smart contracts and both of them manage token balances independently of each other. Each contract must be independently contacted to perform the appropriate debits and credits, usually in two separate transactions.
However, it’s possible in the account model to write a third smart contract which, when executed, will make the correct requests to the AliceCoin and BobCoin smart contracts. Alice could theoretically interact with an AliceAndBobCoinWrapper contract which would perform the appropriate calls to the AliceCoin and BobCoin contracts but this paradigm has several drawbacks such as security (Alice has to give the AliceAndBobCoinWrapper contract permissions to interact with her tokens), fees (it might be the case that this wrapper contract is more expensive to use than issuing two independent transactions to the respective smart contract), determinism (it’s more likely that failures happen when contracts get more complex) and comprehensiveness (what if Alice has a third or fourth coin she wants to send?).