The blockchain is basically a distributed ledger, in which transactions are recorded.
Bitcoin and Ethereum host the two currently most valuable and popular cryptocurrencies. They use two quite different ledger models, known as the UTxO model and the Accounts model, respectively.
Cardano’s team of developers has evolved the UTxO model.
The UTxO model is the unspent balance of a previous transaction, which can be spent in the future.
UTxO chains do not have accounts; instead, coins are stored as a list of UTxOs, and transactions are created by consuming existing UTxOs and producing new ones in their place.
The balance is the sum of UTxOs controlled by a wallet. UTxOs are similar to cash in that they use “change”, and are indivisible (UTxOs are used in full), i.e. if you have to pay $50 and you have a $100 bill (UTxO), you must hand it over in full and receive change in a $50 bill (new UTxO).
Ethereum chose the Accounts model explicitly to facilitate more expressive smart contracts. On the other hand, Bitcoin chose UTxO also for good reasons, including that its semantic model remains simple in a complex concurrent and distributed computing environment.
Ethereum is based on the global state of the blockchain, (Ethereum Virtual Machine, EVM), with a distinct transaction accounting model, the Accounts model.
The Accounts model resembles the way a bank works. Users have accounts that store their coin balance. It is possible to spend partial balances. The concept of “change” does not apply.
While Ethereum’s implementation is simpler, the complications inherent in global state management (EVM) result in greater possibility of failed transactions, or wasted resources, among other problems.
Cardano developed the extended UTXO (eUTxO) model, an evolution of the Bitcoin UTxO model that supports a substantially more expressive form of validation scripts, which enable the scheduling of your transactions.
Cardano bases its transactions in a local environment, with the eUTxO (extended Unspent Transaction Output) model with the ability to interact with smart contracts running on the blockchain.
Cardano’s model circumvents the problems of the Account Model, by allowing resource determinism and indivisible individual transactions by limiting the scope of smart contract transactions to their immediate local environment. However these advantages are not without cost, as transaction construction is an upfront burden, having to be included individually in every development run on Cardano. Unlike Ethereum it is a build that must be faced by each developer.
Transactions consume unspent outputs from previous transactions and produce new outputs that can be used as inputs for future transactions.
It generalizes the concept of ‘address’ using the lock and key analogy. Instead of restricting locks to public keys and keys to signatures, addresses in the eUTxO model can contain arbitrary logic in the form of scripts. For example, when a node validates a transaction, the node determines whether or not the transaction can use a given output as input. The transaction will look for the script provided by the address of the output and execute the script if the transaction can use the output as input.
The second difference between UTxO and eUTxO is that outputs can carry (almost) arbitrary data in addition to an address and a value. This makes the scripts much more powerful by allowing them to carry state information.
This model offers better scalability and privacy, as well as more simplified transaction logic, since each UTxO can only be consumed once and in aggregate, which makes transaction verification much simpler.
It also offers greater security, predictability of smart contract execution costs (no unpleasant surprises) and more powerful parallelization.
The success or failure of transaction validation depends only on the transaction itself and its inputs, and not on anything else on the blockchain. As a result, the validity of a transaction can be verified off-chain, before the transaction is sent to the blockchain. A transaction can still fail if some other transaction simultaneously consumes an input that the transaction expects, but if all inputs are still present, the transaction is guaranteed to succeed.
This contrasts with an account-based model (such as the one Ethereum uses), where a transaction can fail to execute the script halfway through. This can never happen in eUTxO.
The eUTxO model is more complex to program for developers, as they must code the integrity of the transaction model in development itself, prior to transaction validation on the network.
Document: The Extended UTxO Model