The Occam.fi Technical Series: On Concurrency

Published in

Occam.fi

8 min readJul 1, 2021

Concurrency can be visualised as multiple participants accessing a single service at the same time.

This post is first in a series of many concerning some of the issues and problems that we in the Cardano ecosystem are solving as we approach the rollout of the Alonzo hard fork — scheduled to arrive in September 2021.

This post will give a detailed overview of the problem of concurrency — multiple computations happening at the same time. We will approach it first from the angle of Ethereum, then find how that translates to where we are at now in the Cardano ecosystem. Finally, we will explore some early foundations for potential solutions and where we might be headed in the future. We’ll begin with an introduction to concurrency in the realm of Computer Science.

What is Concurrency?

We will start with a high-level overview of Concurrency, which traces its roots to the field of computer science and can best be described as: ‘[the] ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or at the same time simultaneously partial order, without affecting the final outcome.’ [1].

In the world of cryptocurrency we can best understand concurrency, especially when it comes to smart-contracts (SCs), as the ability for multiple different agents to interact with the same SC at the same time.

Figure 1: A simplified view of Concurrency vs. Parallelism

A specific example would be a standard decentralized exchange (DEX) swap contract with Bob and Alice trying to exchange two of their tokens. Concurrency is Bob and Alice being able to access the exact same contract at the same time and swap their tokens. As shown in figure 1 above, we could imagine Alice and Bob are in separate queues at the same vending machine exchanging their tokens for another token at the same time at the same swap contract. This is concurrency at face value, but in further sections we will go into more detail about why there is more below the surface.

Ethereum’s Model

Ethereum was one of the first major account based cryptocurrencies to be created within the space, taking a markedly different approach to Bitcoin’s unspent transaction output (UTXO) model. Within Ethereum’s account model, the world state of the blockchain is not stored in the blocks that get mined. Rather, it is stored on nodes locally, which then reach agreement by comparing ‘StateRoot’ — or the overall state of the system [2].

Ethereum’s virtual machine (EVM) interprets transactions as events and determines the state transition result of these events based on the prior state. This makes developer abstraction much easier and facilitates the building of many DApps like Uniswap, AAVE, Curve and more since Ethereum’s inception.

Figure 2: A view of the account-based transaction

An easy way to think of Ethereum’s model is to understand an agent’s account as a pitcher from $0 to $∞ and by adding money to the account, you are simply pouring more money into the pitcher, thereby raising its value. By transacting and paying gas fees, you empty the pitcher along the way for both the transaction cost as well as the gas fees. The value of the fluid in the pitcher is liquid — easily form fitting to a transaction and easily adjusting to new account-inflows.

Can Ethereum Transactions be Concurrent?

We mentioned initially that the idea of concurrency, when it comes to the realm of smart contracts, is the ability for a SC to process multiple different agents’ transactions all at once. Ethereum is able to do this but it does have a caveat. The SCs themselves are concurrent, yes, but the actual transaction ordering is still sequential and not concurrent.

What this means is that while Alice, Bob, and Eve may all be accessing a DEX SC to swap token pairs, their individual transactions will still be ordered sequentially by the miner as they pack all of these transactions into blocks. Those blocks then get appended to the Ethereum blockchain and are then later re-executed by validators to ensure that the transactions are actually correct.

While the Ethereum SCs may be concurrent, the actual transaction ordering and approval processes are not — as that would introduce a whole host of state issues brought on by transactions. Say if a miner received a collection of transactions and began processing all of them at the same time. They would immediately run into an error if one of the transactions relied on funds that had been sent or received through another previous transaction. There have been tests to try and make transaction processing concurrent and they have been found to increase overall processing speed but nonetheless they still encounter ‘conflicting’ transactions, and must reorder them and re-process them [3].

Cardano’s Model

Cardano’s model returns to the roots of industry with its’ creation of the extended UTXO model (eUTXO). Bitcoin also runs off of the UTXO model and the best way to understand that is to think of transactions with Bitcoin as one would with cash. With cash, say you have a $10.00 note, and you want to purchase a candy bar for $2.00. You have your original UTXO of $10.00 and you send it to the cashier and pay the $2.00, the cashier receives two $1.00 UTXOs and you receive, as change, a $5.00 and three $1.00 UTXOs. Collectively the cashier has $2.00 and you have $8.00, but individually you have multiple different UTXOs that when added together form your ‘account balance’. Your original $10.00 note has been ‘consumed’ and in its stead you now have a collection of ones, fives, and a candy bar, and the cashier a collection of ones and one less candy bar.

