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.
Here is a big old list of relevant resources. Some of them claim (credibly, I think) to solve the problem without sacrificing decentralization.
Minswap reflecting on the incident that sparked the FUD storm
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.
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.
SundaeSwap has already addressed this issue. Feel free to give it a read. https://sundaeswap-finance.medium.com/concurrency-state-cardano-c160f8c07575