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 an obvious candidate for no_std support because it needs to execute native code but there is still utility to us if we could parts of it to no_std (more on that later).
The most 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 bit rotten parity-wasm. It is used by wasmtime anyways to we are exposed to its potential bugs anyways. 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 on missing an RFC for that. Because those are very valuable tools for us we should make an effort to actually write this RFC.
Including wasm-tools in this RFC is a no brainer. But let’s take about wasmtime for a minute. Obviously the execution of native code can’t happen in no_std. However, the code generation part can. This part of wasmtime would be factored out into its own crate and made no_std. Why? Given we have a metered runtime we can run the wasmtime code generation within this runtime even on untrusted code like contracts. While wasmtime codegen is non linear and susceptible to compiler bombs it doesn’t matter if we meter it. This would allow us to have contracts with runtime execution speed.
So someone needs to go here and create a (draft) RFC that basically says this:
Everything under Bytecode Alliance that can be no_std should be. If there are crates (like wasmtime) were sub functionality can be useful in no_std they need to be broken down in smaller crates. In corner cases like hash map usage which can be used in no_std but not securely on untrusted input the crate needs to allow to either replace it by a btree map or provide external entropy by the dependee.