Open VKFisher opened 2 years ago
The error you're seeing is not a Plutus error, it's a ledger phase-1 error, and will result in the script not even running. The error occurs because you have 6 collateral inputs where you're only allowed to have a maximum of 5.
My guess is that this is an issue in the balancing code. Probably the switch from foldr to
foldl` increases the computed costs such that the system needs extra collateral, and it hasn't been coded to bound the number of inputs at 5.
Try making sure you have larger inputs available to use as collateral, perhaps by consolidating some inputs.
@nc6
Here's the transaction before balancing, with a single input.
Tx:
Tx f0199c14819d959db8cd8aa80a80855bd4c8a29dc36d1e92d267eed9ce6fee26:
{inputs:
- 29828087b51af5d4fc54c1beb568cd95935dcea5e07dbbbeb323b63c9bf88009!1
45000
collateral inputs:
outputs:
mint: Value (Map [])
fee: Value (Map [])
mps:
signatures:
validity range: Interval {ivFrom = LowerBound NegInf True, ivTo = UpperBound PosInf True}
data:}
Requires signatures:
Utxo index:
( 29828087b51af5d4fc54c1beb568cd95935dcea5e07dbbbeb323b63c9bf88009!1
, - Value (Map [(,Map [("",10000000)])]) addressed to
ScriptCredential: 4f27b58b078a333f5a907075743c6e55af456f347e13fea47fc602e9 (no staking credential) )
Validity range:
(-∞ , +∞)
Here's that same transaction after balancing. There are six collateral inputs with the identifier ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958
which is different from the original input and doesn't appear anywhere in the initial transaction.
Tx 04730ff5bfcb7c108ddf8d3d6e1e78c5a910c597e768c94194ac6ee6915fa6d9:
{inputs:
- 29828087b51af5d4fc54c1beb568cd95935dcea5e07dbbbeb323b63c9bf88009!1
45000
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!20
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!21
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!22
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!23
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!24
collateral inputs:
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!20
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!21
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!22
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!23
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!24
- ef0ca0fb043642529818003be5a6cac88aac499e4f8f1cbc3bdb35db2b7f6958!25
outputs:
- Value (Map [(,Map [("",8988447)])]) addressed to
PubKeyCredential: 80a4f45b56b88d1139da23bc4c3c75ec6d32943c087f250b86193ca7 (no staking credential)
mint: Value (Map [])
fee: Value (Map [(,Map [("",51011553)])])
mps:
signatures:
validity range: Interval {ivFrom = LowerBound NegInf True, ivTo = UpperBound PosInf True}
data:}
I'm assuming that all the inputs were produced by the emulator. Since I didn't specify any of these, I'm not sure how to go about consolidating them. Are you saying I should make an unbalanced transaction and then modify it?
Summary
When testing a contract I ran into an issue where transaction validation fails with the following error:
After investigation it appears that the issue is caused by computations that generate a lot of thunks during evaluation. I've reproduced the issue in this minimal example:
The relevant part is the use of
foldl
in thevalidateSpend
function. If it is replaced withfoldr
, the validation passes successfully. This is not an OOM issue, since an identical computation runs fine off-chain. 50000 is not an outrageous amount, either.Plutus Core is supposed to be strict, but it seems like its emulation is affected by laziness here.
Steps to reproduce the behavior
Run the following test
OR paste the contract code into playground and simulate the transaction from the test
Actual Result
Transaction validation fails with the following error:
Expected Result
Transaction validates successfully
Describe the approach you would take to fix this
No response
System info
OS: Ubuntu 20.04 Plutus: v2022-04-06