Consider compatibility with borsh

[ARitz-Cracker]

Is adding #[derive(BorshSerialize, BorshDeserialize)] to all the structs provided by cosmwasm-std something you're willing to consider? Especially with a "2.0" coming out soon? I have a couple of contracts in development that are currently using bincode to serialize their state, and while I understand why you may want to serialize u64's and larger as strings when communicating with JS/TS systems, when it comes to storing variable-length data as cheaply as possible which is going to be served to the client through queries anyway, I would like a way to opt out of that.

As a sidenote, deriving Zeroable and Pod traits from bytemuck on fixed-length types (i.e. all the number types) could be cool as well.

[webmaster128]

In CosmWasm 2 we will be shipping messagepack support. This will make serializations significantly smaller and especially improve compactness and performance for escaped string and binary data. As this used serde and contains field names we get a significant efficientcy gain without giving up the convenience and debugability we have so far.

For now we don't have plans to add a borsh dependency to cosmwasm-std. If you really need to use it you can create your own data type for storage. I see this can be a lot of boilerplate code. I recommend trying messagepack first.

[webmaster128]

Feel free to re-open if there is more to discuss around this topic