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
Msg is json inside all cosmwasm contracts so far, and additional tooling, like cw-storage makes that implicit assumption. Without limiting in any way the message format, we can just assert this is json.RawMessage. This makes embedding and creating such a structure much easier.
Assume the message is {"approve":{}}. As is, when we create MsgExecuteContract, it will have a base64 encoded field, something like:
Which one is easier to understand, create, and debug?
If a chain does want to allow contracts to use another codec, they can simply modify this portion and it will enable eg. protobuf or cap't proto, just with a bit of dev ux impact.
Proposal
Update the field and ensure this works properly.
Manually check both binary and json amino encoding before and after.
Test the cli tools, and in particular viewing such a tx as json (both before and after) to ensure this is a nice enhancement to the UI.
For Admin Use
Not duplicate issue
Appropriate labels applied
Appropriate contributors tagged
Contributor assigned/self-assigned
The text was updated successfully, but these errors were encountered:
Summary
MsgInstantiateContract
andMsgExecuteContract
, both take a message for the wasm contract as[]byte
. Let's change that to json.RawMessage.Problem Definition
Msg is
json
inside allcosmwasm
contracts so far, and additional tooling, likecw-storage
makes that implicit assumption. Without limiting in any way the message format, we can just assert this isjson.RawMessage
. This makes embedding and creating such a structure much easier.Assume the message is
{"approve":{}}
. As is, when we createMsgExecuteContract
, it will have a base64 encoded field, something like:this would make it much simpler, without modifying the binary encoding at all.
Which one is easier to understand, create, and debug?
If a chain does want to allow contracts to use another codec, they can simply modify this portion and it will enable eg. protobuf or cap't proto, just with a bit of dev ux impact.
Proposal
For Admin Use
The text was updated successfully, but these errors were encountered: