Management of wrapped redeemers in foreign validators

[MicroProofs]

What are multivalidators?

Boils down to "a validator that supports both 2 and 3 argument validations. I.e. The validator can be used for both spending and minting or staking and spend, etc. These validators allow for spend and mint validators that share the same validation hash and thus are "aware of each other's presence in the transaction."

How is that possible?

In aiken we check if the second argument is a constr with tag 0 or 1. If 0 assume script context and run two argument validator. If 1 assume spend validator, unwrap the second argument and pass it to the 3 argument validator. If you try to cheat the validator by passing in 3 arguments with a redeemer wrapped in the 0 tag, then the virtual machine will error anyway.

The issue, The Transaction field "redeemers"

The redeemers in the script context field redeemers are still wrapped with the 1 tag for spend validators. They aren't the redeemer type. They are the redeemer type wrapped in the 1 tag constr.

How do we present that information so people don’t shoot themselves?

Do we convert their redeemer type? Maybe have a special annotation on the type?

[MicroProofs]

A bit click-baity. The issue won't affect most people and can easily be accounted for when known.

[KtorZ]

One possible solution: have an opaque type around redeemer instead of being plain Data in the standard lib; and provide conversion functions to from opaque redeemer to data / user-defined redeemer that take care of the transformation.

The API could be as simple as taking a enum "IsSimpleValidator|IsHybridValidator" and wraps it accordingly.

That's a bit lame but while we work on something more robust it would prevent people shooting themselves in the foot.

[MicroProofs]

Another thought I had is maybe a best practice around not using multi-validators in specific cases. Like cases where you want to potentially look up the redeemer of multiple spend validators. Maybe the multi-validator should generally be only used for spend validators that have a unique input to unique output.