Although the fee is available in the context, running validators that manipulate them has an undefined and confusing behaviour, see next section.
The problem with validators checking fees
Because the fee of a transaction is available in its context (see the datatype for contexts), one may write validators that succeed upon some condition over the fee. However, because the value of the fee depends on the complexity of the validator, the latter has to be run to compute the former. This leads to a fixpoint algorithm:
set the fee to some arbitrary value $f_0$
run the validator using that value and evaluate the cost of running the validator(s)
fix the fee to $f_1$ and re-iterate until the fee has stabilised.
Therefore, the validator is run in several contexts which differ at least by their fee value. In particular, validators are always run at least once with $f_0$ so one cannot write a validator that succeeds if and only if the transaction it is run in has fees strictly smaller than $f_0$.
What is this all about
This PR provide a test suite designed around nominal use cases of Cooked. It ought to contain
Changes
tests/Cooked/Unittests/Cooked/Behaviour.Cooked.Behaviour.Validatorscontains a collection of validators with unit datum and redeemersCooked.Behaviour.Elementarycontains some standard-ish traces.Questionable behaviours revealed so far
TxSkelRedeemerForScriptwhenTxSkelRedeemerForReferenceScriptyields the following confusing error messageThe problem with validators checking fees
Because the fee of a transaction is available in its context (see the datatype for contexts), one may write validators that succeed upon some condition over the fee. However, because the value of the fee depends on the complexity of the validator, the latter has to be run to compute the former. This leads to a fixpoint algorithm:
Therefore, the validator is run in several contexts which differ at least by their fee value. In particular, validators are always run at least once with $f_0$ so one cannot write a validator that succeeds if and only if the transaction it is run in has fees strictly smaller than $f_0$.
See issue #341.