1

Lets imagine I have UTXO sitting with some Datum, for example storing information about some USDT balance, which I am currently selling to anyone (as in lecture 8 of iteration 2). Can there be for example 100 buyers in the same slot/block who initiated transaction with UTXO's of their balances and my one and only UTXO holding USDT for sale as input? Would these 'actions' sit in a queue of sorts and be executed one after another, while deducing currency being sold on each iteration?

If not, can anyone think of a theoretical way of allowing multiple users to buy my USDT coin on the same block/slot?

If for example I would 'shard' my selling UTXO into 100 UTXO's holding only part of total balance, how could I match buyer UTXO's with multiple partial selling UTXO's in decentralized way? I don't know, some kind of router or something.

Thank you for the answers

Improve this question

2 Answers 2

Reset to default
1

Can same UTXO be consumed multiple times in a same slot/block?

No. Nor can it ever be consumed multiple times. That's what UTxO (Unspent Transaction Output) means, it hasn't been spent yet and can only be spent once.

If not, can anyone think of a theoretical way of allowing multiple users to buy my USDT coin on the same block/slot?

This is an ongoing conversation in the community.

It really depends on what behavior you want. "Shard"ing the UTxO (as you suggest) could be a valid approach, you just need some way to minimize the chance of collision. You could include some entropy in the off-chain code to choose UTxOs at random and that could help, but collisions are bound to happen occasionally--not the end of the world, but messy.

Something I mentioned here is having off-chain services that batch requests to buy USDT. This would enable all the purchases to occur in a single transaction like what Noah Jones mentions in their answer. This kinda adds centralization, but still requires the batcher to meet the smart contracts requirements, so it's a minimal risk. There isn't a risk of extractable value either in the USDT case AFAICT, but that is something to keep in mind as well.

Improve this answer
4
  • Thanks for the answer. Batcher solution sounds nice, yet it kind of defeats the whole point of decentralization, unless its also decentralized service with transparent code sitting on the blockchain. Regarding random UTxO matching, if all of the buyer and seller UTxO's would be spent on the same block, half of them would fail (not even talking it wouldn't see each others state, which is kind of a must for more advanced solutions like AMM's)
    – serx
    Commented Sep 17, 2021 at 10:09
  • Maybe it would be possible for off-chain Plutus script to block just before block is produced (like slot 18), and only then spending all of the UTxO's accumulated until that point, with only 1 unique seller UTXO?
    – serx
    Commented Sep 17, 2021 at 10:12
  • "yet it kind of defeats the whole point of decentralization" maybe not. The batcher still has to follow rules set on the blockchain--the trust is still decentralized and they are incentivized to batch as many fulfillments as possible into their transaction. Even in the case you get DOSed (by a silly actor), it wouldn't ever drop below 1 txn/block (empty batches wouldn't spend the state UTxO). Also, theoretically, you could be your own batcher, so you don't have to rely on some service.
    – Mitchell Turner
    Commented Sep 17, 2021 at 17:54
  • (We already rely on batchers on the chain, i.e. block producers batch transactions into the blocks)
    – Mitchell Turner
    Commented Sep 17, 2021 at 18:10
0

Yep, it's pretty straightforward: The transaction will consume the 1 UTxO with your 5000 USDT and the 5000 UTxOs submitted by your buyers each purchasing 1 USDT. The output will then be 5000 UTxOs each containing 1 USDT to each of the buyers making a purchase. This all occurs within 1 transaction. In the UTxO model, one transaction can have many inputs and many outputs.

Improve this answer

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.