Exploring Wasm Component Model and WASI

Developers
, ,
1

Hey everyone,

Quick update on something exciting we’ve been looking into!

TL;DR

We’ve been exploring the WebAssembly Component Model (think of it as Wasm’s standard library format) and WASI (Wasm’s standard System Interface). And we’re considering an MVP implementation later this year!

Why is this a big deal?

The Component Model and WASI have the potential to really unite the ICP ecosystem by supporting standard libraries right out of the box. This also means more Motoko libraries, as we’ll be able to mix and match Motoko, Rust, and other languages in one canister. Plus, it’ll boost ICP’s security by adding support for virtualization on ICP, opening doors for user code or even full blockchain-on-blockchain use cases.

What are the current challenges we’re facing?

  1. Fragmented ICP ecosystem: It takes a lot of effort to get libraries working across different languages right now.
  2. Limited Motoko libraries: The Motoko ecosystem is still growing, with 211 mops packages currently available.
  3. No easy virtualization on ICP: It’s not straightforward to safely run third-party user code or blockchain-on-blockchain applications.

What’s next?

By supporting the Wasm Component Model on ICP, we aim to:

  1. Unite the ICP ecosystem around common libraries and cross-language canisters.
  2. Open up possibilities to use Rust, JS, Python, etc. libraries in Motoko (and vice versa!).
  3. Enable virtualization to safely run user code or blockchains-on-blockchains.

The WASIp2 support will come later.

We’ll be sharing more details in the upcoming public Global R&D, and I’ll post the links in this thread once they’re available!

Stay tuned!

Update:
2025-06-25 DFINITY Global R&D presentation on Component Model and WASI

23 Likes
2

I think this is an excellent choice in focus from DFINITY. It is one of the keys to enabling ICP to run as much software as possible.

This could be a boon to Kybra for example, more easily allowing Python with code written with the C APIs. Many of the most popular and important Python packages require dynamic linking of code written in other languages. I believe the component model is going to make that natively possible in Wasm.

Also in Azle, Kybra, and I imagine Rust and Motoko, embracing Wasi will help us to enable low-level system APIs that could open up sockets, HTTP, and possibly other APIs, allowing us to bring many libraries to all languages on ICP, libraries that use native HTTP APIs, like fetch in the Node.js ecosystem, without requiring a rewrite to the ICP-specific APIs (like the management canister’s http_request method).

In my opinion, a major focus on Wasi and the component model should be of the highest priority to the ICP community, as it will allow ICP to come closer to being able to execute basic software that all other major cloud platforms already allow, but that ICP has not allowed.

This is crucial if ICP wishes to ever achieve its goal of a blockchain singularity.

6 Likes
3

Will you be able to link/load components at runtime? That would be insanely cool, and useful. But I guess, more likely, components need to be configured at build time?

4

Wasm components can be distributed using an OCI registry and wasm-pkg-tools.

Runtime linking could be useful for making canisters leaner, reducing compilation times, and potentially applying security hotfixes without canister recompilation.

While the MVP will only support static linking, a cross-language ICP components registry would still be a great feature IMO.

1 Like
5

Dynamic linking would be massive, taking composability and collaboration to the next level. I imagine we could see projects allowing user created plugins etc.