3

I am trying to compile my own runtime, as PoC, but I don't use Rust's toolchain and some things are unclear how to do it at the moment.

With Substrate, you can write your blockchain logic in any language that can compile to WebAssembly (Rust, C/C++, C#, Go, etc).

Could somebody provide more details about the compilation of Wasm runtimes from languages/toolchains other than Rust?

  • does it target WebAssembly 1.0 specification?
  • does it target WASI, as it should be run outside the browser?
  • is it possible to use language with automatic memory management?
Improve this question

1 Answer 1

Reset to default
3

does it target WebAssembly 1.0 specification?

The wasm runtime actually targets WebAssembly MVP, i.e. without any extensions enabled.

is it possible to use language with automatic memory management?

Well, to support automatic memory management [^1], the GC proposal would be handy. But as I mentioned, the wasm runtime supports only MVP currently and the GC proposal is under development still.

But, theoretically, it might be possible. The support would be limited, to say the least. Your toolchain would need to polyfill the GC. I suppose the performance would be unsatisfactory.

[^1]: I assume you mean GC based languaged by that, such as Java, .NET, etc. E.g. ARC used by Swift can work just well as of now.

does it target WASI, as it should be run outside the browser?

No, it does not.

WASI is a standard that seeks to provide a system-level API comparable to an OS. Substrate/Polkadot is no OS and it does not support files, networking, or a major part of other things provided by WASI. Instead, a more domain-specific API is provided. You can see the host API definitions in the spec.

Improve this answer
4
  • etc. E.g. ARC used by Swift can work just well as of now. What about AssemblyScript, it is mentioned in the docs that it has garbage collector implemented?
    – user2862
    Commented Jul 13, 2022 at 8:43
  • I am no assemblyscript expert, but AFAIK, their GC implementation does not rely on the wasm GC collection feature but it polyfills it.
    – pepyakin
    Commented Jul 13, 2022 at 13:03
  • Just theoretically, if we assume the GC proposal is ready, what would be the process of migrating to it? How are these changes going to work with the Polkadot spec and the existing implementations of it?
    – user2862
    Commented Jul 27, 2022 at 7:17
  • @user2862 it is not yet clear if Polkadot will be able to leverage the GC proposal. Potential problems include determinism (is there anything in GC that causes ND? Can it be tamed efficiently?) and safety (Is it possible for a host to limit the resource consumption reliably and deterministically?). Assuming that it all works out, then there is no migration needed. It is just enabling feature, not every runtime would want to use it (Rust-based ones likely won't). So it's just: implement, test, and deploy.
    – pepyakin
    Commented Jul 27, 2022 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.