Contract signatures checking

[pepyakin]

This PR introduces logic for checking signatures of functions imported by smart-contracts, providing convenient interface for these functions.

Since signature of a function and it's arguments are super related I defined define_env macro which purpose is two-fold:

• let's user define the signature in the most natural way (as in Rust) and convert all arguments for the expected type,
• provide these function signatures in form that can be used for checking a wasm module for compatibility with these signatures.

Don't be afraid of a big amount of add/removed diffs, it just substrate_runtime_contract::vm code was split on two modules: prepare, env_def.

prepare module handles loading, checking and preprocessing wasm modules) and env_def module contains the environment defintion (i.e. functions that can be imported by a contract) and all related machinery like macros.

[gnunicorn]

@pepyakin could you rebase this?

[gavofyork]

it's pretty huge - would be good to get a few comments in here to describe what it's meant to do how it's meant to work and which bits do what.

[pepyakin]

This is a new test that ensures we correctly check signatures.

[pepyakin]

This is the test that actually ensures that libsandbox actually doesn't care of signatures.

[pepyakin]

this code mostly preserved from src/vm.rs

[pepyakin]

this code mostly preserved from src/vm.rs

the difference in that instead of scanning imports for imports of memory instances we now also process all functions, checking their signatures.

[pepyakin]

@gavofyork Yeah, sure!

Introduction

We have a library substrate-runtime-sandbox (I will use libsandbox to refer it below). It provides an interface to execute the given wasm code and even, as long as executing runtime supports it, while this library is called from wasm itself.
One of libsandbox design decision is that it doesn't care about function signatures at all, i.e. it allows supervisor (i.e. who own the sandbox) to register any functions with any signatures in guest environment (i.e. the code inside the sandbox) and the guest environment can call the function with whatever arguments it like. This design was used because several reasons, but for this disscussion only two are important:

1. it's more compatible with JS (there is no way of getting the signature of a function in JS AFAIK),
2. it makes libsandbox API surface slimmer (this is important, since we are going to have at least 3 implementations of this API: with_std (spins up wasmi directly), no_std (delegates all sandbox calls to the external environment. This in turn requires implementation all of sandbox externalities in substrate-executor), JS (requires implementation of sandbox externalities in substrate-executor JS counterpart).

This leads to the fact that it's up to the supervisor to check if the given module is compatible with the environment. That is, the owner of the sandbox should check that all imported functions not only exists but also have proper signatures.

That was a long-standing design problem that I delayed to implement as much as possible, since I don't find this design particulary user-friendly.

With all that, here is some problems with the former code:

1. in implementations of external functions we used .unwrap()s to get the function arguments. Here is an example.
2. these unwraps can actually be triggered (so there were a little sense to replace them with expects)!

The Pull Request

We can't really get rid of unwraps since there is no way to declare signatures statically. But what we can do is to hide unwraps ensuring they are never triggered. This is what this PR doing in the nutshell.

The mechanism is very similar to the one we have in substrate-executor: we have a macro that allows us to declare some set of external functions with their signatures and bodies. In the bodies of these functions you can only access arguments declared in the signature and return the value that specified by the signature (example). Under the hood unwraps are still there though. In both cases this macro also generates some data that allows checking a module for compatibility with the provided external functions.

However, in the case with the substrate-executor import signatures are checked by the wasmi. And with the libsandbox we have to do it by ourselves. We already have been doing some prepairatory things, so this checks are fit naturally in preparing code.

As I've noted in the PR description, I split the src/vm.rs into several modules: env_def, prepare. This is due to vm became unwieldy (now though I understand that was a mistake since it complicated the review).

[gavofyork]

"vne" looks too much like an actual typo - maybe rename to "another_module"

[pepyakin]

Agreed!