seal: Introduce Chain Extensions

[athei]

With the removal of ext_dispatch_call and ext_get_runtime_storage we made it easier to reason about what a contract can do. However, without those APIs there is no way to have a custom interaction with the runtime.

We want allow chain authors to be able to augment the seal API with additional functions that provide functionality that goes beyond what is provided by the core API. This allows them to tailor seal to their use case.

This customization should be possible without modifying the seal pallet. Those additional APIs should be defined in the same way as other customization applied by the runtime.

[pepyakin]

Ideally, the user of the contracts pallet will be able to add host functions that are available to be imported by a wasm blob. However, that would be not trivial to add.

Instead, for the first iteration we could add a function, tentatively named ext_syscall that receives a byte buffer. It will pass that byte buffer along with gas meter to a trait/function specified in pallet_contracts::Trait (ultimately defined by the chain author). This function would handle any chain specific functions and possibly return a result - Ok(byte_buffer) or Err which would be translated to a trap.

[Robbepop]

The most important part for ink! is the actual definition of the API.
In some discussion with @athei we reached this design so far that ink! uses behind a feature flag.
So can be used as soon as it is implemented on Substrate if nothing is changed to it.

fn seal_call_chain_extension(
    func_id: u32,
    input_ptr: u32,
    input_len: u32,
    output_ptr: u32,
    output_len_ptr: u32,
) -> u32

[gregzaitsev]

Hi Robin and Alexander! While we are waiting for this to complete, could you please explain what the Chain Extensions (CE) are meant to be? Is this part of Ink! 3.0, Contracts Pallet, or anything else? If we have a live substrate based chain (with some state), how would I enable CEs after they are ready? Will smart contracts that were deployed before CE release be usable in this chain?

@Robbepop, @athei

[athei]

Hi Robin and Alexander! While we are waiting for this to complete, could you please explain what the Chain Extensions (CE) are meant to be?

You will be able to define functions in your runtime that can then be called by contracts executed in the pallet_contracts of that runtime. Those calls will be synchronous so you can actually get the result and error out on error (improvement over the old functionality).

We make this opt-in because having a blanket "call into runtime" is considered too difficult to audit. Mainly because all contract triggered calls into the runtime run in the same wasm instance. This is in contrast to calls that are triggered by extrinsics which get their own instance.

That said, we expect those chain extension functions be mostly (hardened) wrappers around existing extrinsic callable dispatchables. But contract exclusive functions are also not too far fetched.

If we have a live substrate based chain (with some state), how would I enable CEs after they are ready?

You basically just make new functions available to your contract. Those can of course make use of the existing state.

Will smart contracts that were deployed before CE release be usable in this chain?

Yes. This is fully backwards compatible because we are only adding new functions available to the contract.