The constraints on compute power a program can consume is limited only to its instruction count #11717
Conversation
jackcmay
changed the title
jackcmay
force-pushed
the
add-compute-metering
branch
from
42f824d
to
c3b8968
Compare
Codecov Report
@@ Coverage Diff @@
## master #11717 +/- ##
=========================================
- Coverage 82.0% 82.0% -0.1%
=========================================
Files 330 330
Lines 77068 77156 +88
=========================================
+ Hits 63255 63310 +55
- Misses 13813 13846 +33 |
runtime/src/message_processor.rs
Outdated
| @@ -560,6 +589,7 @@ impl MessageProcessor { | |||
| self.programs.clone(), // get rid of clone | |||
| log_collector, | |||
| self.is_cross_program_supported, | |||
| COMPUTE_BUDGET, | |||
There was a problem hiding this comment.
I'm a little worried about how we'll deal with tweaking COMPUTE_BUDGET and MAX_INVOCATION_DEPTH in the future. These can cause diverging behavior during a rolling upgrade and changes should be triggered on some slot/epoch boundary. It'd be nice to consider how that will play out now, since technically right now COMPUTE_BUDGET is u64::MAX, and reducing might break existing programs so also needs to be triggered on some slot/epoch boundary
There was a problem hiding this comment.
Agreed, we need a way to adjust these in the future. These changes mostly mimic the current budget which isn't u64::MAX but instead 100_000 BPF instructions. The only difference for existing programs is a small cost for the logging syscalls. Programs using CPI are the ones that will see a bigger change (cost added for create_progrm_address, invoke, and charged for the cost programs they call incur. I was planning to put in the rolling update stuff later when we need it and was focused on getting these CPI caps in place first.
jackcmay
force-pushed
the
add-compute-metering
branch
from
1518cfc
to
7978eb6
Compare
…y to its instruction count (bp #11717) (#11800) * The constraints on compute power a program can consume is limited only to its instruction count (#11717) (cherry picked from commit 8d362f6) # Conflicts: # programs/bpf/Cargo.toml # programs/bpf_loader/Cargo.toml # programs/bpf_loader/src/lib.rs # programs/bpf_loader/src/syscalls.rs # runtime/src/bank.rs # sdk/src/instruction.rs * Resolve conflicts * nudge Co-authored-by: Jack May <jack@solana.com>
Problem
A program's impact on the system is constrained to a cap on the number of BPF instructions it can execute. But program may impact the system in other ways (syscalls, memory allocation, calling other programs). The current constraints are not sufficient
Summary of Changes
Introduce the bones of a compute power metering mechanism that will allow broader and customizable program execution constraints. This first cut takes into account the cost of syscalls as well as calling other programs (but allows free memory allocations from the bump allocator). It can be easily plumbed into fee collection when the time for that comes.
The proposed compute costs are best guesses based on the current limits and should be tuned and expanded in the future.
Fixes #11556