search

CosmWasm / cosmwasm

Framework for building smart contracts in Wasm for the Cosmos SDK
https://www.cosmwasm.com/
Apache License 2.0
1.06k stars 330 forks source link

Make CosmWasm std package `no_std` capable #1484

Open hussein-aitlahcen opened 1 year ago

hussein-aitlahcen commented 1 year ago

Hey, making the CosmWasm std package no_std capable would allow third parties to use it in more constrained environments. At Composable we run a CosmWasm VM under a Substrate pallet (equivalent of Cosmos module) and this require the dependencies to be no_std (targeting wasm32).

When prototyping the VM, we initially copied parts of the std (as we are only interested in the types for the VM) and we now think that it is the good moment to deprecate this forked std in favor of the official one.

Consequently, having the PR #1483 merged would drastically improve the interface of the alternative VM and also allow us to maintain it by following the CosmWasm upgrades.

webmaster128 commented 1 year ago

Picking up yesterday's thoughts on extracting a minimal interface package shared between cosmwasm-std and cosmwasm-vm (#1483): Creating yet another package comes with significant drawbacks wrt. documentation. A contract developer only should bother about cosmwasm-std. All relevant symbols and their documentation should be in https://docs.rs/cosmwasm-std/latest/cosmwasm_std/. If we extract some parts, it adds more indirection and the contract developer suddenly has to worry about the difference between the packages even if they are exported through cosmwasm_std. I think we should focus on dev UX and rather spend 10 days maintaining the codebase if it save the contract dev 10 minutes navigating. cosmwasm-std is maintained by a handfull of highly skilled devs very familiar with the codebase and committed to it for months. But it is used by hundreds of devs in various levels from absolute beginner/Rust newbie to advanced blockchain dev. So optimizing for cosmwasm-std maintenance convenience feels wrong. Looking at #1483 the diff is not all that scary to me. cosmwasm-std has few dependencies and I think it's worth evaluating their no_std compatibility.

mina86 commented 1 year ago

forward_ref can be copied over if needed

I have a PR for it. The crate pretty much is no_std except that it lacks the necessary annotation. However, the PR is sitting in limbo so I dunno if the project isn’t abandoned.

schemars probably has to become optional

schemars is only used for generating the schema as far as I understand and as such it isn’t cross-compiled to no_std targets. Changing cw_serde macro such that it conditionally derives schemars::JsonSchema should works nicely.

serde serde-json-wasm

Both have no_std support. serde-json-wasm in the newly released 1.0 version. In both cases no_std support requires nightly compiler (this is due to core::error::Error).

thiserror

May I suggest a bold option: stop supporting std::error::Error with 2.0 release? Since CosmWasm is reliant on serde, one cheeky option is to use serde::ser::StdError instead and for deriving Display we can use derive_more::Display. The only downside here would be no easy way to derive source method.

I’ve sent a PR adding no_std support however dtolnay rejected it on the grounds that it requires nightly compiler. There is thiserror-core fork which does support no_std so that’s also an option. I’ll try to push some preparation PRs to thiserror to make it so that the fork will have smaller diff to upstream.

webmaster128 commented 9 months ago

1971 will create an std feature that allows to conditionally enable the use of std. This feature is enabled by default but must be enabled manually if default-features = false is used. This makes it breaking and will ship in cosmwasm-std 2.0.

For now a build without std enabled is likely going to fail. Whoever needs no_std support is welcome to improve the situation for such builds. I'll keep this open but remove the full no_std support from the 2.0 milestone.

Thanks everyone