user234: In some applications, multiple users interact with the same smart contract and may want to do it at about the same time. Such interaction involves updating the state of the smart contract as embodied in the UTXOs of the smart contract address. One example application is a DEX.
Because all the users interact with the same smart contract, potentially spending existing UTXOs and creating new ones, potentially only one user can succeed in each block and the other users have their transactions rejected due to double-spending the UTXOs, limiting the throughput of the application.
Is there a general approach for dealing with this kind of situation to allow more transactions for a smart contract to succeed in each block?

user1147: Theoretically, you can just create multiple eUTxOs to reduce collisions. But that isn't an ideal solution. For example, an oracle would have to maintain a lot of different eUTxOs and create new ones to update the oracle value. This would cause a lot of transaction fees for the oracle provider, linearly increasing by count.
Additionally, I'm wondering How can an oracle guarantee certain update rates respectively uptime?

user4764: Please see my article "Scaling with UTXOs." I outline several different approaches. These include buffering, state sharding / replication, and using transactions which do not consume UTXOs.
https://journal.platonic.systems/p/scaling-with-utxos

user1130: This has been bugging me for a while now. I'm not as worried about it as I was before though. Here are some thoughts:
Lars says there are ways around the problem:

Of course there are ways around. You need to parallelize. In an auction contract, for example, you can have several UTxO's instead of just one.

This seems fine to me. Of course there is still a chance of collision. A collision isn't the end of the world, but you could make as many UTxOs as you want to minimize the worry. You can also do things off-chain to pseudo-randomly choose a UTxO (with the modulo of your hashed redeemer, for example).
Back of napkin estimates
If you look at something like Uniswap, which has on the order of ~100K transactions/day and ~50 Liquidity pools. Cardano has 4320 blocks/day, so that would be an average of around .5 tx/block/lp (obviously some pools are much more popular). But having somewhere between 10-100 UTxO/pool should be plenty.
How does it work?
EDIT: This actually still has problems. I can't think of how you would determine the rates without including all the UTxOs in a txn--which defeats the purpose. Hmm, still need to think things through.
For a Uniswap, the way it could work is the sum of all the datums on liquidity pool NFT UTxOs in a pool equal the total liquidity for that pool. Anyone adding or removing from the pool can modify any number of the UTxOs, but for the sake of fees they would tend to modify the minimum number necessary to add/remove from the pool. For pools with a lot of collisions, there might even be a way to incentivize participants to open new pools or even add more UTxOs to existing pools perhaps? The factory token would just need to keep track of how many liquidity NFTs are floating around for each pool.

user28: Not as far as I know. The current model is limited to one state change (transaction) per block per smart contact.
However, depending on the specific smart contact and its use case, I can see people using a centralized entity (or a group of users) post transition proposals and then have an incentive to bundle all of those up into one that actually modifies the global state. Not ideal, but this is the price to pay to have a state-full smart contact design.

user202: According to Lars Brünjes concurrent state machines are being researched https://twitter.com/LarsBrunjes/status/1390331642103877633?s=19

234: <p>In some applications, multiple users interact with the same smart contract and may want to do it at about the same time. Such interaction involves updating the state of the smart contract as embodied in the UTXOs of the smart contract address. One example application is a DEX.</p>
<p>Because all the users interact with the same smart contract, potentially spending existing UTXOs and creating new ones, potentially only one user can succeed in each block and the other users have their transactions rejected due to double-spending the UTXOs, limiting the throughput of the application.</p>
<p>Is there a general approach for dealing with this kind of situation to allow more transactions for a smart contract to succeed in each block?</p>
 1147: <p>Theoretically, you can just create multiple eUTxOs to reduce collisions. But that isn't an ideal solution. For example, an oracle would have to maintain a lot of different eUTxOs and create new ones to update the oracle value. This would cause a lot of transaction fees for the oracle provider, linearly increasing by count.<br>
Additionally, I'm wondering <a href="https://cardano.stackexchange.com/questions/769/how-can-an-oracle-guarantee-certain-update-rates-respectively-uptime">How can an oracle guarantee certain update rates respectively uptime?</a></p>
 4764: <p>Please see my article &quot;Scaling with UTXOs.&quot; I outline several different approaches. These include buffering, state sharding / replication, and using transactions which do not consume UTXOs.</p>
<p><a href="https://journal.platonic.systems/p/scaling-with-utxos" rel="nofollow noreferrer">https://journal.platonic.systems/p/scaling-with-utxos</a></p>
 1130: <p>This has been bugging me for a while now. I'm not as worried about it as I was before though. Here are some thoughts:</p>
<p><a href="https://twitter.com/LarsBrunjes/status/1403760389024894979?s=20" rel="nofollow noreferrer">Lars says</a> there are ways around the problem:</p>
<blockquote>
<p>Of course there are ways around. You need to parallelize. In an auction contract, for example, you can have several UTxO's instead of just one.</p>
</blockquote>
<p>This seems <em>fine</em> to me. Of course there is still a chance of collision. A collision isn't the end of the world, but you could make as many UTxOs as you want to minimize the worry. You can also do things off-chain to pseudo-randomly choose a UTxO (with the modulo of your hashed redeemer, for example).</p>
<p><strong>Back of napkin estimates</strong></p>
<p>If you look at something like Uniswap, which has on the order of ~100K transactions/day and ~50 Liquidity pools. Cardano has 4320 blocks/day, so that would be an average of around .5 tx/block/lp (obviously some pools are much more popular). But having somewhere between 10-100 UTxO/pool should be plenty.</p>
<p><strong>How does it work?</strong></p>
<p><strong>EDIT:</strong> This actually still has problems. I can't think of how you would determine the rates without including all the UTxOs in a txn--which defeats the purpose. Hmm, still need to think things through.</p>
<p>For a Uniswap, the way it could work is the sum of all the datums on liquidity pool NFT UTxOs in a pool equal the total liquidity for that pool. Anyone adding or removing from the pool can modify any number of the UTxOs, but for the sake of fees they would tend to modify the minimum number necessary to add/remove from the pool. For pools with a lot of collisions, there might even be a way to incentivize participants to open new pools or even add more UTxOs to existing pools perhaps? The factory token would just need to keep track of how many liquidity NFTs are floating around for each pool.</p>
 28: <p>Not as far as I know. The current model is limited to one state change (transaction) per block per smart contact.</p>
<p>However, depending on the specific smart contact and its use case, I can see people using a centralized entity (or a group of users) post transition proposals and then have an incentive to bundle all of those up into one that actually modifies the global state. Not ideal, but this is the price to pay to have a state-full smart contact design.</p>
 202: <p>According to Lars Brünjes concurrent state machines are being researched <a href="https://twitter.com/LarsBrunjes/status/1390331642103877633?s=19" rel="noreferrer">https://twitter.com/LarsBrunjes/status/1390331642103877633?s=19</a></p>
