-
Notifications
You must be signed in to change notification settings - Fork 2.6k
seal: Introduce Chain Extensions #6466
Comments
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 |
The most important part for ink! is the actual definition of the API. fn seal_call_chain_extension(
func_id: u32,
input_ptr: u32,
input_len: u32,
output_ptr: u32,
output_len_ptr: u32,
) -> u32 |
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? |
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.
You basically just make new functions available to your contract. Those can of course make use of the existing state.
Yes. This is fully backwards compatible because we are only adding new functions available to the contract. |
With the removal of
ext_dispatch_call
andext_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.
The text was updated successfully, but these errors were encountered: