You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would address many of the points raised in #202 and also be a cleaner solution than fully removing checks as in #809
Using a var for these values will allow a chain importing wasmd (or compiling a custom version) to easily override the values compile time. It will not allow a param change proposal to fix it, but any chain upgrade could update these values as well, so it does make them somewhat dynamic (or at least adjustable by governance without forking wasmd).
This should be a minimally intrusive change that will remove a number of headaches for integrations.
The text was updated successfully, but these errors were encountered:
With the gas register interface and extension point, custom values or logic can be integrated easily. Switching to vars for them with compiler flags may cause more confusion as we have 2 ways now to set values.
MaxWasmSize and MaxLabelSize are a different story though. They are not customizable for chains, currently. Either we make them both vars or use a custom ante handler that can read from params.
The ante handler would be a cleaner solution for me as it removes duplication but adds on gas cost or requires caching.
Wondering if there is a use case for custom MaxLabelSize 🤷
Great. If it is just those two left to do, let's make them vars and document that can call this done.
I don't see the need to customize MaxLabelSize, but someone will surely come up with one. If we just make it var and keep the same default, it should be fine.
This would address many of the points raised in #202 and also be a cleaner solution than fully removing checks as in #809
Using a var for these values will allow a chain importing wasmd (or compiling a custom version) to easily override the values compile time. It will not allow a param change proposal to fix it, but any chain upgrade could update these values as well, so it does make them somewhat dynamic (or at least adjustable by governance without forking wasmd).
This should be a minimally intrusive change that will remove a number of headaches for integrations.
The text was updated successfully, but these errors were encountered: