New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Algod: Simulation run with extra budget per transaction group #5354
Conversation
99d7671
to
b0bf410
Compare
97b6336
to
95f1594
Compare
Codecov Report
@@ Coverage Diff @@
## master #5354 +/- ##
==========================================
- Coverage 55.26% 52.49% -2.77%
==========================================
Files 454 454
Lines 63722 63746 +24
==========================================
- Hits 35213 33462 -1751
- Misses 26113 27762 +1649
- Partials 2396 2522 +126
... and 114 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good and has nice tests. I do have some design-level questions/thoughts though:
- This PR adds an additional flat amount of app call budget to a group. One alternative model I can think of is changing the budget per app call, i.e. changing
Proto.MaxAppProgramCost
. Do we prefer one of these approaches to the other? - We should consider some limit on the maximum additional app call budget that we allow. As a starting point, I'll suggest 20,000 * 16, since that's the maximum amount of logicsig budget you can use today.
- It might be nice to have the additional budget parameter be a signed integer, so you could artificially limit the runtime budget of an app. I think that would be hard to achieve with our REST API code generator though.
I agree with this part, that having a negative budget would be interesting, if we want to push smart contract simulation to an extreme (with rather limited budget). It is indeed not quite feasible to do under codegen at this point, for I attempted to specify type to be |
The thing I'm a bit unsure is that, the error handling for too high simulation extra budget is happening in |
daemon/algod/api/algod.oas2.json
Outdated
"extra-app-budget": { | ||
"description": "The extra budget added for each app call during each transaction group simulation", | ||
"type": "integer", | ||
"x-algorand-format": "uint64" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we use x-algorand-format
here, but not above? (in the request)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a bit research here, saw https://github.com/algorand/generator/blob/e5add2d3096bba45d51e44cdd9e9725427e02208/src/main/java/com/algorand/sdkutils/generators/OpenApiParser.java#L131 and algorand/java-algorand-sdk#183 (comment), I think this x-algorand-format
should be deleted, for it has only things to do with sdk codegen, and we don't have to specify the integer type again.
ledger/simulation/tracer.go
Outdated
@@ -140,6 +140,12 @@ func (tracer *evalTracer) BeforeTxnGroup(ep *logic.EvalParams) { | |||
tracer.result.TxnGroups[0].AppBudgetAdded = uint64(*ep.PooledApplicationBudget) | |||
} | |||
|
|||
// Override transaction group budget if specified in request, retrieve from tracer.result | |||
if tracer.result.EvalOverrides.ExtraAppBudget != nil && ep.PooledApplicationBudget != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm only now realizing this allows extra budget in apps but not logicsigs. Do we want that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be interesting, but not very commonly used I guess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may want that at some point, but I see no reason to attempt to also achieve that now.
And since logicsig budget is not pooled among a group, I suspect we'd want to increase each program's budget to get that feature to work, which isn't really compatible with the scheme here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that with this PR as it is now, one could, in a simulated transaction group, create an wrapper app that incorporates the logicsig code, then call into it that app, with elevated opcode budget? i.e. there's nothing a logicsig can do that an app can't do.
1069eee
to
33d910f
Compare
33d910f
to
be8d6cb
Compare
9d87e9d
to
d305f96
Compare
d305f96
to
3563c28
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor comments
Summary
This PR allows for simulating a txn group with extra budget by specifying additional budget through
SimulateRequest
.Test Plan
The test splits into follow 3 parts:
All tests are testing an app using more than 700 (or 1400) budget.
The logic in both endpoint and simulator should be tested.