Contract entrypoints return data wrapped in protobuf messages
- Dominant language
- Go
- Stars
- 416
- Forks
- 538
- PR merge metrics
- No merged PRs in 30d
Description
Hi,
Following https://github.com/CosmWasm/wasmd/issues/623.
We are currently [building a new Rust VM](https://github.com/ComposableFi/cosmwasm-vm) following the [CosmWasm VM semantic documentation](https://github.com/CosmWasm/cosmwasm/blob/main/SEMANTICS.md). Everything is working like a charm, but we faced an issue when using contracts.
In fact, the semantic describe how contract entrypoints can return arbitrary `data` along the events. In the document, there is no assumption on how the data must be serialized and it's easy to conclude that the raw payload is transferred as is. We then discovered (because of inconsistent results, our VM pass the data as is while wasmd based chains are serializing the data using protobuf) that the only reference implementation (this VM), has an opiniated way of handling this mechanism.
From and engineering perspective, I would argue that having protobuf involved between two contracts is sketchy, especially when the marshalling to/from contracts is JSON based. Also, the behavior is inconsistent as events are returned as is while data is serialized. Either the semantic must describe this specific behavior or we should stick to the current version and refactor the Go implementation to respect the raw payload. The later is probably the best as it would [avoid us having to embark extra protobuf serialization (or even protobuf itself) in contracts just for deserializing a small piece](https://github.com/CosmWasm/cw-plus/pull/502/files).
Update: Probably worth to mention that there is no protobuf involved in any other `contract->contract` interactions such as Querying. Even the events yield from a submessage are passed as is, why would the data be protobuf encoded then?
Contributor guide
Assessment
This issue has not been assessed yet.