Is it possible to call the `mkValidator` inside the same / another `mkValidator` function for script composibility?

Question

Supposed I have a validator below, checking only if the output value is locked by the same script.

{-# INLINEABLE mkValidator #-}
mkValidator :: TestingParam -> TestingDatum -> TestingRedeemer -> ScriptContext -> Bool
mkValidator param _ red ctx = case red of
  (MergeScript anotherParam) -> 
    traceIfFalse "Script provided is incorrect" (valueLockedBy info (valHash anotherParam) == txOutValue ownInput)
  _ -> False
  where
    info :: TxInfo
    info = scriptContextTxInfo ctx

    ownInput :: TxOut
    ownInput = case findOwnInput ctx of
      Nothing -> traceError "input missing"
      Just i -> txInInfoResolved i

{-# INLINABLE typedValidator #-}
typedValidator :: TestingParam -> Scripts.TypedValidator TestingScript
typedValidator param =
  Scripts.mkTypedValidator @TestingScript
    ($$(PlutusTx.compile [||mkValidator||]) `PlutusTx.applyCode` PlutusTx.liftCode param)
    $$(PlutusTx.compile [||wrap||])
  where
    wrap = Scripts.wrapValidator @TestingDatum @TestingRedeemer

{-# INLINABLE validator #-}
validator :: TestingParam -> Validator
validator = Scripts.validatorScript . typedValidator

{-# INLINABLE valHash #-}
valHash :: TestingParam -> Ledger.ValidatorHash
valHash = Scripts.validatorHash . typedValidator

However, it then throws the error GHC Core to PLC plugin: E043:Error: Reference to a name which is not a local, a builtin, or an external INLINABLE function: Variable OtherScripts.Testing.ReferenceTesting.valHash.

Another similar issue with supplying minting policy here: Using `curSymbol` function in Validator script

Looked at several sources and stuck with this issue for months. Can someone advises me if it is a dead end current Plutus ability?

If so, happy to see if someone is interested in drafting a CIP for this together, since allowing to use mkValidator or mkMintingPolicy script externally allows another level of scripts composibility which I think is essential for Cardano smart contract to get into mainstream. Also, this would enable scripts to be composed more secured as validator could know the identity of other scripts they are interacting with, instead of just hardcoding-supplying a validator hash externally.

Answer 1

In this case, when compiling your validator, compiler is trying to compute a value (which is only available after successfully compiled your validator) to complete compiling your validator, thus, it's impossible case.

Your validator is parameterized validator so with each different parameter, it's different validator with different validator hash.

If you want to get outputs of the same validator with same parameter then, that's same validator with same validator hash so there is a getContinuingOutputs function you can use or findContinuingOutputs if you are only interested in amount. Also ownHash is available for getting the validator hash within the same validator.

If it's the case that you want to check an output is locked by the same validator but with different parameter, then it's no longer same validator, it's a completely different validator with different validator hash even if the source code is the same. In this case, you probably might want to provide validator hash directly to the validator via datum or redeemer rather than providing the different parameter which is not possible to compute hash from.

Answer 2

Script.validatorHash can not be compiled to Plutus Core (probably for good reason, as it would've resulted in much larger on-chain scripts).

As Erik mentioned, if you only need the hash of your current validator, ownHash is the answer. But if you want to recreate the validator hash of another script on the fly, that's not possible.

A typical solution is to provide this desired validator hash as a parameter to your current script, and therefore make it "aware" of your other script.

Answer 3

I suspect that this might actually be a GHC Template Haskell (TH) staging error. My understanding is that when you use TH in a file, it must all be expanded (TH is basically a macro expansion system) on the first TH evaluation pass.

Your function valHash calls typedValidator which includes TH functionality and then you are tying to call that within mkValidator which also uses TH. That is why I think you are actually hitting a staging error due to the implicit recursion of mkValidate -> valHash -> typeValidator -> mkValidate.

The current solution (not really that nice IMO) is to provide (ie hard code) the hash itself to mkValidate. You can probably also write a test to validate that the supplied hash is the same as the actual hash provided by TH.

Update: Apparently there is an ownHash in the Plutus libs that will give you the hash of a validator inside the same validator. I have not tried it.