Timeline for Transaction memory and cpu usage limits
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 30, 2021 at 9:22 | history | edited | serx | CC BY-SA 4.0 |
added 119 characters in body
|
| Dec 28, 2021 at 18:11 | history | edited | serx | CC BY-SA 4.0 |
added 476 characters in body
|
| Dec 28, 2021 at 18:10 | history | became hot network question | |||
| Dec 28, 2021 at 17:12 | answer | added | Blake Brown | timeline score: 2 | |
| Dec 28, 2021 at 12:04 | comment | added | Jey | I don't think we can do anything here. It looks to me like these memory and cpu consumptions are the result of some overhead to set up script execution (load redeemer, datum, and context). It is difficult to tell. Maybe it is possible to simplify the compiled Plutus code further and reduce resource consumption. | |
| Dec 28, 2021 at 11:58 | comment | added | serx | Well it's the simplest possible script. Any further logic would additionally increase memory and CPU. From transaction building side, what else can we really do? And in general, I don't think this should be solved by optimizing individually, rather addressed by Cardano themselves, as this will be a blocker for many just a little bit more complicated use cases | |
| Dec 28, 2021 at 11:50 | comment | added | Jey | A script that always succeeds is a very special case. Optimisation this is certainly possible but I doubt if it is worthwhile. | |
| Dec 28, 2021 at 11:48 | comment | added | serx | found here: forum.cardano.org/t/max-number-of-transaction-inputs/60023/3, that each --tx-in generally uses about 38 bytes, so transaction size is not the main problem here, even though the utxo input limit is still somewhere in the hundreds for that limitation. | |
| Dec 28, 2021 at 11:36 | comment | added | serx | transaction with my script (not AlwaysSuceeds), containing 10 utxo inputs, (and some other stuff) - {exUnitsMem = 19785600, exUnitsSteps = 8451556350}, built transaction - 104553 bytes, signed - 12619 bytes | |
| Dec 28, 2021 at 11:25 | comment | added | serx | In my mind, the easiest solution for this would be to introduce some flag to allow executing validator script only once for the whole utxo input set and not for each utxo individually, as ScriptContext is aware of all of the utxos, and validation can be done in one iteration for all of them at once | |
| Dec 28, 2021 at 11:19 | comment | added | Jey | Out of curiosity, how large is the transaction-cbor, though ? | |
| Dec 28, 2021 at 11:17 | comment | added | Jey | I understand now. It is not the transaction size constraint but the memory constraint that is hit here. I read in an article on iohk.io that the needed execution memory increases with every script-UTxO. I wondered on Twitter if the memory could not be cleared after each UTxO as they are independent of each other. I got no answer though and I don't know if this a yet unused optimisation or if something else is preventing this. | |
| Dec 28, 2021 at 10:56 | comment | added | serx | I am pretty sure that it is included only once, as signed transaction size is basically the same with either 1 or 15 utxos, and raw transaction size increases dramatically with each utxo. I can't think of any possible optimizations, as this seems to be lmited by design/architecture itself.. | |
| Dec 28, 2021 at 10:39 | comment | added | Jey | You could deserialise the transaction and check how many times the script is included and how large it is. This would be interesting. I read that SundaeSwap struggled with the size of its scripts and had to do some low level optimisations. But unfortunately there are no details on this to be found. | |
| Dec 28, 2021 at 10:10 | history | asked | serx | CC BY-SA 4.0 |