transaction build no longer checks datum for PlutusV1 and PlutusV2 spending scripts

[mkoura]

Description

With integration of CIP-69, the datum is optional for PlutusV3 spending scripts. However datum is still required for PlutusV1 and PlutusV2 spending scripts.

The transaction build command used to check datum, and failed to build a tx when datum was missing on the txin ("txin does not have a script datum") or when the provided datum was wrong ("The Plutus script witness has the wrong datum (according to the UTxO).").
Now the transaction build doesn't check the datum provided for PlutusV1 and PlutusV2 scripts.

Submitting the tx still fails as expected.

Steps to Reproduce

1. Try do build a Tx that contains a spending PlutusV1 or PlutusV2 script, while providing wrong datum, or no datum on the "locked" txin.
2. Observe that transaction build builds the transaction without reporting an error.

Additional Context

cardano-cli 8.24.0.0 - linux-x86_64 - ghc-8.10
git rev ae8bc933ee6b6366c04854c1e127fd8dfb29b556

cardano-node 8.12.0 - linux-x86_64 - ghc-8.10
git rev ae8bc933ee6b6366c04854c1e127fd8dfb29b556

[mkoura]

The error ultimately comes from evalTxExUnitsWithLogs which lives in the cardano-ledger, so I'm moving it there.

[mkoura]

Response from @lehins on Slack:

the purpose of the evalTxExUnitsWithLogs function is to estimate the ExUnits, not validate the transaction. There are plenty of other things that can be wrong with such transaction that we don't report in that function

Therefore I'm moving it back to cardano-cli.

[lehins]

@mkoura As we've discussed in the meeting: it seems like a desired feature in the cardano-api and the easiest way to bring it back IMHO will be by using ledger functionality, so I'll try and see what can we do in order to bring it back evalTxExUnitsWithLogs. I'll keep you posted on this ticket.

[CarlosLopezDeLara]

@mkoura Yes, it was intentional to relax the check for v1 anbd v2 . Making datum optional on build was the easiest way to accommodate for CIP-69, given the current structure, the alternatives would have implied growing the already convoluted build and build-raw.

We are thinking on restructuring so that we have something like:

...
--plutus-script-v2-file <FILE>
--plutus-script-v2-reference <TX-IN>
--script-purpose <PURPOSE>
( --redeemer-cbor <FILE> | --redeemer-json <FILE> | --redeemer-value <JSON_VALUE> )
( --datum-cbor <FILE>| --datum-json <FILE>| --datum-value <JSON_VALUE> | --inline-datum )
...
--plutus-script-v3-file <FILE>
--plutus-script-v3-reference <TX-IN>
--script-purpose <PURPOSE>
( --redeemer-cbor <FILE> | --redeemer-json <FILE> | --redeemer-value <JSON_VALUE>)
[ --datum-cbor <FILE>| --datum-json <FILE>| --datum-value <JSON_VALUE> | --inline-datum ]

But this is still on the drawing board.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days.