Redeemers in Script Context

[kk-hainq]

Area

[x] Plutus Foundation Related to the GHC plugin, Haskell-to-Plutus compiler, on-chain code
[] Plutus Application Framework Related to the Plutus application backend (PAB), emulator, Plutus libraries
[] Marlowe Related to Marlowe
[] Other Any other topic (Playgrounds, etc.)

Describe the feature you'd like

We want each input's validator script to be able to read the redeemers of other inputs in the same transaction.

Describe alternatives you've considered

We simply can't read other inputs' redeemers from the script context at the moment.

Additional context / screenshots

We used to be able to read redeemers of each input in txInfoInputs through txInInfoWitness of each TxInInfo. This redeemer was listed in most EUXTO design specifications (1, 2) until the Alonzo changes, that 9fbdb53 implemented.

We wonder if this removal was due to some security properties, or to reduce the context's size. The Alonzo specs don't explain it, and re-addition seems pretty simple (txInfo already has a tx with redeemers in its witnesses).

For why such information may be useful, there are certain contract designs that can be simplified by each input knowing how each other passes validation. For example, it may be useful for input A to know if input B validates with a write redeemer (that also proves ownership) or with a simple read redeemer. Input A can diff B's new and old Datum to reason about the change but this might require unnecessary calculations. There are also cases where reversing is impossible, like an open-to-close transition of a debt position might be the result of repayment or liquidation, two very different cases for input A to react to.

We can add extra Datum fields or new supportive output types as a workaround for our own scripts. It gets tricky when we want to integrate with others' contracts, where we can't decide any data type and validation rule.

In summary, there are cases where we want to validate our input if the transaction consumes another input with a specific redeemer. Working solely with Datum without Redeemer usually leads to more complexity and corner cases to care for. Checking for a specific Redeemer, on the other hand, instantly eliminates many logics in other redeemer types.

P/s: We post the issue here because ScriptContext is defined here and txInfo is supposed to be language-dependent. Can create another conversation at cardano-ledger-specs if necessary too.

[michaelpj]

This was supposed to be in Alonzo. Somehow it failed to be implemented, I'm investigating.

[kk-hainq]

This is now implemented in V2, thank you!

• SCP-2771: Plutus V2 interface #3952
• Support for Plutus V2 (ledger API) cardano-ledger#2485