Validate the `Environment` of a contract

[SkymanOne]

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 https://github.com/paritytech/ink/pull/1741 and https://github.com/paritytech/ink/issues/1695

[peetzweg]

@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]

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

[peetzweg]

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

[peetzweg]

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]

types are now part of the abi