-
Notifications
You must be signed in to change notification settings - Fork 6
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
refactor: generic extension #218
Conversation
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.
This fulfils all the needs that we have identified and well done with the amount of flexibility this implementation provides!
In the past we've experienced how useful this flexibility can be so very much onboard.
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.
Looking good to proceed. We might be able to not use any additional error variant other than Other
with your proposed change to using the pallet contracts error for NoChainExtensionId
. This prevents us wanting to delete it in the future.
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.
Really clean PR! The new format is great. Left a nitpicks.
Will review again after unit tests are added.
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.
Mindblowing!
@peterwht @chungquantin as per your comments above, I addressed them in 2152867 and resolved the conversation. Please could you kindly take a look at the commit and let me know if any concerns? |
d30887c
to
f998bb7
Compare
As for the open questions regarding whether to convert the |
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.
Reviewed again. The architecture is really awesome. Left a few small comments.
Refactors the chain extension to maximise flexibility, ensuring that it is highly configurable and so that anything which is runtime specific is defined there instead - e.g. versioning.
A high level overview of the components:
[contract environment: contract ⇄
pop-api
] ⇄ [runtime:pallet-contracts
⇄pop-chain-extension
⇄pallet-api
⇄fungibles
]The simplest analogy is that of a pipeline, where a request arrives and moves through a pipeline where it can be versioned (processed) based on other information available from the environment and then decoded into a valid runtime call.
pop-api
chooses to encode the version within the ext_id/func_id for example. The reverse also then allows for versioning by adapting any result (read) from a pallet or error into a type/shape the applies to the specific version. More specifics below.Errors
The extension supports conversion of a
DispatchError
into some other error type. This is to allow apop-api
specific error type which is also versionable, which in turn is converted into a u32 status code used by the contract. The contract can then optionally convert this status code back into a specific versioned error type if desired, with some contract size overhead.Reads
The results of reads also need to be versionable, so the
ReadState
function allows an additional conversion to be configured. This is so that we can simply map a current read result type from a pallet into some prior versioned result type before encoding it into the bytes expected by the contract based on the version requested.Versioning
Versioning is considered a runtime-specific requirement and all related logic is therefore contained within the
versioning
module within the runtime. The generic chain extension is configured to be version aware by the various types that are plugged into it.TODOs
Closes #202