19

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?

5

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.

5

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

1

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?

1

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.

0

One possible solution for this is that instead of letting the users of your dapp compete for a single UTxO you let them publish a "request for transaction" and then let an open bot network compete to aggregate and execute these transactions into a single block. If your dapp relies on a single state stored in a single UTxO then only one bot will be able to consume that UTxO but you can design your smart contracts in a way that will allow the winning bot to execute multiple "request for transaction" together with consuming the state UTxO. If these "request for transaction" contain a bounty then bots will be incentivized to execute as many "request for transaction" as possible and it doesn't matter which bot wins since all bots will try to execute all transactions.

Variations of this solution are described in the following blog posts:

https://medium.com/meld-labs/concurrent-deterministic-batching-on-the-utxo-ledger-99040f809706 https://medium.com/minswap/introducing-laminar-an-eutxo-scaling-protocol-for-accounting-style-smart-contract-d1ac8847dde8

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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