13

Are there any solutions to the concurrency issue so far without sacrificing decentralization? MinSwap testnet was experiencing this last night and just looking for some clarification, haven't seen much spoken on this subject, thanks.

Improve this question
2

6 Answers 6

Reset to default
6

Here is a big old list of relevant resources. Some of them claim (credibly, I think) to solve the problem without sacrificing decentralization.

From IO

From projects

Videos

Minswap reflecting on the incident that sparked the FUD storm

Indie contributions

Improve this answer
2
  • 1
    I think this article from Maladex also deserves some attention.
    – Jelil Akjaly
    Commented Sep 24, 2021 at 18:19
  • Appreciate it @JelilAkjaly. Adding this.
    – Matthew Capps
    Commented Sep 25, 2021 at 4:50
4

The Occam.fi team claims to have a solution that works for their DEX.

The solution uses an intra-block slot auction system to process multiple transactions simultaneously, which is essential for a fully functional and high-volume DEX.

Looking forward to learning more about that approach.

Another solution I've thought about is introducing an off-chain service provider called a "batcher" who is incentivized and authorized to batch a bunch of concurrent transactions.

Take a DEX for example. If many people are trying to provide liquidity to a pool at the same time, instead of them all trying to access the "liquidity total" datum concurrently, each actor could lock their liquidity + a batching fee in a separate escrow script that requires a minimum amount of liquidity tokens to unlock. They then submit a "batching request" datum to the DEX. The off-chain batcher can filter all the request datums and execute as many as they can simultaneously.

The minimum liquidity token requirement on the escrow script prevents the liquidity providers from being screwed over--they set the terms-- and it also allows some flexibility in a volatile market, but there is still a level of centralization of the batcher. My biggest worry would be regulatory intervention, as the batchers could be seen as MSBs. You could theoretically solve this with federalization of the batching responsibility.

All-in-all, I think there are many ways to solve the concurrency problem. Charles talked about additional side-chain solutions in this video. I think we just need to be comfortable with the idea that the solutions might just look different from what we see on Ethereum, and that's okay. Ethereum has it's own set of problems that needed creative solutions as well.

Improve this answer
2
  • Thinking about the “batcher” service more, it could be valuable to speak of the concurrency congestion as a small “risk.” In designing an app, you can offload that risk to some party other than the costumers of your dApp’s core business, for a small incentive. So back to the DEX example, you don’t need the batcher to be authorized, just incentivized. The risk being that their transaction doesn’t succeed and the resources needed to pay attention we’re wasted. A small risk, but the fee needs to be high enough that it keeps batchers’ attentions.
    – Mitchell Turner
    Commented Sep 6, 2021 at 20:07
  • 1
    In fact, if structured right, the "batchers" might just be the submitters of requests the previous block. You'd just need to be sure that they are incentivized to include other people's requests in their batch.
    – Mitchell Turner
    Commented Sep 6, 2021 at 20:34
1

To my knowledge, there is no concurrency issue on Cardano. If multiple people want to perform some transaction, then on Cardano, you can bundle all of those into one UTxO with several inputs and several outputs. Could you please provide some more details?

Improve this answer
1
  • The issue (for others) is that they may have 2 transactions attempt to use same tx-in. This problem was solved 40 years ago via serialised access, a staple to the dev community. Be very proud you are not having this issue. It's so simple it's almost juvenile.
    – Patrick Sturm
    Commented Sep 25, 2021 at 16:25
0

SundaeSwap has already addressed this issue. Feel free to give it a read. https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575

Improve this answer
1
  • The solution is the shortest section in this article cited. And all it basically says is "Stay tuned for more information".
    – lambda
    Commented Sep 19, 2021 at 5:15
0

Even though the EUTxO model ensures that outputs are not double spent, therefore limiting dApps to one "transaction" per UTxO every twenty seconds, it is not a requirement to use one UTxO only and there are numerous implementations one could think of in order to preserve concurrency.

Instead of keeping a list of all "pools" in one UTxO and use a NFT so as to ensure their validity, for example, you could have a minting policy that requires some specific Datum in these pools (like you would check in the old implementation when validating) and only allows the minting of these specific tokens if the pool has a valid hash, a valid datum and that the token is being transferred to the pool.

Later, off-chain code would be able to identify "authentic" pools by verifying if they hold the token minted by this minting policy, since they would only receive these tokens if the requirements were met.

This is the logic I'm using in a project I'm working on called DigiServices. More details on the implementation can be found here https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#i-utxo-identity and here https://github.com/mateusap1/DigiServices/tree/fdel15/wp-edits-2#6-scalability (though the paper needs a lot of adjustments)

I'm sure there are numerous other ideas and ways. The magic of being open to the public is that anyone can design their implementations. In my opinion, the EUTxO model offers a number of advantages when compared to the account model and most of the disadvantages can be overcome with a little bit of creativity and engineering.

Improve this answer
-1

No issues, just inexperienced team at miniswap testing and developing. Great publicity for cardano and opportunity to showcase how advanced the protocol is and ready for the future which may not even be Uniswap type DeFi

Improve this answer
2
  • 4
    Answers should be complete, evidence-driven, and with sources/examples - this would be better suited as a comment :) For example a link to an article showing a how a DApp is managing concurrency at scale or a detailed example of why miniswap is wrong would be better.
    – Eddy Schauman-Haigh
    Commented Sep 5, 2021 at 23:12
  • Please add further details to expand on your answer, such as working code or documentation citations.
    – Community Bot
    Commented Sep 5, 2021 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.