Skip to content
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

Simplify json encoding of Execute/InstantiateMsg #17

Closed
1 of 7 tasks
ethanfrey opened this issue Jan 10, 2020 · 1 comment · Fixed by #32
Closed
1 of 7 tasks

Simplify json encoding of Execute/InstantiateMsg #17

ethanfrey opened this issue Jan 10, 2020 · 1 comment · Fixed by #32
Assignees
Labels
API Fixes to the external client api

Comments

@ethanfrey
Copy link
Member

ethanfrey commented Jan 10, 2020

Summary

MsgInstantiateContract and MsgExecuteContract, both take a message for the wasm contract as []byte. Let's change that to json.RawMessage.

Problem Definition

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:

{
  "contract": "cosmos1qlc8f2fmw",
  "msg": "eyJhcHByb3ZlIjp7fX0=",
}

this would make it much simpler, without modifying the binary encoding at all.

{
  "contract": "cosmos1qlc8f2fmw",
  msg: {"approve":{}},
}

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
@ethanfrey ethanfrey added the API Fixes to the external client api label Jan 10, 2020
@workshub
Copy link

workshub bot commented Jan 13, 2020

This issue is now published on WorksHub. If you would like to work on this issue you can
start work on the WorksHub Issue Details page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Fixes to the external client api
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant