Conditional CU metering #1
Conversation
tao-stones
force-pushed
the
conditional-cu-charging
branch
from
a3ee270 to
55e4924
Compare
| let execution_cu = match transaction.execution_results { | ||
| Ok(_) || Err(TransactionError::CustomError(_)) => committed_tx.executed_cu, | ||
| _ => transaction.requested_cu, | ||
| }; |
There was a problem hiding this comment.
Not too familiar with InstructionError, wondering if correct to use Requested_cu for any error but TransactionError::CustomError(_)
There was a problem hiding this comment.
This is the most important part to get right. In Agave's VM, I think it's
EbpfError::DivideByZero
EbpfError::DivideOverflow
EbpfError::CallOutsideTextSegment
EbpfError::InvalidInstruction
EbpfError::InvalidVirtualAddress
I'm not sure exactly what these translate to as TransactionErrors though.
In firedancer, it's maybe something like
#define FD_VM_ERR_SIGSPLIT ( -9) /* split multiword instruction (e.g. jump into the middle of a multiword instruction) */
#define FD_VM_ERR_SIGILL (-12) /* illegal instruction (e.g. opcode is not valid) */
#define FD_VM_ERR_SIGSEGV (-13) /* illegal memory address (e.g. read/write to an address not backed by any memory) */
#define FD_VM_ERR_SIGBUS (-14) /* misaligned memory address (e.g. read/write to an address with inappropriate alignment) */
#define FD_VM_ERR_SIGRDONLY (-15) /* illegal write (e.g. write to a read only address) */
#define FD_VM_ERR_SIGFPE (-18) /* divide by zero */
There was a problem hiding this comment.
indeed, what about AccessViolation in agave's VM, should it also be considered as "irregular failure"?
I failed to find where EbpfError converted to InstructionError, there are some casting at bpf_loader, is it the right place to look at @Lichtso ?
There was a problem hiding this comment.
| let execution_cu = match transaction.execution_results { | ||
| Ok(_) || Err(TransactionError::CustomError(_)) => committed_tx.executed_cu, | ||
| _ => transaction.requested_cu, | ||
| }; |
There was a problem hiding this comment.
This is the most important part to get right. In Agave's VM, I think it's
EbpfError::DivideByZero
EbpfError::DivideOverflow
EbpfError::CallOutsideTextSegment
EbpfError::InvalidInstruction
EbpfError::InvalidVirtualAddress
I'm not sure exactly what these translate to as TransactionErrors though.
In firedancer, it's maybe something like
#define FD_VM_ERR_SIGSPLIT ( -9) /* split multiword instruction (e.g. jump into the middle of a multiword instruction) */
#define FD_VM_ERR_SIGILL (-12) /* illegal instruction (e.g. opcode is not valid) */
#define FD_VM_ERR_SIGSEGV (-13) /* illegal memory address (e.g. read/write to an address not backed by any memory) */
#define FD_VM_ERR_SIGBUS (-14) /* misaligned memory address (e.g. read/write to an address with inappropriate alignment) */
#define FD_VM_ERR_SIGRDONLY (-15) /* illegal write (e.g. write to a read only address) */
#define FD_VM_ERR_SIGFPE (-18) /* divide by zero */
Co-authored-by: Philip Taffet <[email protected]>
| Ok(_) || Err(TransactionError::CustomError(_)) => committed_tx.executed_cu, | ||
| _ => transaction.requested_cu, | ||
| }; | ||
| ... ... |
There was a problem hiding this comment.
alternatively, instead of charging different CUs based on TransactionError at call sites, we could make VM to consume CUs differently - deplete CU meter in case of "irregular failure"; so the call sites (banking stage or replay) don't need to change. I thought this is what @Lichtso implied somewhere.
Co-authored-by: Justin Starry <[email protected]>
Co-authored-by: Justin Starry <[email protected]>
… VM error as "less common"
No description provided.