plutus

plutus copied to clipboard

I don't know if this is the right place to raise this, but it seems quite odd and inefficient that a script must be invoked multiple times to spend multiple UTXOs in the same transaction. Would there be any problem just passing a validator a nonempty list of UTXOs to spend instead of just one?

It is intuitive to think of a validator script as a vault that locks multiple UTXOs under the same rule. In this sense, it does feel more natural to pass the smaller objects in UTXOs to the bigger object in the validator. However, the other way is actually more precise, in that each UTXO is the bigger vault that stores assets and data, each with a validator script as the smaller lock. In that sense, UTXOs with the same validator hash shares the same lock type but with a different (or sometimes, same) set of passwords in datum (different public keys that can sign stored in datum, etc), redeemer, and script context. What a node does, then, is to try opening each UTXO in the transaction using the passed data as passwords. Each UTXO indeed has a different lock and password.

With that in mind, it is very straightforward to have a transaction consuming different UTXOs with different lock types. For example, a collateral liquidation transaction can consume a debt position UTXO, an oracle price feed UTXO, and a stake position UTXO to have enough convincing data as the password to unlock and liquidate the collateral in the debt position. This level of composability allows an Oracle UTXO to have a lock that says pay me a bit money, keep the data intact and you can include my data in your transaction to validate anything that needs a third-party price (collateral, exchange, and more).

Your proposal can already be achieved in the current setup as the UTXO list can be folded and stored in a single UTXO (both datum and values are highly appendable). When there are legit reasons to separate them, it is more composable to have different locks or passwords on each one.

The true reason is that it is more complicated, and the current system is heavily slanted towards being as simple as we could get away with. Outputs are associated with spending conditions; different outputs are independent in that respect.

Here are a bunch of other issues, although I don't think any of these are the true reason not to do this.

• Redeemers and datums are per-output, but of course you could pass in a list of those too.
• Reasoning becomes even less compositional, since you're explicitly entangling the validation of multiple outputs. If anything, we'd actually like to move in the opposite direction, and make it easier to keep them apart, to make reasoning more compositional.
• The interface with the ledger becomes more complicated.

@kk-hainq Can you describe in more detail what you mean by

Your proposal can already be achieved in the current setup as the UTXO list can be folded and stored in a single UTXO

Are you suggesting a new redeemer for validators that allows a transaction with multiple script inputs and, as output, combines them into a single script output UTXO with the datums and values combined?

@purefn My comment was simply about running a validator once instead of twice if we store things in one instead of two UTxOs, regardless of how it's done. Sometimes it makes sense, sometimes it complicates logic and increases congestion risks.

And yes, what you mentioned is useful in several scenarios. For example, to avoid congestion, users in a voting dApp can frictionlessly mint a special token to cast a vote with the vote validated by that token's minting policy. Batchers can then continuously fold these UTxOs to count votes. This scenario combines UTxOs to progress state though, not to avoid the number of validator invocations in transactions.

@michaelpj this issue has been open for quite a while and given the previous comments it doesn't seem like we're going to change the behavior? In that case, please close the issue as "won't do".

I think the correct place to discuss this now is probably a CIP. This CIP is I think an inheritor of the general concern.