The word blockchain carries a lot of weight today, whether it be on Twitter with influencer shilling or the media calling for regulation. Despite the hype being seemingly everywhere it can be difficult to truly grasp the mechanisms that underpin this technological revolution. This article provides a detailed breakdown of the various approaches blockchains use to manage transactions, ownership, and the state of assets.

“We have elected to put our money and faith in a mathematical framwork that is free of politics and human error.” — Tyler Winklevoss

“Blockchain” was first coined in the Bitcoin whitepaper in 2009, published by Satoshi Nakamoto. Nakamoto proposed the use of cryptographic mechanisms to undeniably verify the authenticity of data distributed throughout a decentralized peer-to-peer (p2p) network.

The nature of this model allows for the transfer of digital currency and assets, without the need for centralized trusted authorities. We refer to this type of network as trustless, since it doesn’t require a centralized trusted authority (e.g banks) to facilitate transactions and asset storage.

Background

Blockchain Structure: Verified transactions are appended to the ledger in blocks, with the updated state being broadcast to the network. Blocks contain a creation timestamp, random nonce (number used once), transactions, root hash, hash pointer, and a hash of the data contained in the block.

Hashes, simply put, are deterministic cryptographic outputs from a mathematical function. Inputs will always calculate to the same unique hash value if put through the same hash function. Thereby hashes are a way to prove the authenticity of data.

Previous blocks are tethered using a hash pointer to the previous block hash. This pointer is included in the hash of all blocks ensuring data immutability, since any update in previous block data would alter its hash, invalidating the pointer and blockchain going forward.

Fig 1: Blockchain Structure

Transactions and Consensus: When users want to send money over the blockchain, they submit transactions to the network from their wallet, proving their spending authorization by providing a cryptographic signature. The network nodes each consult their copy of the distributed ledger, ensuring the transaction is valid in accordance with their records (e.g the user has enough funds). Nodes communicate the result of this individual process amongst their network peers. If enough validator nodes achieve the same binary conclusion (yes/no) the transaction is either approved or rejected.

Upon approval, all nodes update their individual copy of the blockchain to include the new transaction. This process, known as consensus, allows these networks to operate in a decentralized environment (provided the majority act honestly).

Fundamentally these transactions act as state transitions, where the blockchain evolves from one single state to another. In the following sections, we’ll examine the models for tracking these states.

UTXO Model

In the unspent-transaction-output (UTXO) model, introduced in Bitcoin, transactions generate unspent-outputs associated with the recipient’s address, representing the transferred asset. UTXOs are spendable, with the associated wallet tracking the sum of all unspent outputs assigned to the address.

To transfer funds each transaction must specify a previous unspent output (UTXO) that fulfills the monetary value as an input. If the transaction is successful, the input UTXO will be spent, and the newly approved transaction will produce a new unspent output, associated with the recipient's address. This model can be visualized through a directed acyclic graph, which traces the inputs/outputs (state transitions) of the blockchain.

Fig 2: Directed Acyclic Graph of Unspent Transaction Outputs

If the transaction only consumes a fraction of the input, the output of the transaction will assign the remaining funds back to the sender. These processes can be conceptualized as paying in cash, and getting change returned to you.

Advantages

Traceability: The input/output structure of assets allows UTXO-based blockchains to be traceable on a deeper level than other models. Furthermore, tokens are individually identifiable since each transaction acts as a compartmentalized state.

Parallelism: Since input states are clearly defined before being submitted to the network, validators can theoretically process non-conflicting transactions in parallel, increasing network throughput.

Client-side State Generation: The network can offload state generation client-side (state is generated before it reaches the validator node). This means validators can focus on assessing the validity of proposed states (transactions), instead of calculating the new state and validating it.

Limitations

Inexpressive: The functional input/output nature of the model makes incorporating logical expression (i.e smart contracts) a complex challenge. Since logical expression fundamentally requires the freedom to determine an output based on a variety of parameters, the deterministic input/output approach presents inherent challenges.

Computational Overheads: Verifying if the output is spent or unspent is computationally expensive. The algorithms used in calculating which UTXOs to use can become exponentially complex, especially when considering that outputs may be divisible to an infinitesimal amount. This increases the outputs required to maintain the volume of assets, increasing memory and storage overheads.

Transaction Size: Since the input, the state needs to be included in transactions, this can increase the size of a transaction.

Account Model

The account model, introduced in Ethereum, presents a conceptually simpler solution to managing the ledger state in comparison to UTXO. Each account (address) is used to track the sum total of transactions in/out, and store the resulting value as the user’s total balance. Instead of selecting individual input states (UTXOs) to fulfill a transaction, the transaction signifies an operation to be performed (upon validation) on the account balance object. For example: reduce the sender’s balance by X amount and increase the recipient's balance by X amount.

In Ethereum, the account model supports smart contracts (accounts controlled by code) and externally owned accounts (user accounts controlled by a private key). Both externally owned accounts (EOA) and contract accounts contain a public address, nonce, balance, storage hash, and code hash. These account types differ in that the code and storage in EOA’s are empty, and contract accounts do not use private keys because control is automated by the contract itself.

Fig 3: Account Types

When transactions are sent to a smart contract account, the code logic is executed (dependent on the parameters of the transaction), for this reason, we can essentially consider transactions to smart contract accounts in Ethereum to be function calls.

Advantages

Expressivity: Logical expression adapts intuitively to the account-base model with each transaction essentially equating to a function call, to execute some process. Furthermore, since the state is maintained on a per-address basis (as opposed to per transaction), it’s easier to design applications that operate on a balance object, as opposed to arbitrary inputs with binary flexibility.

