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

Validate the Environment of a contract #469

Open
SkymanOne opened this issue Apr 26, 2023 · 5 comments
Open

Validate the Environment of a contract #469

SkymanOne opened this issue Apr 26, 2023 · 5 comments
Assignees

Comments

@SkymanOne
Copy link

Is your feature request related to a problem? Please describe.
There has been a change to the ink! metadata. A new field environment has been added

Describe the solution you'd like
It would be ideal if the UI could validate the types specified in environment match the types of the chain the contracts are tried to be deployed on. This will ensure resilience against type mismatch and data corruption.

Additional context
See See use-ink/ink#1741 and use-ink/ink#1695

@peetzweg peetzweg self-assigned this May 5, 2023
@peetzweg
Copy link
Collaborator

peetzweg commented May 8, 2023

@SkymanOne sounds like a valuable addition to me.

Just compiled the custom-environment example contract to investigate the environment property a bit. Not sure what this should match in the substrate chains metadata. Can you point me in the right direction or docs where the contracts environment and the chains metadata should overlap?

I was trying to find stuff like maxEventTopics and AccountId, I guess the "type": number of each environment element somehow should match stuff in the chain metadata. 🤔

@statictype
Copy link
Contributor

the validation should happen when the user tries to upload the file. wdyt @peetzweg ?

@peetzweg
Copy link
Collaborator

Linking this issues from pjs api. Might be relevant for a future refactor:
polkadot-js/api#5637

@peetzweg
Copy link
Collaborator

peetzweg commented May 10, 2023

Hm bit stuck here, not sure how to make sure the environments of the chain and contract are compatible. Once creating a CodePromise with pjs the registry of the code promise seems to fallback to the chain registry. Not an expert on this registry magic pjs is doing and the docs lack a lot of detail what is actually happening.

I made this codesandbox deno workspace which should show this. Run the following in the cs terminal.

https://codesandbox.io/p/sandbox/custom-environment-80kxpj?file=%2Findex.ts%3A50%2C38-50%2C68

deno task start

I've added a contract which has a non default environment to the workspace. I.e. changed the BlockNumber from an u32 to u64 but it's not properly reflected when using abi.createType().getRawType(). I still get u32. When I use abi.registry.lookup.getTypeDef() I get the expected u64. Not sure what the difference between the to methods are.

abi.registry.createType().getRawType() => u32
api.registry.createType().getRawType() => u32
abi.registry.lookup.getTypeDef() => u64 // Actual value I set in the CustomEnvironment

Furthermore, for AccountId it results this:

abi.registry.createType().getRawType() => AccountId // Actual Rust type is `struct AccountId([u8;32])
api.registry.createType().getRawType() => AccountId // Actual Rust type is `struct AccountId([u8;32])
abi.registry.lookup.getTypeDef() => [u8;16] // Actual value I set in the CustomEnvironment

No hunch how to get better types from pjs.

Another option would be to ditch pjs and plainly do the comparison based on the raw chain metadata data and the contract environment data. However, it does not seem very trivial todo as some types like AccountId and Hash are just mirrored and therefore not serialized the same way as the chain AccountId and Hash.

https://github.com/paritytech/ink/blob/123c4d4b6845aa7259aaae7caa440d2b4380178e/crates/primitives/src/types.rs#L28-L38

Need more knowledge about this type serialization in environment and chain metadata to come up with a proper solution to this.

@statictype
Copy link
Contributor

types are now part of the abi

Screenshot 2023-06-15 at 18 33 46

@peetzweg peetzweg removed their assignment Jul 6, 2023
@peetzweg peetzweg self-assigned this Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants