-
Notifications
You must be signed in to change notification settings - Fork 125
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
Introduce a no-wasm compatible ExtrinsicSigner
#461
Labels
F7-enhancement
Enhances an already existing functionality
Comments
haerdib
added
F7-enhancement
Enhances an already existing functionality
and removed
Z6-question
Further information is requested
labels
Apr 3, 2023
Answering myself: yes, definitely. Necessary for signing extrinsic in the TEE. |
We can use the runtime inside the TEE. We do this already. :) |
Ah wait, this is only the sgx runtime. :P |
Hah. I just panicked for a short moment there. Was already double-checking 😨 |
But anyway: For simply signing extrinsics, importing the full Runtime is not worth it. So it's useful either way |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current
ExtrinsicSigner
depends on aRuntime
. But the node Runtime is not available in an environment where wasm is not supported.Therefore, a No wasm compatible
ExtrinsicSigner
(implementing the same traitSignExtrinsic
) where no Runtime type input is needed could be introduced.If not possible in any other way, a hardcoded extrinsic_address type conversion may be used.
@clangenb Would that help your usecase?
The text was updated successfully, but these errors were encountered: