-
Notifications
You must be signed in to change notification settings - Fork 404
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
Add customizable WasmLimits #1989
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1989 +/- ##
==========================================
+ Coverage 48.82% 48.88% +0.05%
==========================================
Files 65 65
Lines 10082 10101 +19
==========================================
+ Hits 4923 4938 +15
- Misses 4725 4727 +2
- Partials 434 436 +2
|
a80f083
to
aaad097
Compare
obviously not mergeable yet, but would love some feedback from you @pinosu |
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.
Nice work!
I'm still thinking if it's best to have the wasmLimits in wasmConfig or add a new paramenter to the NewKeeper func . I guess we need to think about the scope of the two things and if they can match or just have similar names.
// QueryWasmLimitsConfigResponse is the response type for the | ||
// Query/WasmLimitsConfig RPC method. It contains the JSON encoded limits for | ||
// static validation of Wasm files. | ||
message QueryWasmLimitsConfigResponse { string config = 1; } |
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.
Do we have a specific struct that we can define for config or we want to keep it flexible?
In that case, we could evaluate using bytes instead of string. WDYT?
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.
As mentioned in our chat, I want to keep it flexible. The reason for string instead of bytes is that I want to make it easy for contract devs to copy and paste the limits. They need pass them into cosmwasm-check. See here: https://github.com/CosmWasm/cosmwasm/blob/cf413c5ad6a58a87e0be894584f01506f3b2e0af/packages/check/src/main.rs#L41-L50
@@ -315,8 +315,14 @@ func NewWasmCoins(cosmosCoins sdk.Coins) (wasmCoins []wasmvmtypes.Coin) { | |||
return wasmCoins | |||
} | |||
|
|||
// WasmConfig is the extra config required for wasm | |||
type WasmConfig struct { | |||
// VMConfig contains configurations that are passed on to CosmWasm VM. |
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.
Nice!
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.
Great work!
Should we also define DefaultVMConfig()
, with the limits set o some reasonable default value?
This is handled in cosmwasm-vm because I want to avoid chain developers forgetting to set one of the values to the default. That's why the values all use pointers. If you pass a |
630bde9
to
b03f430
Compare
b03f430
to
930241d
Compare
I rebased this on main, removing the commit with the |
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.
Great work! LGTM 👍
closes #1986