The upcoming Alonzo hard fork will introduce eUTXO, extended unspent transaction output, capabilities to the Cardano ledger. The much-anticipated upgrade is scheduled for September 12th. A successful roll-out will pave the way for expressive smart contracts and a flourishing dApp ecosystem on the blockchain.
However, recent discussions on SNS platforms like Reddit have cast doubt on whether UTXO models are indeed up to the task. Detractors claim that the eUTXO ledger structure is too inflexible to support popular applications like Uniswap, where over 100,000 transactions occur daily, or over 15 transactions per block. On the other hand, Cardano developers assert that concurrency issues are only a stumbling block, and workarounds are entirely feasible.
Blockchain Ledgers and Secure Transactions
Blockchains are the computational structures underpinning Bitcoin and other cryptocurrencies. Simply put, they function similarly to a database: blockchains store information off-site in a manner that is easily accessible. Unlike databases, however, most blockchains rely on distributed computation, with countless computers upholding the system’s integrity.
Since Bitcoin and others account for vast sums of value, blockchain networks must operate in a tamper-proof manner. Networks must execute reliably, and fund double-spending must be prevented. Cryptographically-secured ledgers ensure this is the case.
Along these lines, Bitcoin relies on a UTXO (unspent transaction output) model of account. In his book Mastering Bitcoin, Andreas Antonopoulos explains the concept succinctly:
“The fundamental building block of a bitcoin transaction is a transaction output. Transaction outputs are indivisible chunks of bitcoin currency, recorded on the blockchain and recognized as valid by the entire network. Bitcoin full nodes track all available and spendable outputs, known as unspent transaction outputs, or UTXO.”
Overall, the transaction execution is the means by which the blockchain is securely updated. Outputs are analogous to physical currency. Users “hold” outputs of varying sizes—think a one-dollar bill, twenty-dollar bill, etc—they received from those who previously paid them. When users spend bitcoin, their UTXOs become the inputs into a subsequent transaction that pays the next party. Moreover, the transaction returns any “change” to the paying party—think buying a pack of gum with a twenty-dollar bill and receiving change.
EVM, Accounts, and State
While secure, the UTXO model has largely proven to be inflexible. Smart contracts were suggested to be possible on Bitcoin as early as 2010, but to-date progress remains sparse (although the Taproot upgrade may change this).
The matter centers around global state. In Bitcoin, transaction validity is assessed at the transaction level—are the necessary outputs available?—thereby foregoing the notion of a shared mutable state across the blockchain. Practically, this implies difficulties conveying the state of a smart contract that may execute over a series of underlying ledger transactions. As such, contract continuity may be challenging to guarantee.
Ethereum addresses this issue via an account-based system and the notion of a global state. In the protocol, accounts are managed by the Ethereum Virtual Machine (EVM). This quasi-Turing-complete state machine can express detailed statefulness while allowing smart contracts to leverage complex logic.
However, blockchains are computationally intense networks that rely on incentivizing outside parties to maintain network integrity. This computation is expensive, and as such, protocols must ration the computational power needed to execute transactions.
For Ethereum, issues arise in the interplay of a global state and computation fees, so-called gas fees. In short, gas prices fluctuate depending on network demand and resource availability. Since countless players and smart contracts interact with the network, influencing the global state, fees can vary wildly from moment to moment.
In practice, this means gas fees can spike after a transaction is submitted but before it is approved. Such a transaction may not execute, resulting in cancellation and wasted gas payments accrued by users. Other issues also arise from the duplicitous ordering of transactions by network maintainers (miners).
Understanding Cardano’s Ledger
Cardano seeks a middle ground between the reliability and simplicity of Bitcoin and the expressiveness of Ethereum. In so doing, developers have championed an eUTXO model. eUTXO ledgers are relatively simple but capable of maintaining state while enforcing the same contract code across a series of transactions. The solution also foregoes a complicated global state supported by a virtual computation engine like Ethereum’s EVM.
As the name implies, eUTXO builds upon the Bitcoin model by including additional data, the so-called datum, within transactions. In combination with validation logic, the datum maintains arbitrary contract-specific data allowing for transitions of the blockchain transaction state—e.g. appending new transactions that adhere to the constraints of smart contracts.
In the eUTXO model, transaction context information is also passed to the validation logic. This enables contract continuity while ensuring that transactions are deterministic. Unlike Ethereum, transaction fees are understood upfront, and fee benchmarking is more straightforward. Moreover, transactions cannot be nefariously reordered for the benefit of miners.
Overall, Cardano’s eUTXO mimics a Mealy machine, a state machine that produces data as it transitions between states. The emitted information then defines acceptable transactions—i.e. the transactions that the smart contract will permit in its current state. Valid transactions effectively move the contract forward from valid state to valid state.
The Concurrency Debate
Yet, is this localized version of state enough? A recent flurry of social media posts by Cardano critics suggested that eUTXO ledgers lack the expressiveness necessary for smart contracts. This is a disaster scenario for high-transaction-throughput applications like decentralized exchanges (DEXs). These concerns seem related to a previously mentioned limitation:
Sure enough, the episode has forced the issue of concurrency front and center. Concurrency is the process by which portions of a program are executed out-of-order or in partial order, drastically improving execution time in multi-processor systems.
SundaeSwap, a decentralized exchange building on-top of Cardano alongside partner Liqwid Finance, recently published a Medium post responding to concerns. The piece paraphrased the misconceptions prevalent in recent posts:
“Many critics are using recent discussions surrounding the design decisions of Cardano to misrepresent the problem and ultimately underestimate the potential of one of the giants of the crypto industry. Misconceptions are now floating around suggesting that Cardano only supports one transaction per block, only one user can interact with a smart contract at a time, and that Cardano is ultimately destined for centralization.”
Essentially, the misunderstanding stems from the suggestion that smart contracts manage UTXOs, and only one actor can manipulate a given UTXO at a given time. Following this logic, how can a DEX, for example, possibly handle a spike in transaction volume during a sudden market downturn?
According to SundaeSwap Labs, this criticism belies the fact that smart contracts on Cardano can manage several UTXOs, effectively creating a greater surface area for user interactions than some would suggest.
Moreover, workarounds involving sharing state seem possible:
“There appear to be two categories of solutions to this problem: either design your protocol to tolerate segmentation of your state or aggregate interactions with that state.”
SundaeSwap’s post continues suggesting its developers are viability testing a potential solution they will announce soon.
All things considered, recent controversies may likely be opportunistic in their undertaking. New technologies, by definition, involve design challenges and trade-offs. Cardano is no exception, and developers working on the protocol remain optimistic that solutions are indeed possible.
Amazing article !! Congratulations, Luke!