This is the best way to think of the UTXO model realized by Bitcoin, and now with Cardano we have the eUTXO which is essentially a UTXO but with two added features — the ability to maintain contract state and the ability to enforce that the same contract code is used along the entire sequence of transactions. The eUTXO adds custom data and values to the transactions, which allows for arbitrary logic to interact with these transactions and opens the door to smart contracts [4].

Plutus Smart Contracts

With our new understanding of concurrency, Ethereum’s model and concurrency in terms of it’s SCs, and Cardano’s eUTXO model, we can finally begin exploring our main topic — Cardano’s SCs. Smart contracts on Cardano are stored in the form of UTXOs, where agents must interact with the UTXO, which contains the SC logic script to perform whatever action the agent intends to happen.

With the rollout of Plutus, Cardano’s coding language to compete with Ethereum’s Solidity for SC writing, Cardano is finally able to enter the SC space and begin building many of the DApps that exist on other blockchains; while at the same time allowing developers to improve and reiterate on them.

Can Cardano Transactions be Concurrent?

This now brings us to the current issue creating some cause for concern among many Plutus developers, the ‘Contract-Concurrency’ issue. This concurrency is different from Ethereum’s concurrency as currently with Plutus there is no global state or ‘Cardano Virtual Machine’ which all Plutus SCs might be connected to. With Ethereum as we mentioned, many different agents are all able to access a Ethereum based SC because of the shared global-state, but with Cardano’s UTXO model that isn’t the case. With Cardano, SCs themselves are components of the UTXO, and essentially act like conditions which govern how the UTXO will be utilized. Once the criteria for the SC script is met the UTXO is fulfilled and ‘consumed’ [5].

Where developers are currently running into a problem is with only one agent being allowed to consume the UTXO and thus the SC at a time, creating this so-called “Concurrency” issue. If we put this in the context of a DEX; Alice, Bob, Eve, Steve and Joe are all trying to swap their ADA for another token, and they all submit their transaction within a given block, only the first agent will have their transaction approved because at the moment the UTXO can be consumed only once per block. At that point it becomes a guessing game for the agent as they will never know until after the block has been processed if their transaction has gone through or not.

This differs radically from Ethereum’s model where one is simply interacting with the logic of the SC and is able to simply pass off the state change to the miners for validation. Cardano’s approach to the ‘Smart Contract Weapons Race’ brings many benefits for ‘future-proofing’ the network but this issue of SC consumption is the immediate problem facing many developers right now. How are developers for projects like DEXs, loaning and liquidity protocols supposed to create projects when their SCs that are going to power their entire system can not handle concurrent transactions and aren’t able to support multiple tens if not thousands of agents trying to interact with the system at a given time.

Lastly, the whole concept of liquidity providing is put into question because in the Ethereum system delegating your LP tokens is rather simple because the entire system is rather fluid. When we try to migrate that idea to Cardano and the eUTXO model we must find a way to translate something like a liquidity pool to the realm of unspent transaction outputs.

Looking to the Future

The problem has been addressed by Lars Brunjes himself in a twitter thread pictured below, many other people within the Cardano ecosystem have recognized the problem and are currently racing towards a solution to the problem of concurrency.

We also have Sundaeswap.finance, whose team have also addressed the exact same problem in their whitepaper. The team wrote: “Because any given eUTXO can only be spent once, as part of one transaction, it appears as if only one swap can happen per block. On the Cardano blockchain, there is roughly one block every 20 seconds. This would be abysmal throughput for a decentralized exchange.” [6].

Lars has stated that IOHK’s engineers are already thinking of ‘concurrent state machines’ for Plutus and how to incorporate that into the code; he has also floated the idea of parallelization as pictured above.

We at Occam.fi, like many other Cardano projects, are working towards a solution to this problem and testing different theories and workarounds. We are committed to helping to solve this issue and demo a working product featuring the solution. With the month of June coming to a close and the Alonzo hard fork scheduled for September, developers only have so many days to put together a solution to this issue of SC consumption concurrency, but the team that is able to solve this will certainly have the leg up for the months to come.