Some blockchains, such as Ethereum, use an account model to represent the quantities of an asset held by each party, and transactions between them. This is an alternative to the UTXO model described in an earlier post. The idea is straightforward. At any time, we have a set of accounts, each with a unique identifier and an associated quantity of the asset. A transaction consists of, at least, the following:
- From: The account to be debited.
- To: The account to be credited.
- Value: The size of the transfer.
- Fee: A fee for processing the transaction.
Figure 1 gives an example where Alice is paying Bob 30 units, with a transaction fee of 2 units.
Processing the transaction consists of adding the transaction value to the ‘To’ account and subtracting the transaction value and the fee from the ‘From’ account, to obtain the new state. Since the value of an account cannot drop below zero, we must have,
| Transaction Value + Transaction Fee ≤ From Account Value. |
There are some additional fields that are required in order to be able to validate a transaction, although they do not have any effect on the state of the accounts.
- Signature: Only Alice should be able to spend the contents of her account which, as with the UTXO model, is done using public key cryptography. Each account should have an associated public key. Alice can sign the transactions from her account using the private key and, then, validation requires using the public key to verify that the signature is valid. In Ethereum, the account name is just a hash of the public key.
- Nonce: Figure 1 above shows a transaction from Alice to Bob of 30 units, with a fee of 2 units. What happens if she wants to repeat this payment? She could try submitting the exact same transaction again. However, this cannot be accepted by the network. If it was possible for the same transaction to be applied more than once, then anyone could just take Alice’s original transaction and re-submit it as many times as they like, until her account has been drained. This can be avoided by including a nonce field (‘number used only once’) in the transaction. Then, Alice can submit a new transaction with the same value and fee, but with a different nonce. In Ethereum, the nonce is required to start at 0 for the first transaction from an account, and increase by 1 for each subsequent one, so is always equal to the total number of previous transactions from that account.
This is all that is really needed for transactions in the account model. Depending on the particular blockchain in question, states and transactions can contain additional information such as code and data to execute smart contracts, but this is not the subject of the current post. The miner creating a block will be paid a block reward plus the sum of all fees from transactions in that block. Unlike with Bitcoin, which uses the UTXO model, with the account model there is no need to create a transaction paying the miner. Instead, the total reward can simply be added to an account specified by the miner.
The transaction model is rather different from the UTXO model used by Bitcoin, but they both achieve the same goal of representing transactions of amounts of an asset between parties. So, why would you choose one method over the other? They do both have their individual benefits and drawbacks, so the best choice can depend on how the blockchain is expected to be used.
The account model corresponds more closely to how we might intuitively think of ownership a currency, where each party owns a particular quantity and can transfer amounts of this to anyone else. The UTXO model corresponds more closely to the idea of coins which can be individually transferred from one person to another, with unspent transaction outputs taking the place of the coins.
As transactions in the accounts model are simpler, they tend to be smaller than with UTXO. If we want to auto-generate payments, or generate multiple payments from or to the same accounts, then this is easier in the account model. We can transfer arbitrary quantities between accounts, which only affects the quantities that they hold, not the account identifiers themselves. With the UTXO model, each transaction destroys the transaction outputs that it takes in and creates entirely new outputs. Any method of generating multiple transactions would need to handle the fact that the transaction inputs and outputs will be different each time, combine utxos using multiple inputs where necessary, and generate additional outputs for change where the inputs do not exactly sum to the required amount. Blockchains such as Ethereum natively supporting smart contracts tend to use the account model.
On the other hand, the UTXO model is simpler to validate. Partial spending of utxos is not allowed, so every transaction input completely absorbs the corresponding output. We therefore do not need to keep a running tally of the quantities in each account. The UTXO model does have a further benefit. As every transaction output is a distinct utxo, this makes it easier to have custom locking scripts and different private keys for each payment, increasing security.
Zero Knowledge 