0

I can think of one solution, which is the validator script checks if a specific NFT is locked by the script address. Because of the nature of the NFT, it ensures there is at most one UTxO sitting at the script address at any given time that can also be consumed.

This is to ensure there is a chain of UTxOs sitting at the script address without forking.

I wonder if there are any other solutions.

3
  • 1
    Have you met the statemachine (github.com/input-output-hk/plutus-apps/blob/main/…) There are examples in the plutus-use-cases and the later weeks of the PPP. It works like you describe: using an NFT to keep track of state
    – waalge
    Apr 8 at 13:12
  • Yeah. I was aware of state machine. I was just wondering if there were any other alternative solutions.
    – Qin
    Apr 8 at 13:30
  • By watching PPP Week 7 lecture, using ThreatToken within state machine is another way to achieve it.
    – Qin
    Apr 9 at 2:29

3 Answers 3

1

Yes, you can use a policy id as a parameter to that script and say that the script can only be consumed if it contains a token with that policy ID. You then mint an NFT and send it to this script (which should have the policy ID from your NFT as a parameter).

Since NFTs are unique, this will be the only UTxO that can be consumed, because the rule enforces that the script can only be consumed if it has that specific unique token.

0

As far as I know there is no such way to ensure that only a single UTxO exists at any given address since anyone can send ADA to some address - independently of whether it's a script address or not.

Also a validator script only runs when an output is spent from the validator's address. Therefore there is no check in place/ available that could possibly run when new UTxOs are created at some address.

4
  • You are right that anyone can send ADA to the script address, which will make multiple UTxOs sitting at the same script address.
    – Qin
    Apr 8 at 12:46
  • Perhaps I should've asked my question differently. I intended to seek ways to ensure at any given time at most one UTxO sitting at the script address can be consumed. This is to ensure there is a chain of UTxOs sitting at the script address without forking.
    – Qin
    Apr 8 at 12:53
  • Sounds like you sort of state machine to me.Without more context it's difficult to understand the problem. One way I could imagine doing something like that is perhaps by spending and recreating all but one UTxO that is suppose to be chained.That way the validator sees all inputs (chained UTxOs) and can ensure only one is correctly consumed (technically all are consumed) but the validator can check if all other output references are recreated at the script address with the correct datum. That way you can perhaps chain utxo consumption but still not sure if that's a good solution for your prob Apr 9 at 17:22
  • State machine indeed sounds a good solution by using its threadToken.
    – Qin
    Apr 10 at 0:21
0

You generally CAN'T prevent the creation of UTxOs

But you can check that all UTxOs sitting at the validator address are included in the transaction

This way if say you have 2 or more UTxOs, you have to include all of them for the transaction to succeed, and then have one single UTxO as output (or zero if all the founds are sent away)

Doing so should minimize the number of UTxOs, the more the validator is run, the more often the number of UTxOs is reduced to one (or zero)

Edit:

some useful functions that you can use to check all the validator UTxOs are included are:

scriptOutputsAt :: ValidatorHash -> TxInfo -> [(DatumHash, Value)]
findContinuingOutputs :: ScriptContext -> [Integer]
getContinuingOutputs :: ScriptContext -> [TxOut]
findTxInByTxOutRef :: TxOutRef -> TxInfo -> Maybe TxInInfo

and the list goes on, just have a look at <your docs from plututs-apps>/haddock/plutus-ledger-api/html/Plutus-V1-Ledger-Contexts.html

5
  • In this case, can we design a validator script in a way such that it can ensure ALL UTxOs sitting at the script address are included in the transaction? I think we are not able to achieve it as validator script does not have a global view beyond the spending transaction.
    – Qin
    Apr 9 at 1:50
  • @Qin the validator is part of the transaction, it is possible then to include all his utxos
    – Michele
    Apr 9 at 7:23
  • If all UTxOs sitting at the script address are included in the transaction, then consuming all of them and outputting a single UTxO would be a solution. However, the validator is not able to guarantee that all UTxOs sitting at the script address, without omission, are included in the transaction.
    – Qin
    Apr 10 at 0:13
  • @Qin Yes a validator cannot build a transaction but it can fail if the transaction does not respects some criteria; in this case the validator should fail if not all UTxOs are spent; I'm editing the answer with some function that may turn usefull
    – Michele
    Apr 10 at 7:28
  • "But you can check that all UTxOs sitting at the validator address are included in the transaction". I don't think you can, validatos only have access to what is provided inside the transaction, you might very well have 10 script UTxOs and only provide two of them as inputs
    – Mateus
    May 10 at 10:07

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.