[BUG] - Underestimation of Mem and Cpu units with transaction build

[logicalmechanism]

Area
Plutus Related to Plutus Scripts (Alonzo).
cardano-cli Relaated to the Cardano-CLI

Summary
Creating a smart contract transaction with cardano-cli transaction build results in an inaccurate mem and cpu estimation when using a fee-paying input UTxO that contains a token that must be returned to the change address using the --change-address. The build function builds the transaction but fails at submission with the overspending budget error.

The machine terminated part way through evaluation due to overspending the budget.

In the example smart contract I am using, when the fee paying input is:

deb0785b9b65de8872e423180c3ee9e818f90118ec80b4efa248fc205380d1e2     1        2109371692 lovelace + 5000000000 698a6ea0ca99f315034072af31eaac6ec11fe8558d3f48e9775aab9d.7444524950

The tx.draft assumes the cost is {5: [[0, 0, 121([]), [1649252, 510827641]]]} where the --calculate-plutus-script-cost parameter returns

[
  {
    "executionUnits": {
      "memory": 1678012,
      "steps": 519565179
    },
    "lovelaceCost": 134282,
    "scriptHash": "e606f584d5910a03eca95243ac489a37dcc040859b8a9b465533c215"
  }
]

The estimation using calculate-plutus-script-cost is correct but the estimation with transaction build is incorrect.

By removing the tokens from the input the transaction build calculates the correct fee and mem/cpu units.

This input lets build and --calculate-plutus-script-cost to return the same mem and cpu units.

86dd709f3740b81b3231799d4990aa526817c972c676b445514d0bbf43479dfb     1        2107202627 lovelace 

This should be reproducible with any contract.

Here is an example of the bash I used to reproduce this:

    # --calculate-plutus-script-cost ../tmp/tx.cost \
echo -e "\033[0;36m Building Tx \033[0m"
FEE=$(${cli} transaction build \
    --babbage-era \
    --out-file ../tmp/tx.draft \
    --invalid-before ${current_slot} \
    --invalid-hereafter ${final_slot} \
    --change-address ${seller_address} \
    --tx-in-collateral ${collat_tx_in} \
    --tx-in ${seller_tx_in} \
    --tx-in ${script_tx_in} \
    --spending-tx-in-reference="${script_ref_utxo}#1" \
    --spending-plutus-script-v2 \
    --spending-reference-tx-in-inline-datum-present \
    --spending-reference-tx-in-redeemer-file ../data/redeemers/remove-redeemer.json \
    --tx-out="${seller_address_out}" \
    --required-signer-hash ${seller_pkh} \
    --required-signer-hash ${collat_pkh} \
    --testnet-magic ${testnet_magic})

IFS=':' read -ra VALUE <<< "${FEE}"
IFS=' ' read -ra FEE <<< "${VALUE[1]}"
FEE=${FEE[1]}
echo -e "\033[1;32m Fee: \033[0m" $FEE
# jq -r '' ../tmp/tx.cost

Expected behavior
The cardano-cli should be able to calculate the mem and cpu correctly like it is doing with --calculate-plutus-script-cost with any fee-paying input that contains or does not contain tokens. Clearly, it can calculate it because --calculate-plutus-script-cost is correct but that information is not being put into the out-file resulting in the overspending of the budget error.

System info:
Ubuntu 22

cardano-node 8.1.1 - linux-x86_64 - ghc-8.10
git rev 6f79e5c

cardano-cli 8.1.1 - linux-x86_64 - ghc-8.10
git rev 6f79e5c

[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.

[logicalmechanism]

Any work on this in the new version of the cli?

[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.

[logicalmechanism]

Its more than a year now and this bug still exists. It was brought up IntersectMBO/cardano-api#302 but it was closed.

What else is required to get some attention on this?

[carbolymer]

@logicalmechanism thanks for the bump. Do you confirm that the bug still exists in the latest version of cardano-cli and cardano-api?

There was a related fix in the meantime: IntersectMBO/cardano-api#622 - I don't know if that fixed this.

[logicalmechanism]

Ah good catch I was using the cardano node 9.1.1.

Just confirmed that it exists in all cardano-node tagged releases before the cardano-api update to 9.3.0.0. So cardano node tag versions 9.2.0+ should work as far as I can tell from my testing but all older versions have the bug.

Pretty sure this commit fixed it.

If I run into it again, I'll make a new issue but I will close this for now assuming it is solved in cardano-api 9.3.0.0. Thanks @carbolymer