All Babbage related Plutus testing

[Jimbo4350]

ScriptContext equivalence testing
In order to be sure that the "correct" ScriptContext is available to the plutus validator we devised a test as follows:

1. Create a transaction
2. Jsonify the relevant bits of the transaction
3. Feed the JSON to the Plutus validator via a redeemer
4. Check for equality between the values of the redeemer and the ScriptContext

• Implement a golden serialization tests for plutus scripts in both eras

Test Cases for PlutusV1 in Babbage era

• Confirm the existing tests still work in the Babbage Era
• Confirm a failure when a PlutusV1 script is labelled as a PlutusV2 script using build-raw (upon tx submission, we should get MalformedScripts)
• Confirm a failure when a PlutusV1 script is labelled as a PlutusV2 script using build

Test Cases for PlutusV2 in Babbage era

• Update script context equality test for new fields in PlutusV2 (I.e additional fields in Plutus.V2.Ledger.Contexts.TxInfo)
• Confirm a failure when a PlutusV2 script is tagged as a PlutusV1 script using build-raw (upon tx submission, we should get MalformedScripts)
• Confirm a failure when a PlutusV2 script is labelled as a PlutusV1 script using build
• Confirm total return collateral and return collateral output functions as expected this means
  • The correct return collateral is taken when specified
  • We get UnequalCollateralReturn error when the return collateral and total collateral are not equal. We should prevent this in the cli but first make sure we get this error.
• Confirm we can use reference scripts and datums as expected in the Babbage area. I.e successfully execute scripts using combinations of these features:
  • Reference script only
  • Reference script and inline datum
  • Inline datum only
• Write a simple validator using the new serialiseBuiltinData to confirm it works

[JaredCorduan]

For reference, here is everything that can end up in the context in the Babbage era for both PV1 and PV2:

https://github.com/input-output-hk/cardano-ledger/blob/70dbfc9f12283666e29f8492aff5da9b1c8c5a7f/eras/babbage/impl/src/Cardano/Ledger/Babbage/TxInfo.hs#L207-L239

Most of the types are the same between PV1 and PV2, but most notably txInfoOutputs is different in PV2, as it now has inline datums and reference scripts.

[newhoggy]

This unmerged PR modifies cardano-addresses to work with both aeson-1 and aeson-2: IntersectMBO/cardano-addresses#182

@hamishmack is looking in to some nix/ghcjs issues with aeson-2.

plutus-apps depends on cardano-addresses, so the intention is that plutus-apps be able to update to this once its merged and do some extra work to upgrade to aeson-2.

[catch-21]

@Jimbo4350 some points to consider:

CIP-0031 Reference Inputs

• Plutus correctly observes everything available in an Alonzo txout (created pre-Vasil): value, tokens, datum hash.
• Try referencing same input multiple times for single transaction (no duplicates should arise in TxInfo)
• Try referencing spent outputs
• Try referencing an output that is also a regular input of the same transaction (is there conflict and does cli option order affect the outcome). I expect no conflict and TxInfo should have the txo as both both a regular and reference input.
• Confirm that the spending conditions on referenced outputs are not checked

CIP-0032 Inline datums (quotes are from cip spec)

• Try attaching datum that is not valid or well-formed script data
• Try referencing two outputs that both hold the exact same datum (TxInfo should behave correctly)
• Is there a way to break CLI displaying large attached datum (try multiple utxos with large or deeply nested json)
• Confirm that attached BS datum and datum hash are distinctly different enough to not fool a cli output parser
• Prove that "Scripts with old versions cannot be spent in transactions that include inline datums, attempting to do so will be a phase 1 transaction validation failure."
• Datum witnessing requirements cannot be satisfied with reference inputs. Outputs with hashes must have datum included in transaction body as witness. We should prove that:
  • "when an output with an inline datum is spent, the spending transaction does not need to provide the datum itself."
  • a reference input with datum requires no witness, and so it should only be visible in TxOut and not txInfoData map.

CIP-0033 Reference Scripts

• Confirm that reference scripts are only run if needed (e.g. if spending from its script address)
• Confirm that reference scripts are not run when not needed (e.g. if not spending from correct script addres)
• Inspect or read a script stored onchain using node-cli (unconfirmed functionality)
• Produce a valid transaction with both a reference script and datum at same utxo input
• Prove that fee and collateral are cheaper when using a reference script
• Mix of attached and reference scripts in a single valid transaction
• Try attaching and referencing the same script in single valid transaction. Should run validation twice for each input? Should run validation only once. Check that txOutReferenceScript is correct.
• Try referencing and attaching different scripts in a single transaction and prove correct output if only one fails or if both pass
• Try attaching and referencing a pre-Vasil (V1) script - should fail phase1 validation only when script executes
• Try attaching and referencing something that is not a script or is not well-formed

Return Collateral

• Is always optional to incude in transaction, even when script is invoked
• Ada-only collateral has been dropped when collateral return is provided
• Ada-only for collateral input remains when collateral return is omitted
• When collateral return is included and input collateral equals total collateral then the minUtxo constraint shouldn't fail like [BUG] - transaction build attempts to create UTxO with 0 lovelace as change #3041.

Redeemers in TxInfo

• Ensure redeemers for a mix of spending/minting/withdrawal/certifying scripts in transaction are visible in txInfoRedeemers

[michaelpj]

Should run validation twice for each input?

No, should only do it once.

[dorin100]

@CarlosLopezDeLara should we close this ticket now?

[Jimbo4350]

I'm closing this because:

• It's not possible to cover every combination
• We have already hardforked on mainnet therefore we were satisfied with the test coverage