Speed Demons, Block Size and other Deviations from the Norm in Blockchain dApp Performance
In this, our fourth post, we begin to drill down on the function of speed in how it relates to the performance of a DEX on any blockchain, and then on the Cardano blockchain specifically.
Let us start with transaction speed, as this is a frequently used benchmark.
Q: What does transaction speed mean and how does that relate to a DEX?
The perceived dApp speed is dependent on many factors, both internal and external. To get a handle on this, let’s break it down and put it back together. A dApp runs on a blockchain that has its own properties and features. A dApp wouldn’t exist in a vacuum and there could be many dApps running in parallel. To be able to provide users with a smooth UX experience, dApps also use heavy infrastructure in places that mirror the blockchain state or even run some business logic or processes. The infrastructure also introduces delays. These are all external factors.
Then there are internal factors:
Q: What is the design of the dApp? Did the dApp make the right tradeoffs? How well does the dApp handle concurrency? How well the developers optimized their solution to use minimum resources?
Let’s start with the blockchain properties to make a clear distinction between “transaction speed” and “swap speed” in a DEX.
Confirmed or verifiable transactions per second is a property of the blockchain. (It is slightly different from the actual transaction processing speed, which can potentially be much higher.) Swap speed is partly impacted by transaction speed, but it’s equally impacted by all the internal factors.
There are many parameters that may have an impact on confirmed transactions per second. As a disclaimer, some of the following limits are set conservatively on Cardano. IOHK already showed willingness to increase these with raising the block size and memory usage limit.
Currently a block is created roughly every 20 seconds. Each block can contain up to 72kB worth of transactions. The maximum transaction size limit is set at 16kB. Simple transactions can be as low as 0.25kB.
With some “back of the napkin” calculations, this means around 4 max-size transactions up to ~250 tiny transactions. This gives you roughly 0.2 to 14 transactions per second. To imagine it better, let’s convert that to roughly 12 — ~800 transactions per minute.
These numbers would be relevant if blocks were created every 20 seconds. On the mainnet this is usually the case, but on the public testnet the number of stake pools is lower, and the throughput is less consistent.
To narrow it down even more, currently, script sizes for more complex dApps are around 2kb — 12kb in size with AMM Co-DEXes being on the upper limit. These dApps contain more logic than simple interactions between two parties to handle multiple swap requests, ensure ordering, authorize all participants and even mint some tokens for providing liquidity. Some dApp transactions contain additional metadata or NFTs that take up even more space.
Let’s do some more “napkin math’’.
If all transactions would be scripts in a block, that would narrow the range down to around 12–72 transactions per minute for generic dApps, but realistically for larger scripts around 20 dApp transactions per minute. (Keep in mind that the rest of the space can be filled with smaller transactions, so the actual throughput of the blockchain could be much larger even in the presence of these applications.)
Disclaimer Time: These are slightly pessimistic approximations as smart contracts on cardano are very fresh and there still a lot of improvements that can be done both with optimizations and development on the smart-contract side. Efficiency is usually deterministically inversely related to “newness”.
Q: Now that we established that roughly 20 large dApp transactions per minute is possible for now, how does this relate to “swap speed”?
In our previous article we mentioned Co-DEXes and the “batching model”. Users would create swap requests and agents (the “batchers”) would fulfill these requests. The requests are small transactions, while the transactions that fulfill these requests would interact with the DEX scripts. 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 dApp design, concurrency solution and tradeoffs become evident. We’ve seen this before in the Cardano DEX ecosystem.
We did a short burst load-test on the public testnet to demonstrate the “swap speed” with our beta WingRiders DEX testnet contract.
We really kept it short to not hijack the whole public testnet :P. Between blocks 3215541–3215550
( https://testnet.cardanoscan.io/block/3215541 https://testnet.cardanoscan.io/block/3215550)
The agents fulfilled 175 requests.
Here is an example:
If the blocks were created every 20 seconds, this would correspond to around 55 requests fulfilled per minute. (Based on the timestamps the blocks are more sparse on the testnet and the actual throughput was 33 requests). All this with other dApps being present at the time as well. A purely synthetic test fully utilizing the blocks would yield even higher numbers! To put it into perspective, according to more recent transaction numbers Uniswap v3 are closer to 20 - 40 operations per minute. (Uniswap v2 claimed as high as 70 transactions per minute in August 2020.)
Additional disclaimer, these numbers are not representative of the actual numbers that will be achievable on the mainnet. We are continuously tightening the security of our contracts and adding more features requested by the community!
Let’s put it all back together with a swap flow and evaluate the perceived speed of the swaps on Cardano.
Typical Process Flow
- When you go to NuFi and create a swap request, the transaction needs to be submitted.
- Once submitted it takes 5–30 seconds for that transaction to be confirmed and for it to appear on the blockchain.
- Some wallets would hide this wait time, but NuFi is very transparent and shows you when the transaction was confirmed.
- On the testnet this might take even longer due to less stake pools. This is an external delay that is caused by the blocks being created every 20 seconds and infrastructure delay when the backend infrastructure registers the new blocks. This is also the time before an agent would detect your request.
- During the time between blocks the agent would collect the requests that appeared on the blockchain since the last interaction with a liquidity pool and submit a batch transaction. This would again take 5–30 seconds to confirm the transaction.
- The total perceived time after creating a request to the point where swapped tokens arrived to your wallet could be 15–60 seconds, but in reality most of it is waiting for confirmations.
- Anything over this could mean that the network might be congested or that agents are collecting more requests to reduce blockchain congestion.
This post is in our technical series, and will be added to on a weekly basis. Our next topic will be around “Concurrency” with the aim of answering some of the community’s many questions around the topic.
Come join us and Fly! #WingRidersDEX
