When a UTXO is produced, it is locked to an address, i.e., the hash of a script, not the script itself. When a transaction spends it, does the tx have to provide the script in its input? There are conflicting answers here/no, here/yes, and here/yes. Can someone please give a definite answer? I believe the answer should be yes, otherwise a validator cannot run the script and verifies it evaluates to true. However, I can't find it in the tx input.
1 Answer
The definite answer is the following...
Any transaction that consumes an unspent output has to provide a witness that proofs that the transaction is allowed to spend that output.
What this witness is, depends on the address that locks the output, as you indicated. The output could be locked by a simple public key that requires the signature of the associated private key. Or it could be a plutus script that locks these funds. In both cases, a witness needs to be provided.
For a script address, a witness consists of multiple things. The first is of course the script itself; otherwise, no validator could run the validity check of the transaction. Moreover, each unspent output at such an address also needs a redeemer to be added. Together with the already available datum at the output and the context of the transaction, a validator can now check if the spending of that output was valid.
Now, where are these things located from the perspective of a validator? If we take a look at the TxInfo in the ScriptContext we see the txInfoInputs as a list of TxInInfo. These are the unspent outputs that we are trying to spend in the transaction that is currently run. Then, if we scope further in on the txInInfoResolved we get a TxOut that captures the address, the value and maybe the presence of a datum. It could also be locked by a public key that does not need a datum, that the reason for maybe a datum.
Now to check how these outputs are locked we can futher scope in on the the Address type. We see that this consists of a credential and maybe a staking key (not all addresses have staking). If we again scope in on the Credential type, it is either a public key hash or a script hash.
We see that a validator can deduce by hashing the script if there are any outputs available that are associated with that witness. Additionally, in the TxInfo there is the txInfoRedeemers which captures the redeemers and the outputs that they are a witness of.
