Although there may have been changes, this remains a valid question.
The code shown in the question is the boilerplate code that accompanies a validator implementation for on-chain execution. A simple validator implementation can be seen below. It is the recent 42 redeemer validator code of Pioneer (before switch from Data
to BuildinData
).
-- This is the validator implementation
-- It must be inlinable so it can be compiled into Plutus code
{-# INLINABLE mkValidator #-}
mkValidator :: Data -> Data -> Data -> ()
mkValidator _ r _
| r == I 42 = ()
| otherwise = traceError "wrong redeemer"
-- boilerplate: compiles validator to Plutus code
validator :: Validator
validator = mkValidatorScript $$(PlutusTx.compile [|| mkValidator ||])
-- boilerplate: get the hash of the validator script
valHash :: Ledger.ValidatorHash
valHash = Scripts.validatorHash validator
-- boilerplate: get the script address of the validator
scrAddress :: Ledger.Address
scrAddress = scriptAddress validator
The first code block is the validator implementation in Haskell, here named mkValidator
.
The actual question refers to the next three code blocks marked as boilerplate.
validator
inlines the mkValidator
implementation and compiles it to Plutus code. This is necessary so the validator can be executed on-chain.
valHash
and scrAddress
are auxiliary functions that return hash and address of the the validator script.
One can see them used in the off-chain code to construct the transactions.
The reason for this roundabout way of implementing the validator is to enable code sharing between on-chain and off-chain executed code.
More complex validator implementations will result in a more complex Plutus code compiler code block, but the principle remains the same.