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
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  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.
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.