Files
pezkuwi-subxt/substrate/primitives/sandbox
Koute a7e3d819f8 Refactor sp-sandbox; make sure both sandbox executors are always tested (#10173)
* sp-sandbox: convert executors into normal `mod`s instead of using `include!`

* sp-sandbox: run `cargo fmt` on `host_executor.rs`

* sp-sandbox: abstract away the executors behind traits

* sp_sandbox: always compile both executors when possible

* sc-executor: make sure all sandbox tests run on both sandbox executors

* sc-executor: fix brainfart: actually call into the sandbox through the trait

* sc-runtime-test: fix cargo fmt

* sc-runtime-test: deduplicate executor-specific sandbox test entrypoints

* sc-executor: test each sandbox executor in a separate test

* cargo fmt (Github's conflict resolving thingy broke indentation)
2021-11-08 12:52:11 +00:00
..
2020-08-20 17:04:42 +02:00

This crate provides means to instantiate and execute wasm modules.

It works even when the user of this library executes from inside the wasm VM. In this case the same VM is used for execution of both the sandbox owner and the sandboxed module, without compromising security and without the performance penalty of full wasm emulation inside wasm.

This is achieved by using bindings to the wasm VM, which are published by the host API. This API is thin and consists of only a handful functions. It contains functions for instantiating modules and executing them, but doesn't contain functions for inspecting the module structure. The user of this library is supposed to read the wasm module.

When this crate is used in the std environment all these functions are implemented by directly calling the wasm VM.

Examples of possible use-cases for this library are not limited to the following:

  • implementing smart-contract runtimes that use wasm for contract code
  • executing a wasm substrate runtime inside of a wasm parachain

License: Apache-2.0