Refactor and rename sandboxing implementation

[athei]

The sandboxing code inside the client which is responsible for running the contracts of pallet-contracts needs a refactor. Currently, the different execution engines for contracts are crammed into sc-executor-common. Neither should different execution engines be in the same crate nor should runtime execution and sandbox execution be intertwined in this way. For that reason we want to refactor that code in order to have proper abstractions that allows us to move the sandboxing code to its own set of crates.

Rename

After a discussion with @pepyakin (see comments below) we agreed that we should also move away from the term "sandboxing" for this whole thing. One proposal what I also back is to use the terminology "Wasm Virtualization".

TODO

• Separate wasmi and wasmer sandbox implementations into their own modules #10563
• Create a trait to abstract over sandboxing execution engines ("backends").
• Use dynamic dispatch with that trait to make engine selection possible at runtime (command line argument).
• Move sandboxing code into its own crate client/wasm-virt with one additional crate per execution engine (sc-wasm-virt-wasmi, sc-wasm-virt-wasmer). This should also move all wasm virtualization related traits that needs to be implement by the runtime executor to the new location.

[0x7CFE]

Another open question is whether we need to expand the API to allow for chunked execution so that code merkelization can be implemented. However, current thinking is that we can and should get away without execution engine support. I think it is reasonable to go forward with a non chunked version risking that we might need to maintain two APIs. Otherwise this is blocked by paritytech/polkadot-sdk#122.

I think, by carefully designing the API we can future-proof it to support potential chunked execution similar to what we have done for wasmi during our experiment.

[athei]

Maybe. It adds complexity, though. For example, we would need some kind of feature discovery then because not all execution engines will support this right off the bat. As a matter of fact none will support it as we only put it in for future proofing. Just creating a new version of the API when the need arises is better in my opinion. Future proofing APIs is worth nothing when users will depend on the implementation.

[pepyakin]

Excerpt from our discussion about changing the terminology from sandoxing to a term based on virtualization, e.g. wasm virtualization API, hypervisor API, or whatever.

Specifically, I think it is just too general and does not represent what it actually does. What is usually understood by sandbox? Well, it's when some code is put into an environment where it cannot reach to anything except things that was explicitly designated to be used by that sandboxed code.

If we agree on that definition, then the "runtime" is exactly that. The thing that executes "runtime" (which would be called runtime by normal people) can be also called a sandbox.

However, virtualization is really more appropriate term here I feel. This is because it fits really an analogy. Virtualization is where you have some medium that provides virtualization facilities, some hypervisor/supervisor that virtualizes or multiplexes the underlying hardware, emulating other and providing services, and the guest which consumes those services, who uses the hardware through the hypervisor, and ultimately is controlled by the hypervisor

[athei]

Updated the top post with new information after a discussion I had with @0x7CFE, today.

[athei]

Refined the top posting again after the picture got a bit clearer on how the final refactoring should look like.

[athei]

I narrowed down the scope in this issue and created a proper task list.

[atenjin]

hope polkadot parachain could use this feature soon... for now, parachain in polkadot even can not use sandbox hostfunction...
I think even though polkadot integrate sandbox hostfunction so that the parachain can use host_sandbox, the polkadot will not open the wasmer-sandbox feature...
I do not know how long should we wait for this feature.

[athei]

What exactly do you need it for?

[atenjin]

run a piece of wasm in runtime

[athei]

You can still do that: Use sp_sandbox::embedded_executor. It doesn't rely on this interface but includes a wasmi into the runtime.

[athei]

No one is working on this anymore.

[athei]

Since we decided to go with wasmi for now and we don't really have the resources to work on that we will close it.