Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow validator invocations to spend multiple UTXOs #4213

Closed
treeowl opened this issue Nov 12, 2021 · 6 comments
Closed

Allow validator invocations to spend multiple UTXOs #4213

treeowl opened this issue Nov 12, 2021 · 6 comments
Labels
enhancement status: needs triage GH issues that requires triage

Comments

@treeowl
Copy link

treeowl commented Nov 12, 2021

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?

@kk-hainq
Copy link
Contributor

kk-hainq commented Nov 13, 2021

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.

@michaelpj
Copy link
Contributor

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.

@purefn
Copy link

purefn commented Nov 24, 2021

@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?

@kk-hainq
Copy link
Contributor

@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.

@effectfully
Copy link
Contributor

@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".

@effectfully effectfully added the status: needs triage GH issues that requires triage label Apr 10, 2023
@michaelpj
Copy link
Contributor

michaelpj commented Apr 11, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement status: needs triage GH issues that requires triage
Projects
None yet
Development

No branches or pull requests

5 participants