CIP-???? | Tag / Redeemer field in TxOut

[colll78]

We propose to allow the attachment of arbitrary, temporary data to transaction outputs within the script context. This data, akin to redeemers in their operational context, is intended to be used exclusively during the execution of Plutus scripts and thus are not recorded by the ledger. This will facilitate a wide variety of smart contract design patterns, one of which can be used as a general solution for double satisfaction without sacrificing script composability.

---

(proposal rendered from branch)

[rphair]

@colll78 we're not adding this for discussion in today's CIP meeting, where new proposals are normally introduced in Triage, because of the Draft status (as also with #749). Please feel free to leave it in this state as long as you need... then we will proceed to meeting discussion as well as more rigorous community review (though leaving it here for public comment now is also welcome).

[colll78]

@colll78 we're not adding this for discussion in today's CIP meeting, where new proposals are normally introduced in Triage, because of the Draft status (as also with #749). Please feel free to leave it in this state as long as you need... then we will proceed to meeting discussion as well as more rigorous community review (though leaving it here for public comment now is also welcome).

Whoops, I didn't mean to set this as a draft.

[rphair]

@colll78 Due to last minute status change this has been added to Triage (not time for full technical review; just an introduction) at today's meeting: https://hackmd.io/@cip-editors/80

[Ryun1]

Input from the IOG Plutus and Ledger teams would be appreciated here 🙏
@michaelpj @lehins

[michele-nuzzi]

Including this information in the witness set might be an attack vector.

The user signs the transaction body, not the witness set.

That means that once transaction is signed the witness set might still change, and the signature would be correct.

That implies the user agreed to sign something that is later modified.

This is not a problem for redeemers because usually the information present on redeemers is validated in the contract, so if an attacker modifies it, a carefully designed contract will fail.

In the example use case of the "TxOutRef in output datum" that information is indeed in the datum, which is part of the tx body, which is signed and hence immutable once signed (or else the signature is invalid).

if we move this info outside the body the TxOutRef can be modified after signing, leaving the contract vulnerable to double satisfaction.

[michele-nuzzi]

also modifying the redeemer indirectly causes the body to be invalid, because redeemers and datums in the witness set are used to calculate the scriptDataHash

modifying these will result in a different scriptDataHash, hence the body is invalid

[lehins]

The user signs the transaction body, not the witness set.

The user does sign some parts of the witness set (redeemers and datums) indirectly through the script hash integrity check.

[michele-nuzzi]

Yes that is correct I corrected myself in the coment

[colll78]

Right the idea would be for the user to sign this information the exact same way they sign redeemers and datums (ie adjust script hash integrity check accordingly). I will update this CIP to reflect that.

[michele-nuzzi]

the idea would be for the user to sign this information the exact same way they sign redeemers in datums (ie adjust script hash integrity check accordingly

@colll78 please don't

scriptDataHash is already a pain, I would suggest instead to move the field as is inside the body

[HeptaSean]

Maybe also move the redeemer in the body in the process?

[colll78]

I agree that it would be best if redeemers were directly in the transaction body and I would fully support a separate CIP to that end, however, given that currently they are signed via scriptDataHash I don't want to introduce inconsistency by moving these into the body in which case tooling would have to accommodate them differently than they do normal redeemers. The idea is to keep them as close from an implementation perspective to transaction redeemers to lower the implementation burden.

[michele-nuzzi]

@colll78 trust me, scriptDataHash is much worse than a small inconsistency

[colll78]

Should we not then create a CIP to move redeemers into the tx body?

[michaelpj]

I don't like it: it adds a kind of weird dangling feature that is useful in this one specific case, and otherwise doesn't mean anything. But I acknowledge that it's a reification of the pattern people currently use.

What I would like is some more principled solution to the double satisfaction problem, which we don't have.

So I guess it's a -0 from me: I would prefer not to do this but if there's lots of support and no alternative I wouldn't block something like this.

[michaelpj]

This made me wonder why you can't in fact use redeemers.

If a particular script execution needs to know which transaction output is "it's" output for some purpose, then you can put the index of that output into the redeemer.

The answer (I think) is that for double-satisfaction you need exclusivity: with the redeemer solution each redeemer has its own mapping and nothing ensures they don't overlap. With output tags you have (I assume) a single tag.

That does sit a little awkwardly, however. Why shouldn't you have multiple tags? What if you do want to use a single output for two purposes in a legitimate way? e.g. "this is the payout address for the Ada" and "the permission token goes here".

[colll78]

The type of output_tag is data, so you can have any arbitrary information you want in the output so you can store whatever you want there.

What if you do want to use a single output for two purposes in a legitimate way? e.g. "this is the payout address for the Ada" and "the permission token goes here".

That is two outputs though right? IE 1 output is "payout for ada" and 1 is "permission token output", in which case you tag each output accordingly.

The issue is that matching the redeemers to the outputs is very expensive and they aren't really designed to facilitate this time data association with outputs so the interface would be awkward.

[michaelpj]

I think I would prefer this approach, and for us to just solve the lookup time problem properly.

[michaelpj]

I'm not sure the bloat complain quite lands:

1. Anything included in transactions goes in the history of the chain forever, so that would apply to tags as well
2. But: information in datums does bloat the UTXO set, which can be a problem

That is, I would say it's not so much the permanency that's a problem (that happens anyway), so much as the (temporary, but ongoing) UTXO set bloat.

[colll78]

Yes, I did not make it clear I was referring to the UTxO set size which is often what is most impactful on the efficiency of indexers for dApps.

[gitmachtl]

just wanna ask if this affects in any way also hardware wallets? because of the memory constrains, hardwarewallets cannot look at whole utxo sets while performing the signing action.

[rphair]

@colll78 this is lagging in progress a bit and there was a question in the CIP meeting today over some resolutions that weren't recorded. A couple editors including @Ryun1 & @Crypto2099 (I was just taking some notes) + @michaelpj and @fallen-icarus as I remember made the following points:

• This is relevant to a "composability" problem of transaction outputs from one dApp to be applied as inputs to a potentially different dApp.
• Within the CIP process there hasn't yet been any other way of dealing with this composability problem other than the one suggested here.
• However, people are able to deal with composability issues in other ways that don't require the proposed changes... and therefore this solution might only be applicable to the author's own / preferred implementations.

Assuming the above reservations are valid, both @Ryun1 and I (and maybe others) thought this might then be better off as a CPS dealing with composability (and peripherally the "double satisfaction problem"), and suggesting this tagging approach as one means of dealing with it.

[colll78]

@colll78 this is lagging in progress a bit and there was a question in the CIP meeting today over some resolutions that weren't recorded. A couple editors including @Ryun1 & @Crypto2099 (I was just taking some notes) + @michaelpj and @fallen-icarus as I remember made the following points:

• This is relevant to a "composability" problem of transaction outputs from one dApp to be applied as inputs to a potentially different dApp.
• Within the CIP process there hasn't yet been any other way of dealing with this composability problem other than the one suggested here.
• However, people are able to deal with composability issues in other ways that don't require the proposed changes... and therefore this solution might only be applicable to the author's own / preferred implementations.

Assuming the above reservations are valid, both @Ryun1 and I (and maybe others) thought this might then be better off as a CPS dealing with composability (and peripherally the "double satisfaction problem"), and suggesting this tagging approach as one means of dealing with it.

I would like to clarify that this CIP is not designed specifically as a solution to the double satisfaction problem / dApp composability problem. This is a general improvement to the smart contract platform on Cardano that enables a huge range of use-cases that are currently in-feasible. The core value add is the ability to associate arbitrary data with outputs without permanently writing that data to the UTxO set. Sure, it can be used to solve double satisfaction without sacrificing dApp composability (a property that is currently unique to this solution to DS); however, more generally it can be used to do things like tag specific outputs with the USD price of the multi-asset value they contain via a signed oracle message which is associated to the output via this output_tag field. It also could be used to index the location of relevant tokens within the output value map to make onchain token lookups ~O(1); currently searching values is a very expensive and common operation, for instance if you need to find the total number of pool_asset_a in a DEX pool utxo, or if you need to check for the presence of a some state_thread_token (pretty much every dApp on Cardano). This is possible because the location of all tokens in the value of all outputs is known during transaction construction (nice property of deterministic transactions on Cardano), so you don't need to ever perform search on-chain (i.e. valueOf) instead we can just index the location of these tokens via this output_tag field. So, when a contract comes across a TxOut with an output_tag = 6 (idx of state token) it could simply verify that the head of the 6th entry of the value map contains the state token (or provide 2 indices if it isn't the first token with that currency symbol in the value).

It also enables things such as dependent transaction chaining which is a pre-requisite for babel fees. To achieve this, you could use this field to store a TxIn of an input that must be included as a resolving input (see validation zones) for this transaction to be considered valid by the CHAIN level rules for this tx to be included in the block. Since this would be available in the witness set, it would be available during chain level validation without bloating the UTxO set (probably not an exact fit because the update rules and structure needs to be specific for chain level validation).

Likewise this CIP is of critical importance to intent-based operations / smart contract account abstraction. Both of these involve expressing intent offchain which reduces the number of transactions required to execute a user action. For instance, right now when a user wants to interact with a DEX / orderbook they first must create their order (which conveys their intent i.e. to swap X asset A to Y asset B in DEX pool P, or to sell asset A for asset B at exchange rate of E on an orderbook) in a preliminary transaction, and then a second transaction is required to actually fulfil their request (i.e. batch process orders against the pool on an AMM DEX or match orders on an orderbook DEX), furthermore if you want to update your intent (ie. you want to swap your asset A for asset C instead of asset B or you want to increase slippage or update your sell price or even change the asset you are selling) all of these things will require an additional transaction (perhaps multiple). With this CIP, you can provide your intent as a signed message which in turns allows all aforementioned user operations to be fulfilled in a single transaction. The user doesn't need to submit and pay for a transaction to create a swap request / limit order, the instead they can just publicize a signed message that describes their intent (i.e. swap order with XYZ constraints) which can be consumed by dApps directly to allow them to spend funds from the account as long as they do so exactly as intended by the user (as described by the user's signed message). The user can then update their intent without performing a transaction by producing a new signed message that can then (with this CIP) be associated with the relevant input / outputs.

[rphair]

My reading of @colll78's #735 (comment) is that this proposal is still interesting to the community. However, I still have no idea how this would be validated as a candidate.

Since all the prior response was from the Plutus team I'm tagging this as Plutus category even though it looks like it could be applicable to the Ledger. @zliu41 (@lehins WhatisRT) could you confirm (or change) that category and indicate that this proposal might be admissible?

In the meantime marking this as Unconfirmed since it's been triaged already but not validated as a CIP candidate. @michele-nuzzi @MicroProofs if you see any advantage to bringing it into the CIP meeting for discussion again please make a comment here & we'll put it on the schedule.