# We should create an RFC with the Bytecode Alliance to add no\_std support

**URL:** <https://forum.polkadot.network/t/we-should-create-an-rfc-with-the-bytecode-alliance-to-add-no-std-support/398>\
**Category:** Tech Talk\
**Tags:** wasm\
**Created:** [September 15, 2022, 1:49pm UTC](https://forum.polkadot.network/t/we-should-create-an-rfc-with-the-bytecode-alliance-to-add-no-std-support/398 "2022-09-15T13:49:32Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/alex/32/765_2.png) [@Alex](https://forum.polkadot.network/u/Alex)\
**Post date:** [September 15, 2022, 1:49pm UTC](https://forum.polkadot.network/t/we-should-create-an-rfc-with-the-bytecode-alliance-to-add-no-std-support/398/1 "2022-09-15T13:49:32Z")

</div>

The [Bytecode Alliance project](https://github.com/bytecodealliance) houses a multitude of useful WebAssembly related software projects written in Rust. The most prominent of them is probably [wasmtime](https://github.com/bytecodealliance/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`](https://github.com/bytecodealliance/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](https://github.com/bytecodealliance/wasm-tools/pull/41)][[2](https://github.com/bytecodealliance/wasm-tools/pull/454)][[3](https://github.com/bytecodealliance/wasm-tools/issues/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](https://forum.parity.io/t/eliminating-pre-dispatch-weight/1085) 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](https://github.com/bytecodealliance/rfcs) 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.