-
Notifications
You must be signed in to change notification settings - Fork 443
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Environment agnostic contract invocation API #2219
Conversation
WIP
environment agnostic message invocation API
🦑 📈 ink! Example Contracts ‒ Changes Report 📉 🦑These are the results when building the
Link to the run | Last update: Fri Apr 26 14:13:31 CEST 2024 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please merge master
and adopt the license header (Parity Tech) as well.
Please also add a changelog entry. |
The next foundational layer towards #1674.
This PR:
Executor
trait which can be implemented in different environments (e.g.pallet-contracts
, see example). TheExecutor
implementation has the responsibility of gathering the other call parameters and performing the environment specific invocation, as well as decoding the result.message_builder!
macro which instantiates the generated message builder instance for use to generate and invoke messages.This PR does not:
pallet-contracts
, it requires a boilerplate impl ofExecutor
(seeintegration-tests
). The reason this is not provided as part of the lib is that it would require matching versions ofpallet-contracts
etc. with the target runtime. Need to think carefully about how best do this for maximum convenience for the user and minimum maintenance cost on theink
side.pallet-contracts
context as it is better to depend on a trait rather than a contract impl, since you are working against an interface.ContractRef
would have to be used for that,CallBuilder
API which provides a nice interface for applying the weight and storage limit parameters etc.These can be resolved in subsequent work. The goal here is to provide a relatively simple non-breaking stepping stone to a possible universal contract invocation API, can use in the cross-contract context, from
pallet-contracts
and frome2e
tests.