GenesisConfig in WASM Runtime: A Step Towards a Non-Native Future

At present, the GenesisConfig is not compatible with WASM environments. My current mission is to rectify this and fully incorporate GenesisConfig functionality into the WASM runtime. This is an important step for the progression towards a non-native runtime environment.

The primary problem we’re addressing and proposed high-level plan are thoroughly detailed in this issue: `GenesisConfig` in a native runtime free world · Issue #13334 · paritytech/substrate · GitHub

This post aims to shed further light on the issue, outline our strategy, and share the progress we have made so far.

Here’s an overview of our planned modifications:

  • We intend to enable serialization support in substrate primitives by introducing a serde feature, regardless of std.
  • We are proposing to integrate the serde crate (featuring Serialize/Deserialize traits) into the WASM runtime by default, without the need for a gate feature.
  • GenesisConfig-related code will always be compiled for WASM, without the necessity to introduce serde or genesis-config features into pallets (this includes Default implementation for GenesisConfig).
  • At the runtime level, we’re suggesting a genesis-config feature. We expect that disabling this feature will restrict linking any serde or GenesisConfig related functionality from pallets and the runtime into the WASM blob.
  • To enhance interaction with GenesisConfig for the runtime, we’ve proposed a new runtime API called GenesisBuilder. This API simplifies the instantiation of a default GenesisConfig, its serialization to a JSON blob, deserialization from a given JSON blob, and storage of the GenesisConfig.

Several pull requests have already been initiated in this regard:

For a practical demonstration of the new API’s usage and implementation on runtime side, check out our draft/proof of concept here:

7 Likes