cardano-serialization-lib ExUnits

Question

I am new to Cardano and Plutus.

I was trying to build a transaction that redeems a UTxO from the alwayssucceeds contract on Cardano Testnet.

The Redeemer object constructor takes ExUnits as one of the parameters and I used values from Ex Budget part of output of the cabal run plutus-alwayssucceeds -- 42 alwayssucceeds.plutus , but when I try to submit the transaction I get an error that the machine terminated due to overspending the budget.

I was wondering where I could get the correct values for ExUnits, if not from cabal run? It might not be a big problem for the alwayssucceeds contract, but I will have to know the correct values for whatever contracts I will write for my own projects...

Here is how I create the Redeemer:

let redeemer = CardanoWasm.Redeemer.new(
                CardanoWasm.RedeemerTag.new_spend(),
                CardanoWasm.BigNum.from_str("0"),
                datum,
                CardanoWasm.ExUnits.new(
                    CardanoWasm.BigNum.from_str("1100"), //memory
                    CardanoWasm.BigNum.from_str("297830") //steps
                )
            );

And here is the error I get:

transaction submit error ShelleyTxValidationError ShelleyBasedEraBabbage 
(ApplyTxError 
    [UtxowFailure (UtxoFailure 
        (FromAlonzoUtxoFail 
            (UtxosFailure 
            (ValidationTagMismatch 
                (IsValid True) 
                (FailedUnexpectedly 
                     (PlutusFailure "\nThe 3 arg plutus script 
                         (PlutusScript PlutusV1 ScriptHash \"67f33146617a5e61936081db3b2117cbf59bd2123748f58ac9678656\") fails.\n
CekError An error has occurred:  User error:\n
The machine terminated part way through evaluation due to overspending the budget.\n
The budget when the machine terminated was:\n({ cpu: -47270\n| mem: -500\n})\n
Negative numbers indicate the overspent budget; note that this only indicatessthe budget that was needed for the next step, not to run the program to completion.\n
The protocol version is: ProtVer {pvMajor = 7, pvMinor = 0}\n
The data is: I 42\n
The redeemer is: I 42\n
The context is:\n
    Purpose: Spending 
    (TxOutRef {txOutRefId = 202acb00198b4ff05420110addd32e7cabb39d67694152d46356cee2f9454455, txOutRefIdx = 0})\n
    TxInfo:\n  TxId: 950e298860961fab043e7a24e7199bfa07fe37b81874776786c99a4612d37c7a\n  
    Inputs: [ 202acb00198b4ff05420110addd32e7cabb39d67694152d46356cee2f9454455!0 -> - Value (Map [(,Map [(\"\",3000000)])]) addressed to\n ScriptCredential: 67f33146617a5e61936081db3b2117cbf59bd2123748f58ac9678656 (no staking credential) ]\n  
    Outputs: [ - Value (Map [(,Map [(\"\",2821081)])]) addressed to\nPubKeyCredential: 64356374321e2e70dcce03e074e7c8beadfbc3ee0f27a22a9c8fc611 (StakingHash PubKeyCredential: a94f395e81e6b4405ed4bb6e7e8bce939d055b036b5de81b94235d9d) ]\n  
    Fee: Value (Map [(,Map [(\"\",178919)])])\n  
    Value minted: Value (Map [])\n  
    DCerts: []\n  
    Wdrl: []\n  
    Valid range: (-\8734 , +\8734)\n  
    Signatories: []\n  
    Datums: [ ( 9e1199a988ba72ffd6e9c269cadb3b53b5f360ff99f112d9b2ee30c4d74ad88b\n          , 42 ) ]\n" "hgCYphoAAyNhGQMsAQEZA+gZAjsAARkD6BlecQQBGQPoGCAaAAHKdhko6wQZWdgYZBlZ2BhkGVnYGGQZWdgYZBlZ2BhkGVnYGGQYZBhkGVnYGGQZTFEYIBoAAqz6GCAZtVEEGgADYxUZAf8AARoAAVw1GCAaAAeXdRk29AQCGgAC/5QaAAbqeBjcAAEBGQPoGW/2BAIaAAO9CBoAA07FGD4BGgAQLg8ZMSoBGgADLoAZAaUBGgAC2ngZA+gZzwYBGgABOjQYIBmo8RggGQPoGCAaAAE6rAEZ4UMEGQPoChoAAwIZGJwBGgADAhkYnAEaAAMgfBkB2QEaAAMwABkB/wEZzPMYIBn9QBggGf/VGCAZWB4YIBlAsxggGgABKt8YIBoAAv+UGgAG6ngY3AABARoAAQ+SGS2nAAEZ6rsYIBoAAv+UGgAG6ngY3AABARoAAv+UGgAG6ngY3AABARoADFBOGXcSBBoAHWr2GgABQlsEGgAEDGYABAAaAAFPqxggGgADI2EZAywBARmg3hggGgADPXYYIBl59BggGX+4GCAZqV0YIBl99xggGZWqGCAaAJBjuRkD/QqCGQZAGgAFRAxOTQEAADMiIiAFEgASABGfGCoYKth5n9h5n5/YeZ/YeZ/YeZ9YICAqywAZi0/wVCARCt3TLnyrs51naUFS1GNWzuL5RURV/wD/2Hmf2Hmf2HqfWBxn8zFGYXpeYZNggds7IRfL9ZvSEjdI9YrJZ4ZW/9h6gP+hQKFAGgAtxsDYeZ9YIJ4RmamIunL/1unCacrbO1O182D/mfES2bLuMMTXStiL/////5/YeZ/YeZ/YeZ9YHGQ1Y3QyHi5w3M4D4HTnyL6t+8PuDyeiKpyPxhH/2Hmf2Hmf2HmfWBypTzlegea0QF7Uu25+i86TnQVbA2td6BuUI12d/////6FAoUAaACsL2dh6gP//oUChQBoAArrnoUChQACAgNh5n9h5n9h5gNh6gP/YeZ/Ye4DYeoD//4Cf2HmfWCCeEZmpiLpy/9bpwmnK2ztTtfNg/5nxEtmy7jDE10rYixgq///YeZ9YIJUOKYhglh+rBD56JOcZm/oH/je4GHR3Z4bJmkYS03x6///Yep/YeZ/YeZ9YICAqywAZi0/wVCARCt3TLnyrs51naUFS1GNWzuL5RURV/wD/////ggcA" :| []))))))])```

Answer 1

These two are the maximum computation resources you're declaring your contract needs. I believe the easiest way to get the "right" value, is to interact with your contract on testnet in various ways, and get a ballpark of those two values.

For these initial interactions, you can use cardano-cli transaction build which doesn't require them, and then either use cardanoscan.io to see the consumed resources, or even look inside the CBOR of your transaction file to find them (the latter doesn't require you to submit the transaction).

What you put for these two values doesn't affect the transaction fees much, they are just a pair of numbers in your transaction CBOR. So you'd probably be able to use a pair of larger numbers (maybe even an order of magnitude larger) to construct your transactions.

Answer 2

I am using much higher ExUnits for my redeemer and it works just fine.

Redeemer.new(
    RedeemerTag.new_spend(),
    BigNum.from_str('0'),
    PlutusData.new_constr_plutus_data(
        ConstrPlutusData.new(
            BigNum.from_str('1'),
            datum
          )
        ),
    ExUnits.new(
      BigNum.from_str("7000000"),
      BigNum.from_str("3000000000")
    )
);

Source: dApp Wallet Connector Example