Off-Chain Scalability: Smart contracts have unlocked a new dimension for scalability since operations can be shipped off-chain, to specialized frameworks (e.g sidechains, rollups) while the results are finalized on-chain.

Smaller Transactions: Transactions are generally smaller in size since the transaction represents instructions for the validators to generate the desired output state, as opposed to the transaction representing the input and output states themselves.

Computational Efficiency: The account model is more efficient in virtual memory usage than UTXO implementations. In account-based blockchains, fewer objects are maintained since the virtual machine only tracks balances, not all transaction outputs. This can reduce bootstrapping overheads when new nodes join the network, and calculate the current ledger state.

Limitations

Sequential Processing: Transactions must be validated sequentially by validators because their associated dependencies are unknown until they are validated. Unlike UTXO transactions where the only dependency is the input state, transactions on account-based blockchains could also depend on arbitrary on-chain data, the state of which is unknowable until validation.

Unforeseeable Implications: Transactions on account-based blockchains do not maintain the same atomic finality as UTXO transactions, in that: a transaction on, for example, Ethereum is saying “Follow these steps with my money” while a transaction in Bitcoin (UTXO), is saying “Validate this state transition”. The key difference here is: the transaction in Bitcoin has a binary conclusion of 1) valid (as the user intended) or 2) invalid; while the transaction on Ethereum could be 1) valid (as the user intended), 2) invalid, or 3) valid (with an unintended outcome).

Such unintended outcomes may be the result of an on-chain state dependency changing while the transaction is waiting in the mempool (transaction queue).

Extended-UTXO Model

Extended-UTXO is somewhat of an umbrella term for approaches related to applying smart contract functionality to the UTXO model or similar state models. Key examples of this are Cardano, Nervos and Ergo.

In the research paper introducing extended-UTXO, a smart contract-capable implementation of the traditional UTXO model was proposed for the Cardano platform. UTXO models utilize a mechanism of a lock and key, where public keys are the locks for transaction ownership while verifiable signatures serve as keys to unlock and spend associated outputs. With extended-UTXO, addresses may include logic that fulfills the same purpose as keys (signatures). Such logic specifies the conditions necessary for spending locked outputs.

Arbitrary data may be contained within transactions dictating the conditions under which the resulting UTXO is used, and how it operates when spent (we call this the datum). Contract logic outlines additional parameters applied at validation when the output is used.

When a transaction consumes the smart contract-dependent output, additional parameters are passed within the consuming transaction. Such parameters are conceptually similar to the arguments passed in transactions (function calls) on Ethereum; we call this the redeemer. Redeemers dictate the parameters the contract logic operates under and defines the executed validation logic.

Example: Imagine a scenario where assets are locked on a vesting schedule, and users can periodically unlock their assets after a period (specified in the datum) has elapsed. The redeemer arguments could be ‘claim’, signifying the user wishes to unlock their assets. This argument tells the contract what to do if the request is valid. In this case, the request is valid if a predefined period has elapsed since the assets were initially locked, and the user is authorized to unlock them.

Fig 4: Extended-UTXO Smart Contract Transaction

Since the dependencies (inputs, data, and logic) are predefined in this approach, the legitimacy of transactions may be checked off-chain. Therefore, if dependencies remain constant upon on-chain validation, transaction success is assured. Transactions might not always succeed due to state dependencies no longer being valid by the time validation occurs. Considering that transactions only depend on themselves and their inputs, they are shielded from external on-chain states that might cause unintended outcomes.

Advantages

Traceability: Naturally, extended-UTXO maintains the same level of traceability through the directed acyclic graph as traditional implementations.

Transaction Parallelism: Due to predefined state dependencies, transactions can be processed in parallel at the validator level.

Client-side State Generation: Client-side state generation can help offload and distribute computational overheads from the validator nodes. Furthermore, in the context of smart contracts, the results of off-chain logic can be determined before being committed on-chain, thereby mitigating unforeseen circumstances.

Expressivity: Smart contracts in extended-UTXO bring similar functionalities seen in the Ethereum ecosystem to a UTXO framework. Although contracts and dApp structure in this architecture is more functional, overly complex, and less developer friendly.

Scalability: Off-chain logic allows for additional scaling practices to be applied on the underlying blockchain. This in conjunction with the potential for layer one transaction parallelism could merge two powerful scaling mechanisms not available in other ecosystems.

Limitations

Complex: Extended-UTXO is overly complex in nature, especially to develop on. For this reason, the rate of adoption and growth in off-chain utility applications is subpar compared to ecosystems where the talent pool is broader. Furthermore, state explosion is a real issue where outputs become divisible to an infinitesimal amount, increasing computational overheads associated with node bootstrapping.

Larger Transaction Size: Since transactions not only represent independent states but also include contract parameters, transaction sizes are larger.

Lack of Research: Research is concentrated amongst a small group of projects spearheaded by Cardano. This lack of mass industrial awareness could result in missed potential.

Conclusion

We’ve reviewed three approaches to state management in the blockchain ecosystem. We’ve determined the semantic differences that allow projects different avenues of scaling, (e.g layer-two, off-chain scaling through smart contracts, and on-chain transaction bundling). In this analysis, we discovered that extended-UTXO may have the potential for an unrivaled distribution of scaling mechanisms since both off-chain methods and transaction parallelism are possible. Despite this, the model is overly complex and doesn’t have the same industry research as more developer-friendly solutions.