3

As a newbie in Plutus and Haskell, I write code by printing/logging variables to see their value, which is the only reason why I managed to write Contract, off-chain Plutus part. My question is, are there any possible ways (even hacky ones, doesn't matter), to inspect variable value in on-chain, validator Plutus part.

I am aware of trace, traceIfFalse, etc. All of the functions can be found here: https://playground.plutus.iohkdev.io/doc/haddock/plutus-tx/html/PlutusTx-Trace.html But it doesn't help, as you can't inspect variables.

This enhancement seems to be dead: https://github.com/input-output-hk/plutus/issues/3164 Searched a lot of sources and found nothing useful. I am aware why it's difficult (BuiltInString, absence of Show), only asking for possible solutions/tricks/hacks and not for explanation why it's impossible.

This question is related: Logging in validator

Thanks

EDIT:

let's image I have a validator:

mkValidator :: Order -> Order -> OrderAction -> ScriptContext -> Bool
mkValidator o oDatum act ctx = True

how can I print the value of for example ctx (ScriptContext), or oDatum, then executing the whole script with Emulator, so that whole script compiles and I can see ctx Value somewhere in EmulatorTrace (or any other way)?

I mean something like this:

mkValidator o oDatum act ctx = trace "test" ctx && True
2
  • Why is impossible to inspect variables with trace? Could you include specific examples of what you're trying to do? Nov 20, 2021 at 22:28
  • let's image I have a validator: mkValidator :: Order -> Order -> OrderAction -> ScriptContext -> Bool mkValidator o oDatum act ctx = True. how can I print the value of for example ctx (ScriptContext), or oDatum, then executing the whole script with Emulator, so that whole script compiles and I can see ctx Value somewhere in EmulatorTrace? I mean something like this: mkValidator o oDatum act ctx = trace "test" ctx && True
    – serx
    Nov 21, 2021 at 10:26

2 Answers 2

2

I could not find a way to work around this yet. Validation is a side effect free function (a pure function) so it can't write to any log.

What I do is create a debug endpoint in my contract log info there

So I will have something like this

debug :: AsContractError e => () -> Contract w Schema e ()
debug _ = do
        utxos <- utxosAt address
        Contract.logInfo @String $ show utxos
        Contract.logInfo @String $ show (length utxos)
        wallet1Utxos <- utxosAt . walletAddress $ knownWallet 2
        Contract.logInfo @String $ show wallet1Utxos
        wallet2Utxos <- utxosAt . walletAddress $ knownWallet 1
        Contract.logInfo @String $ "Utxos for wallet 2: " ++ show wallet2Utxos

And then use that in a EmulatorTrace()

mintAndTransfer :: EmulatorTrace ()
mintAndTransfer = do
        let tn = "USDC"
        h1 <- activateContractWallet (knownWallet 1) (endpoints @ContractError)
        callEndpoint @"mint" h1 $ MintParams
                { mintParamsTokenName = tn
                , mintParamsAmount = 100 }
        void $ waitNSlots 1
        callEndpoint @"mint" h1 $ MintParams
                { mintParamsTokenName = tn
                , mintParamsAmount = 200 }
        void $ waitNSlots 1
        callEndpoint @"transferToWallet" h1 $ TransferToWalletParams
                { tpTo = walletPubKeyHash $ knownWallet 2
                , tpAmount = 50
                , tpTokenName = tn }
        void $ waitNSlots 1
        callEndpoint @"debug" h1 ()
        void $ waitNSlots 1

Not ideal I know but it helps sometime.

2

There is a recent update regarding the error message from validator onchain here https://github.com/input-output-hk/cardano-node/releases If you update your cardano-node to version 1.31.0, you will be able to see log message from traceIfFalse. Something like

The provided Plutus code called 'error'.
Script debugging logs: UTxO not consumed

Like @Calin answered, you can always run any test with the Emulator Trace, which gives you where it fails onchain.

2
  • 1
    It is still just a pre-prepared string logging, not variable logging though
    – serx
    Nov 25, 2021 at 7:32
  • 1
    Yes, that's right, but at least it gets improved and now while testing on testnet/mainnet we at least know which condition doesn't meet. Nov 25, 2021 at 19:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.