Concurrency

Greetings Riders! Welcome to another of our tech focused articles — It’s great to be moving ever closer to the MainNet launch, we are really thankful for your support!

Today’s blog post is around the topic of Concurrency — What is it, why does it matter, and how does it impact DEX performance. We initially covered this in our recent Litepaper — Here’s what we said there — We’ll expand and explain with a few examples.

Concurrency

Concurrency is an interesting topic, hotly discussed in Cardano circles. There are two different understandings regarding this and we’ll outline them here. To many in the community, it has to do with how many interactions are possible with a single Liquidity Pool (LP) by different users in one block (the answer is one per LP without a concurrency solution). To understand what is meant by a single user being able to interact with a single LP once per block, think about this -

“Aaron is doing a transaction on a DEX platform, he wishes to swap x ADA with y SOL by interacting directly with the ADA-SOL liquidity pool. Once he submits the swap transaction, it is not complete until the block is settled. The balance of both x ADA and y SOL will be different post the transaction. E.g. Until the transaction is settled, the balance of that LP is not verified. If other users tried creating their own swap transactions, they will conflict with Aaron’s transaction and the blockchain will reject them. However, it is possible to spread multiple transactions across multiple LP’s in a single block.”

More importantly, the varied balance of ADA and SOL in the above example may impact the price of subsequent transactions. The solution WingRiders chose for this is the “batching model” described below.

From a development perspective, the concurrency is more to do with servicing multiple liquidity pools in parallel. Cardano already supports this type of concurrency out of the box. With the “batching model” the concurrency solution becomes more interesting, since the agents have to balance prioritization of liquidity pools, blockchain congestion and batch sizes. When we at Wingriders talk about concurrency, as we are very much developer led, we lean toward the latter meaning.

The “Batching Model”

Users would create swap requests and Agents (the “batchers”) would fulfill these requests on behalf of the users. The requests are small transactions, while the transactions that fulfill these requests would interact with the DEX scripts (smart contracts) to ensure that the users are correctly compensated. These batch transactions are large because of the included scripts and large number of inputs. The agent’s goal is to maximize efficiency and include as many swap requests as possible. The more requests the agent can fulfill in a single transaction, the less load on the blockchain, lower overall fees and faster perceived user experience. How many requests can be included also depends on the transaction size, memory and cpu usage of the smart contracts. This is where the internal factors of the DEX’s architecture, concurrency solution and tradeoffs become evident.

Well — that seems totally understandable right? Job Done.

Let’s expand on this to clarify.

Imagine there are 300 orders waiting to be executed on WingRiders DEX. They break down into 5 different types. In no way do the example tokens represent tokens listed at launch, but we do keep an eye out for good projects:)

120 ADA/SOL

80 ADA/Token A (Let’s call this a gaming token for a blockchain based Chicken Game)

40 ADA/Token B (Let’s say this is a NFT collectible game)

35 ADA/Token C (Let’s say this is a crypto yield aggregator token)

25 ADA/ Token D (Let’s say this is a Digital ID token)

Based on our earlier blogpost around Speed we know that a block is every 20 seconds and can hold 72 Kb of transactions — How many transactions is that? We rated it at 800 transactions per minute for simple transactions. So, in a perfect world, we’d clear our 300 transactions in a little less than 30 seconds. In a perfect world. Based on what we are currently seeing in the Cardano world — This is not the case. Failed transactions, failed swaps, congestion, and other issues can arise. Why is this?

One of the reasons, as we discussed, smart contract transactions carry much more data and only 3–4 of them can realistically fit into the block with the current blockchain limits. The more larger transactions are included in a block, the less transactions can fit inside blocks overall, causing congestion.

If we consider the above excerpt from our Litepaper, it could also be because the DEX only has a limited number of Liquidity Pools (LP’s) or perhaps, more likely they have too many transactions for a single pool, the liquidity pool ADA/Token A (wouldn’t be the first time chickens broke a blockchain). If the DEX has a high number of requests against a single liquidity pool, the batches need to be sequenced between blocks. This is likely to cause congestion when interacting with a single liquidity pool and swap wait times will be very long.

This is what we are seeing in recent (non WingRiders) DEX related issues on Twitter

So — what can we see? How could we improve this?

Have more LP’s
Reduce transaction size — This doesn’t entirely solve the issue, but it allows more transactions per block which allows the DEX to move quicker overall.(Like not being a better driver but having a faster car)
Reduce smart-contract resource usage — the more optimal implementation for the smart contract, the more smart-contract transaction can appear inside the block.
Have more batchers/Agents.

Why number 4? Well, it’s not entirely obvious, but more Agents would cause a slight increase in stability and availability (more batchers would allow greater flexibility — speed would potentially improve minimally).

As 1 is beyond our ability to predict (you cannot predict the market with certainty), we’ll focus on 2–4.

Reducing transaction size and resource usage is a goal of every Development team working on a DEX, optimisation is critical, especially as volumes go up. It helps to have an experienced team very familiar with Haskell and the overall Cardano blockchain. WingRiders has this. It is a core focus of our dev team build from inception to testnet to mainnet. More details later.

More batchers/agents and more liquidity pools are usually a function of total users. A popular DEX attracts more users, which attracts more stakers, which means more liquidity pools, which means less problems. But more batchers is difficult. Traditionally DEX’s work with whales and other large holders (established staking pools, consortiums, Investment groups who hold many coins.) But what if a DEX built from the ground up to provide the opportunity for any user to be an Agent — At WingRiders we’ve already disclosed that our roadmap contains this. It’s a complicated engineering problem, but we understand it pretty well, and we already run in a browser (being lightweight) and therefore we have planned for this since our Proof of Concept in October. We strongly believe that this is not only not only helps us future proof our platform, but allows small holders and users to still participate in the ecosystem. Hence, we call ourselves THE DEX on Cardano — not because we are the best (that is subjective) but because we are open to all.

Keep coming back Riders, take off is coming 😎

Discord to discuss: https://discord.gg/wingriders