How to do a plutus smart contract vending machine?

Question

I am building a vending machine where the users have to first send ADA to some address then my backend selects NFTs and sends back to the user who payed. I have been wondering if is there a way to do it using smart contracts?

The NFTs are all locked in a contract and we make the tx to the contract from the front end to unlock them. But my problem is: How could I make that the NFTs are randomly seleceted?

The front end might randomly select some. But when the Browser Wallet ask for sign the transaction it will show which NFTs are selected and then the user might decline or accept the transaction depending of the NFTs.

The main problem is that NFT must be randomly selected. How can I solve this problem?

Answer 1

In Cardano, all transactions are deterministic, which means you can not have unpredictable randomness, even if you inject an entropy source from, lets say and Oracle, the user who constructs the transaction will always know in advance the outcome, all variables are known at TX construction time. He then can choose to not sign/send the transaction if the outcome is undesirable.

One way to solve this problem, is to obfuscate from the user the meaning of the outcome, he will know which NFT he is getting (Asset Name), but maybe the NFT metadata is not revealed until after the NFT has been bought. Although this would require some off-chain business logic (when NFT A is bought, publish NFT A metadata). This would work better by committing to the metadata by pre-publishing a Hash of it, so the buyer knows the metadata that is being published was not changed after the fact. Sadly CIP-0025 doesn't allow to do this via smart contract because it relies on transaction metadata which cannot be read from smart contracts, so it would have to be done via an honor system.

Another approach would be to use a model similar to the current liquidity pools (I.E Minswap), The users initiate a buy order by sending ADA to a contract address, then a batcher would continuously select these orders from contract A, and execute the buy by taking the NFTs from contract B and sending it to the users. At this point, the batcher could use an Oracle as the entropy source, or the UTXO ID hashed with some secret value to pick the NFT to send to the user. This would still require some off-chain code (the batcher), but at least you could program some fairness into contracts A and B, for example, by preventing anyone to claim the money the user deposited in the buy order without sending the NFT back. (claiming the ADA in buy Order would require an NFT of a specific policy to be returned to the sender). Extra logic could be put in place to for example, allow the original sender to claim back its ADA if the order has not been executed in X amount of time.

Answer 2

Lars already gave a pretty good answer to the randomness problem here. Basically, an oracle is probably the easiest and best way to achieve randomness with entropy.

If you want to avoid an oracle, you might be able to seed your randomness with the transaction ID. There could be some concerns with reverse engineering there, but depending on the scale of your project those concerns might be unrealistic.