Fee probing

[gabrielhdt]

Symptoms

The fee available in the context of validation is not always the fee applied on the transaction.

Reproduce

To see this bug, you need a validator whose behaviour depends on the fee.

For an example, see the tests at

cooked-validators/tests/Cooked/Behaviour/Elementary.hs

Line 353 in cb24ef3

testGroup

where the validator checkFeeBetween succeeds if the fee is in some given range.

• the test case "3 Ada is the upper bound" shows that if the upper bound is lower than 3A, the validator fails. So the fee is greater or equal to 3A
• the test case "350 000 Lovelaces is the lower bound" shows that if the lower bound is greater than 350 000 Lovelaces, the validator fails. Therefore the fee is lower or equal to 350k Lovelaces.

Are there several fees? Some explanations later on.

Expected behaviour

One should be able to reduce that range to a single value, the value of the fee itself, which is supposed to be deterministic and unique per transaction.

Some explanations

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:

1. set the fee to some arbitrary value $f_0$
2. run the validator using that value and evaluate the cost of running the validator(s)
3. 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$.

From our tests, we can deduce that $f_0$ is either close to 3Ada and the final fee is close to 350,000 Lovelaces (so the fee decreases through iterations of the algorithm); or $f_0$ is close to 350,000 Lovelaces and the final fee is close to 3 Ada, which is less probable since the transaction is a light one.

Environment
Cooked v2