#2322 introduces checking note consumption checking. However as #2322 (comment) indicates, its not possible to tell a specific note's cycle count if it fails.
The only (currently) possible cycle estimation is to execute a note in isolation. Unfortunately this is also an estimation, since execution can vary based on the account's state. Meaning different runs can result in different cycle counts.
There are two use cases for having cycle count estimations:
- Evicting notes which exceed the capacity of a transaction.
- Packing as many notes as possible.
(1) is the initial priority, but it may be worth considering what we can do for (2).
For (1) it seems reasonable to:
- Every time a note fails consumption,
- execute it in isolation and
- use that cycle estimate to evict a note, or mark it as defective
This is reasonable because execution is (relatively) cheap.
For (2) it makes sense to me to have a library of note estimations i.e. an estimate per note script root. Many notes would be static, or at least have a static upper bound, or are standard notes which are known "constants".
Perhaps the note checker could emit cycle counts for every successful note (cc @PhilippGackstatter)? And these could be updated in the database on every transaction. Each account then pulls notes until these estimates sum to the transaction capacity (or maybe a little more?).
Though thinking on this more, is this any better than just taking the max notes and stuffing it in? Perhaps some compute can be saved by limiting it more accurately, but since these are all estimates that vary, perhaps this isn't worth it.
#2322 introduces checking note consumption checking. However as #2322 (comment) indicates, its not possible to tell a specific note's cycle count if it fails.
The only (currently) possible cycle estimation is to execute a note in isolation. Unfortunately this is also an estimation, since execution can vary based on the account's state. Meaning different runs can result in different cycle counts.
There are two use cases for having cycle count estimations:
(1) is the initial priority, but it may be worth considering what we can do for (2).
For (1) it seems reasonable to:
This is reasonable because execution is (relatively) cheap.
For (2) it makes sense to me to have a library of note estimations i.e. an estimate per note script root. Many notes would be static, or at least have a static upper bound, or are standard notes which are known "constants".
Perhaps the note checker could emit cycle counts for every successful note (cc @PhilippGackstatter)? And these could be updated in the database on every transaction. Each account then pulls notes until these estimates sum to the transaction capacity (or maybe a little more?).
Though thinking on this more, is this any better than just taking the max notes and stuffing it in? Perhaps some compute can be saved by limiting it more accurately, but since these are all estimates that vary, perhaps this isn't worth it.