Implement the Wasm module-linking proposal

[clearloop]

It has already been a part of wasm (component but not core) spec tests, however WASMI has not supported it yet while both wasmer and wasmtime support it

wondering if this has a priority, or ur welcome others' PRs

[Robbepop]

Do you have a use case for the Wasm module-linking for wasmi?

So far nobody has requested this feature. My employer (Parity Technologies) is not in need of this so it is rather low priority although we still want to implement all of the stabilized Wasm proposals in wasmi eventually to stay complete and up to date.

Another reason why I have not yet thought about implementing the Wasm module-linking is that I thought it was superseeded by Wasm component-model and wanted to wait for dust to settle and things to stabilize.

[clearloop]

Do you have a use case for the Wasm module-linking for wasmi?

exactly, for example pallet-contract, we can separate the dlmalloc-rs and ink logic to shared libraries to trim the size of contracts 🧙‍♂️

we have an experimental feature based on this gear-tech/gear#2942 but currently blocked by WASMI xd

[Robbepop]

I spoke with the rest of the smart contracts team at Parity and we came to the conclusion that indeed this Wasm proposal might be useful to us as well for delegate calling libraries.

That said the priority of implementing the Wasm module-linking proposal is still not high for us. Reasons are that there are more pressing things to be done, especially with the upcoming wasmi audit in August, the register-machine engine implementation and the planned lazy compilation strategy to significantly improve execution and startup times.

However, with the conclusion that this feature indeed is useful we might consider implementing it with medium-priority (instead of low-priority) even though it is unstable and so far we refrained from implementing unstable Wasm proposals at all.

What the @gear-tech team could do until then is as follows:

1. Fork wasmi and implement Wasm module-linking there with the chance of upstreaming it into mainline wasmi if the implementation meets our quality standards.
2. Try to find a work around that does not utilize Wasm module-linking proposal by providing tooling support (Due to missing knowledge about the big picture of the Wasm module-linking proposal I am uncertain if this is feasible.)
3. Wait for me (or another wasmi contributor) to do the job. 🙃

This wasmi WIT support implementation might be interesting for you: #703

[jakehemmerle]

We're using Substrate at Entropy but had to rule out wasmi for our off-chain application environment because it's missing support for the components model (WIT stuff). We're using wasmtime currently, but would strongly consider wasmi, especially since it's audited.

Also, yes, module linking proposal has been superseded by the component model proposal, and that would be the proper implementation.

[Robbepop]

We're using Substrate at Entropy but had to rule out wasmi for our off-chain application environment because it's missing support for the components model (WIT stuff). We're using wasmtime currently, but would strongly consider wasmi, especially since it's audited.

Also, yes, module linking proposal has been superseded by the component model proposal, and that would be the proper implementation.

@jakehemmerle If you are primarily missing "WIT stuff" I would like to copy'n'paste this link for you again since it might be of interest to you until wasmi properly implements the Wasm module-linking proposal: #703

[Robbepop]

Closed in favor of #897 since Wasm module-linking got deprecated and was superseeded by the newer Wasm component-model proposal.