What happens to DEX UNISWAP when ERC20 tokens migrate to cardano?
The code for Uniswap is still written in Solidity and will not run on Cardano (just yet). However, part of the Plutus Pioneer program there is a lecture that shows how to implement Uniswap functionality in Plutus.
I would also like to hear what more dev heads think about whether this issue will delay the practical arrival of Cardano DEX beyond the hoped-for end of Q3 2021. I can’t recall reading any Cardano DEX funding proposal or white paper mentioning this aspect of concurrency:
It was discussed here, but not with respect to any timeframe:
My impression so far (I’m not a Plutus developer) is that the assumption of Cardano DEX by the end of September, long expected to shortly follow the Alonzo release, is therefore overly optimistic, not taking the concurrency related dev issues into account: sounding more like we might not expect it until early 2022. Of course if this turns out to be pessimistic I will be thrilled to find out why. 
1 Like
Yes, this is a hard problem. Ultimately, every blockchain works sequentially in the same way that you can spent the same dollar bill only once and not multiple times concurrently. The question here is where and how does the sequencing happen.
With Plutus it is currently such that the client’s wallet picks the UTxO. It does this totally disconnected from any other client that might be interested in the same UTxO - for example one that holds the current state of the smart contract. You then have a classical race, the first one wins all others fail.
The current approach that Plutus takes is IMHO correct, they need to get the foundation/fundamentals right. Ultimately there must be an entity that that picks a specific UTxO. A client wallet cannot be that entity. Instead, a client would probably want to work with intensions i.e. Alice wants to send Bob 100 ADA - Alice does not care which specific UTxO the wallet picks to fulfil that intension.
The most basic approach would probably be some sort of retry. i.e. Ok, I lost the race lets try with another UTxO. Alice would not want to see errors resulting from retries. The chances of success (i.e. the throughput) would be higher if the contract was smart enough to distribute its state across multiple UTxO.
In a more sophisticated configuration, the thing that does the retry would coordinate its attempts with with other things that also try.
Ideally, this would not have to be implemented by every smart contract provider. Instead, there would be a higher level Plutus API that has the notion of intent, retry and perhaps even peer synchronization.
… by the end of September
That may be asking a little too much - it would already need to be part of the pioneer curricula.
Would you like to have a practical example of this from the upcoming ASTOR smart contract?
3 Likes
thanks @tomdx … I couldn’t make use of it now, and understanding the implementation details would be above my current level, but if posted here or elsewhere in the public eye I would definitely highlight it for later study. 
1 Like
So does it mean that if there is ouroboros lib for solidy and uniswap is programmed for cardano it will be able to swap between ERC20 tokens?
Confusion here, swap between ERC20 tokens migrated to cardano and ERC20 tokens not migrated to cardano possibility?
What would be the relevance of UNISWAP if CARDAX or YAYSWAP would be able to allow swaps between ERC20 and converted ERC20 tokens?
It’s a bit confusing to me about what’s down the pipeline.
1 Like
Regarding retries, I wonder if Alice would have to wait to retry: Alice could submit the several transactions all at once, each with her UTxO and one of the other candidate UTxOs. No more than one of those would validate and succeed because Alice can only spend her UTxO once. If any of the other candidate UTxOs haven’t been consumed by the time that the block-producing node validates the transaction, then it would succeed; otherwise one of the others might succeed. I just tried this on testnet: if you submit the conflicting transactions (that both consume the same UTxO) to different nodes, then they are both successfully submitted but only one succeeds; if you submit them to the same node, then the second one fails.
If the DEX is large enough for concurrency to become a problem, then it can be split into multiple smart contracts, with (if needed) additional smart contracts acting as arbitrageurs to keep the prices among them nearly synchronized. Clients would submit their transaction (or several simultaneous attempts, as in the previous paragraph) to the most advantageously priced contract(s), though maybe not the absolutely best priced. I haven’t worked out the details, but I think it might even be possible to create a smart contract with multiple state (price) tokens that internally arbitrages among those tokens. Anyway, I think that probabilistic/statistical approach to concurrency would work better than a rigid one, if one is okay with state only being approximately global.
3 Likes
Yes, distributing state over multiple “candidate” UTxO would probably depend entirely on whether the use case permits that. If the API works for a single (semaphore) UTxO it would work for the distributed case as well - just better, I assume.
1 Like
Help me out here a bit… So does it mean if and when Uniswap migrates over to Cardano. I could swap between ERC20 tokens and ERC20 converted tokens. Or will I be able to only swap between ERC converted tokens only. Or does it mean UNISWAP would never be able to come to Cardano even if they wanted to ?
These are two distinct topics. Here, we are discussing currency with the Cardano eUTxO model. Whether tokens found their way onto the Cardano blockchain via the ERC20 bridge or whether we are dealing with tokens that have been “invented” on Cardano doesn’t really matter.
In the more distant future it is planned to support Solidity as one of the languages that can map to Plutus. For now however, we are taking about “Uniswap functionality” that gets reimplemented using Haskell/Plutus.
1 Like
Thanks for sharing it is so interesting since in plutus pioner programs lars talked about it, i think We will get the issue solved! 
Lars solution seems plausible to me.
1 Like
Really!! they talked about this in the plutus pioneer program! Cool! Unfortunately i didn’t get a chance to be a part of the program. But thank you though.