Skip to content
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

Investigate extended usage of metadata #416

Open
haerdib opened this issue Jan 4, 2023 · 4 comments
Open

Investigate extended usage of metadata #416

haerdib opened this issue Jan 4, 2023 · 4 comments
Labels
F8-newfeature Introduces a new feature Q3-substantial

Comments

@haerdib
Copy link
Contributor

haerdib commented Jan 4, 2023

We have full access to the metadata, but it's hardly used yet. Can we do more with that?

E.g. like this comments suggests:

/// * 'args' - Optional sequence of arguments of the call. They are not checked against the metadata.
/// As of now the user needs to check himself that the correct arguments are supplied.

Check out subxt example: https://github.com/paritytech/subxt/blob/master/subxt/src/tx/tx_client.rs#L56-L73

@haerdib haerdib added F8-newfeature Introduces a new feature Q3-substantial labels Jan 4, 2023
@haerdib haerdib changed the title Check usage of metadata Check extended usage of metadata Jan 5, 2023
@haerdib haerdib changed the title Check extended usage of metadata Investigate extended usage of metadata Jan 5, 2023
@clangenb
Copy link
Collaborator

clangenb commented Jan 5, 2023

It seems that what the comment suggests and what is done in subxt is something entirely different. Subxt does only verify the generic call metadata hash without the arguments of what has been generated at compile time in their macro matches the the hash of the pallet-prefix and the call-name of the supplied call.

Hence, subxt verifies the same thing as we already do with:

let call_index = pallet.call_indexes.get($call_name).unwrap();

Be aware that subxt has more need for validation than us, as it relies on statically generated code that it wants to check against the actual metadata that the client connects to, while the api-client does only know the latter.

but I like the Idea. What could we do with the metadata? :)

@haerdib
Copy link
Contributor Author

haerdib commented Jan 6, 2023

I see. Didn't look too deeply into that. Nonetheless, something like integritee-network/worker#970 (comment) was possible. Not sure if that's verifiable with the metadata, but I think it should be worth it to investigate a little.

@haerdib
Copy link
Contributor Author

haerdib commented Jul 10, 2023

I suggest timeboxing this task to 8h. If there's a promising lead after investigation, it should be done in a different task.

@clangenb
Copy link
Collaborator

There is an extensive discussion on how to change the metadata, especially for (offline-) light clients, and there is an ongoing proposal on polkadot on how to implement this. I suggest waiting for some results there: https://forum.polkadot.network/t/the-ledger-app-debate-united-we-stand-divided-we-fall/3177/9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F8-newfeature Introduces a new feature Q3-substantial
Projects
None yet
Development

No branches or pull requests

2 participants