Make wasmparser and wasm-encoder compatible with no_std

[athei]

The Vision

The Bytecode Alliance project houses a multitude of useful WebAssembly related software projects written in Rust. The most prominent of them is probably wasmtime which we use to execute our runtime. Wasmtime itself is not a candidate for no_std because it needs an operating system to function. One could argue that the code itself generation could be no_std but this not what we are after.

The useful bit for us is the wasm-tools repository which houses crates like wasmparser and wasm-encoder which we want to use to replace our deprecated parity-wasm with. It is used by wasmtime anyways and would allow us to use a single parser instead of being exposed to the bugs of two implementations. There is no inherent reason that those do not support no_std (with the exception of hash maps which need entropy to be secure against Dos) as they do not depend on any platform.

There were attempts [1][2][3] to make this repo no_std compatible (which is trivial) but they were all shot down for the lack of an RFC. Because those are very valuable tools for us we should make an effort to actually write this RFC.

The wasmtime project wrote down their stance on no_std. Additionally, there is an open issue about making wasmparser no-std compatible which seems to be stuck. Those should be read and taken into account for the RFC.

Wasmi which needs to be compiled for no-std as part of pallet-contracts uses a fork of wasmparser (maintained by @Robbepop). Having this RFC would remove the need for maintaining this fork.

In order to close this issue we need to go here and create a (draft) RFC that basically says this:

Every library crate within the wasm-tools where it makes sense should support no_std. If there are crates were sub functionality can be useful on its own and can exist as no-std they need to be broken down in smaller crates. The no_std version (just as the std version right now) need to be able to deal with untrusted input securely. One example of that would be hash maps which can be used in no_std but not securely on untrusted input. Rust's hash maps need to be initialized with unpredictable and secret random data to be resistant against DoS. Something that cannot be assumed to be available on no_std platforms in general and especially not on public blockchains. The nostd probably just replaces them with a BTree map as a fallback. Optionally, it can offer configuration for users which are able to provide such random data.

The Plan

• Create the RFC and get it accepted
• Open and merge PR to make wasmparser no_std compatible. This would be basically mean upstreaming our fork.
• Open and merge a PR to make wasm-encoder no_std compatible. We can use it in pallet-contracts runtime benchmarks to get rid of parity-wasm.
• We don't care so much about the other crates as we only plan to use them in std environments. So we don't require them to be ported for closing this issue.

Open Questions

If you want to help us out and contribute to this issue, in this section you can find open questions and tasks where we would appreciate any input.

[athei]

No longer necessary as we switched away from Wasm.

[kayabaNerve]

No longer necessary as we switched away from Wasm.

Can you please clarify? Are you referring to future Polkadot designs focusing more on RISC-V (via PolkaVM), a more immediate change within Polkadot, or is "we" referring to a distinct organization/suborganization (such as specifically pallet-contracts)?

[athei]

Both. Polkadot itself is moving away from Wasm with JAM. pallet-contracts will be replaced by pallet-revive which also no longer uses Wasm.

But AFAIK at least wasmparser is already no_std compatible.