January 2, 2022
Concurrency and Cardano: A Problem, a Challenge, or Nothing to Worry About?
Ben Beddow
Co-Founder
Three months after the Alonzo hardfork, concurrency is a term many members of the Cardano ecosystem are getting their teeth into. From our recent Twitter poll on the topic, it seems that the vast majority of respondents know what concurrency is and are not concerned with its effect on transacting using Cardano dApps. There is, however, still a good percentage of respondents who say they either do not understand concurrency or are worried about its effects of transacting on Cardano.
So, as some of the most anticipated dApps to launch on Cardano roll out onto the testnet and begin to look at launch dates and celebrations we thought we’d answer, in basic terms, what concurrency is and why some might think of it as a problem and why others see it as a challenge. We’re also going to bring together all the concurrency solutions put forth by dApps building on Cardano. In this piece we’re going to answer:
- What is concurrency?
- Why does concurrency exist on Cardano?
- How does concurrency on Cardano affect me?
- What is each dApp's solution to concurrency?
What is Concurrency?
In the real world, concurrency is when two events or actions happen at the same time. In computing, concurrency is the ability to execute more than one program or task at the same time, or out of order without it affecting the outcome.
Why does concurrency exist on Cardano?
We’re going to dive into technicalities here but still try to keep it simple.
Smart contracts and the dApps that use them are typically thought of as compared to those on Ethereum -the blockchain on which they are most popular- which uses what is called an “account based” model for a blockchain.
The account based model gives each wallet a single address and relies on what is known as “global state”, which is where a record of the accounts (wallet addresses) and their balances are stored across a network of nodes; similar to how a centralized bank may keep a record of all the accounts and the funds stored in each.
This global state is updated with every block that is produced and the way the account based model, i.e. Ethereum, functions allows multiple users to transact with a single smart contract in a single block. This perfectly suits the swaps model of DEX that has become so popular over the past few years, hence why it arose on account based blockchains.
Cardano uses the eUTxO model, building on top of Bitcoin’s UTxO model. The Cardano model is called the “Extended Unspent Transaction Output” Model. In this model the sending and receiving of funds are not stored as a balance but as unspent transaction amounts (UTxOs) that are associated with a wallet’s addresses. These UTxOs can each only be spent once. An example explains this the best:
When you perform a transaction on Cardano you must spend the whole UTxO. So, if you have 50ADA in your wallet and you want to send 10ADA to your friend, your wallet creates a transaction that spends the whole 50ADA; sending 10ADA to your friend and sending 40ADA back to the wallet that it came from (yours). This is because the whole of the 50ADA UTxO can only be spent once. So you get 40ADA sent back to you, as a new UTxO, to spend again.
So, in the Cardano and Bitcoin model -UTxO- a wallet’s balance is made up of all the UTxOs associated with it. This is important here because, as explained, when you send funds in a UTxO based blockchain then you must spend the whole of a UTxO because a UTxO can only be spent once. The remaining funds are sent back to the originating wallet as a new UTxO to be spent again.
A smart contract on Cardano stores a UTxO and has certain conditions programmed into it which governing how the UTxO stored in that smart contract can be spent. Because a UTxO can only be spent once it means that only one person can interact with and use a smart contract per block (which is every 20 seconds on Cardano). Once a person has interacted with that UTxO in that smart contract, it is replaced with the updated UTxO for the next block. But this still means only 1 person can use a smart contract each block.
This becomes problematic when someone tries to utilize liquidity pools -the basis of a swap style DEX- on a UTxO based blockchain. A liquidity pool is a large pool of funds, deposited by numerous users, that are managed by a smart contract, and used to facilitate swaps by other users. This concept functions very well on an account based blockchain, i.e. Ethereum, where multiple users can interact with a smart contract during a single block. But if only one person can interact with a smart contract in every block, which is every 20 seconds on Cardano, then that creates a massive amount of congestion for the dApps trying to operate like this.
How does concurrency on Cardano affect me?
The concurrency issue on Cardano is created because each UTxO, and therefore smart contract associated with it, can only be used once. So each smart contract can only produce one transaction per block. Meaning that only one person can interact with a Cardano smart contract each block, meaning that interactions with many DeFi protocols that want to allow multiple users to interact with a smart contract at the same time (concurrently) will not be possible if implemented in their current format.
What will happen with, let’s say, an AMM style DEX on Cardano is that multiple users will try to interact with a smart contract and only 1 user’s transaction will be successful. The others will get notification that their transaction has failed and will have to keep trying until either their's is the successful transaction or they give up trying. Resulting in many frustrated users not being able to make the transactions that they wanted to.
But just because what works on one blockchain, Ethereum, doesn’t work on another, Cardano, it doesn’t mean that either is superior or inferior to the other. It shows that they’re both different. Which means that each must build their own path to each facet of their shared decentralized goal. Along those roads each will contend with their own issues; and some of those issues will be individual and some will be shared. Concurrency on Cardano is not a problem and more of a challenge associated with a UTxO base blockchain and should not be described as a limiting factor.
This is one of the factors that developers have to contend with when working with the Cardano protocol (and each protocol has its own limiting factors that need to be worked around to maintain a level of scalability, decentralization, and security, often described as the blockchain trilemma) and is not a new issue that they have to contend with; it has been known about for a long time.
As we’re about to see, the developers of protocols on the Cardano blockchain are facing up to the challenge of concurrency and forging new paths by designing innovative and creative solutions to this issue. Solutions that will allow users to use their protocols at the same speed as users on other blockchains.
What is each dApps solution to concurrency?
There is no one right answer to resolving concurrency on Cardano. However, it is expected that, over time, one or two solutions may become more favorable than others, by both protocols and their users.
Here we’re going to list and summarize the concurrency solutions that have so far been proposed by dApps building on Cardano, with links to the materials they have produced on the topic. The list below is for easy reference as to which protocols we’ve covered and will readily be updated as we hear back from the protocols we’ve reached out to.
Concurrency Solutions
- Cardax
- ErgoDEX
- Maladex
- Matrixswap
- MELD
- Minswap
- MuesliSwap
- Occam.fi
- SundaeSwap
- WingRiders
Cardax
Summary: An algorithm called “streaming merge” provides each user with an exclusive thread in which they can submit their action i.e. swap. These threads are split into time cycles and once a time cycle is over the algorithm then merges those actions into a single thread that respects their input time. This merged thread is then processed on-chain.
Source: Cardax blog piece and Youtube interview
ErgoDEX
Summary: Off-chain bots, run by third parties, collect the orders created by users. These are then sequenced and transmitted on-chain as a single order. These off-chain bots can be run by anyone who runs an Ergo node.
Source: ErgoDEX backend documentation and YouTube interview.
Maladex
Summary: Using what they call “programmable swaps” Maladex splits the process into a commit and an execution phase. A user sends a commit to the blockchain to perform a certain action, this is represented by an NFT that contains all of the triggers built into a transaction; having programmable triggers means that transactions can be programmed for multiple types of trade. The execution phase happens each block and all commits are evaluated and all those that are active are executed against each other using an order matching engine.
Source: Maladex Medium post.
Matrixswap
Summary: Matrixswap is based on a virtual AMM concept, vAMM, that allows trader access to virtual liquidity locked on-chain in a collateral vault, and the assets themselves are never actually traded. There is no need for the liquidity pools that traditional AMM exchanges use and thus the need for a concurrency solution is reduced to an effective zero.
Source: Matrixswap documentation.
MELD
Summary: In MELD’s on-chain solution the user of a swap produces a reserve UTxO with several defining data points. These reserve UTxOs are then batched using the attached data points which ensure that UTxOs cannot be omitted, rearranged or changed by the batcher. This batch of UTxOs is then executed as one against the pool UTxO.
Source: MELD Medium post.
Minswap
Summary: Minswap will use an automatic batching protocol to meet the challenge of concurrency. Orders created by users will be created as “batch requests” that are then picked up by third party batchers running the batcher bot script. This bot script then combines and executes all the transactions as one. The batcher bot script can be run by anyone running a full Cardano node.
Source: Minswap medium post.
Muesliswap
Summary: Muesliswap operates an order book style DEX. In an order book style DEX each order placed by a user creates its own UTxO stored in its own smart contract. This means that order book style DEXs, like Muesliswap, on Cardano don’t require a concurrency solution because it is not a challenge to the way their protocol is designed.
Occam.fi
Summary: Occam.fi uses off-chain aggregators to aggregate and execute transactions in a single transaction, using a slot based system to determine the order in which they were submitted and, therefore, the order in which they are pulled for execution.
Source: Occam.fi Medium article.
Sundae Swap
Summary: Sundae Swap uses an off-chain, 3rd party to aggregate transactions and execute them as a single transaction. These 3rd party aggregators, called “Scoopers” are given 30 day licenses and their behavior is policed by holding their rewards until their license has expired and the DAO has decided that their actions weren’t malicious. if they were they lose their rewards and the rewards are rerouted to the Sundae Swap treasury.
Source: Sundae Swap’s Medium post.
WingRiders
Summary: The WingRiders DEX uses “Agents”, a software run by individuals on their machine that order and batch swap request and liquidity operation requests. Anyone can run the Agents script, allowing this batching process to be decentralized, but, to begin with, “only a select number of closely monitored hosts are allowed to run the agent software". Data from these hosts will be used to evaluate this solution and to further improve it before deployment to the public.
Source: WingRider documentation and a blog post