How to solve the Plutus scalability issue?

Question

This issue is one that'll plague projects trying to build on Cardano.

Let's consider Lecture 10 of the first iteration of the Plutus Pioneers Program (https://www.youtube.com/watch?v=Dg36h9YPMz4&feature=youtu.be&ab_channel=LarsBr%C3%BCnjes), if I want to send a swap transaction, I have to consume the latest pool state (containing the token balances owned by the pool). Does it mean in any block there can be only one transaction per pool? If two or more users are trying to consume the latest UTXO, only one transaction will be successful and other users have to change their transactions to reference the new UTXO.

Here are some links where it's mentioned:- https://twitter.com/LarsBrunjes/status/1390331642103877633?s=19- General approach for allowing multiple smart contract transactions per block

Answer 1

This should not be thought of as a scalability problem, but more as a design parameter for whatever smart contract you are building.

There are many creative ways in which projects are trying to make the liquidity pools work. SundaeSwap is using the Scooper model, which you can read about here. It goes over the tradeoffs for each popular type of DEX, and why they chose the Scooper model. Definitely worth a read.

I think that Cardano's eUTxO architecture is uniquely suited for orderbook DEXes. Since there is no global state to worry about (unlike EVM L1's), it also eliminates several design constraints that you have to worry about in designing EVM apps.

Each project is taking a unique approach, and it's worth looking at all of the major ones as a developer I think. Some of the most interesting DEXes so far are:

• SundaeSwap (Scooper model + AMM)
• Minswap (another AMM)
• Genius Yield (this one is really interesting because it is orderbook-based and Lars himself is the CTO).

So I guess the short answer is, there are definitely ways to get around the issue of many transactions trying to consume the same output, and that isn't necessarily a roadblock for scalability. However, building with UTxO in mind is always better than trying to build a 1-to-1 replica of EVM dApps.

Answer 2

In other discussion, Lars said a real implementation of something like this or the Oracle could use - instead of an NFT - its own currencySymbol, and then have multiple UTxOs which could be grabbed concurrently at one time.

Here there is talk of "read-only" inputs : https://github.com/Emurgo/Emurgo-Research/blob/master/smart-contracts/Unlocking%20The%20Potential%20Of%20The%20UTXO%20Model.md