12

I have a question about how pallet-contracts interprets a Wasm contract. Are the following assumptions correct?

  • pallet-contracts interprets contracts through the simple wasmi interpreter
  • gas metering is not done by extending this interpreter with metering capabilities, but by cleverly analyzing the Wasm code and injecting calls to a metering function as sparingly as possible (through wasm-instrument)
  • like every pallet also pallet-contracts is compiled to Wasm itself as part of the Wasm runtime
  • the Wasm runtime is executed through the more powerful Wasmtime Wasm engine (as part of the external node), which even does JIT compilation

So if these assumptions are correct, does that mean that every contract is intepreted through wasmi, whereas wasmi itself is executed through Wasmtime, i.e., a double layer of Wasm execution?

If so, is there any chance to remove one layer in the future and execute the contract directly through the node's Wasmtime engine? If not, why not use Wasmtime instead of wasmi in pallet-contracts, I guess that would be more efficient and would also allow for SIMD operations?

Improve this question
0

2 Answers 2

Reset to default
16

All your assumptions are correct. And yes we have a double layer of execution right now. There exists an API that allows us to have the execution engine within the the client (native code) which would allow us to use a compiler instead of an interpreter. Supported execution engines for this right now are wasmi and wasmer singlepass. We can't use wasmtime because as an optimizing compiler it uses non linear algorithms that are highly susceptible to compiler bombs. The runtime code is somewhat trusted as opposed to contracts. Also, it is totally unclear if compilation brings an end to end benefit for the typical contract workload.

That said, this API is currently not available on the relay chain validators. We plan to use the in-runtime interpreter until we clearly see that moving it to the client improves performance. Using an in-runtime interpreter gives us the most flexibility in making changes because we don't rely on any client behavior.

Improve this answer
4
  • Thanks, super interesting. Good to see that you guys put a lot of thought into this and makes sense that you want linear complexity only. There is quite a big performance gap between Wasm smart contracts and native code but a lot of potential to improve this over time. Could be a game changer for adoption of Wasm SCs. Is there any open discussion or reference document about potential performance improvements considered or planned in the future?
    – Torsten Stüber
    Commented Apr 6, 2022 at 12:33
  • Right now we are still focusing on delivering a sound solution first. Areas where we see the most room for improvement: Move gas metering into user space. Improve wasmi performance by transforming wasm to a register machine byte code before execution. Moving wasmi into the client.
    – Alexander Theißen
    Commented Apr 6, 2022 at 13:13
  • It could be complicated and expensive: but did you consider to allow for a one time optimizing compilation of SCs during deployment when the deployer pays extra gas? You could limit the optimization time according to the provided paid gas (which means that the optimization phase itself needs to be metered and interruptible at any time in case the provided gas runs out)? Then again, JIT depends on the target machine and is not deterministically reproducible between Substrate nodes...
    – Torsten Stüber
    Commented Apr 6, 2022 at 13:50
  • It won‘t work because time is subjective. So a timeout won‘t fly within runtime logic. It will lead to consensus issues. Compilation right now is part of the fee structure but fees assume that everything is at most linear complexity.
    – Alexander Theißen
    Commented Apr 6, 2022 at 19:42
5

Overall your assumptions are correct. WASM Smart Contracts are currently interpreted by the wasmi Interpreter.

There exists indeed considerations to switch to the wasmer compiler/runtime. AFAIK those compilers are heavily platform dependent and the Validator nodes would need to expose some ABIs first, so that we can execute those execution engines within the runtime.

It is also not granted, that a compiler, which would have to compile the Smart Contract on every access, would improve the performance in any case.

Improve this answer

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.