refactor: reading state charging weight

[Daanvdplas]

Read state weight implementation with benchmarks and test coverage (#132 (comment)).

Including proof size (SE).

The Proof size weight of a storage read is the maximal size of the storage item being read. We have the MaxEncodedLen trait to track this. So you need contextual information about the type that is being read and then use MaxEncodedLen::max_encoded_len() on it.
Depending on what the chain extension does, it may or may not be easily possible to know what key is being accessed. Smart contracts are normally uses an optimistic approach and revert on error, whereas FRAME requires to know the worst case effort in advance. These are just fundamentally different computational models.
If you can: write a benchmark. The only way to currently write FRAME benchmarks it to use a pallet; for example the minimal pallet or some mocked types just to make the benchmark compile.
If you want to know how to charge it exactly, that would be env.charge_weight(Weight::from_parts(0, proof_size)).

[evilrobot-01]

(Outdated)

#122 (comment)

[evilrobot-01]

(Outdated)

https://github.com/r0gue-io/pop-cli/blob/b4874220ca58ebb38453c7ab83670f7e0711c674/crates/pop-parachains/src/templates.rs#L168 shows an example of attaching a custom property to an enum using strum, with https://github.com/r0gue-io/pop-cli/blob/b4874220ca58ebb38453c7ab83670f7e0711c674/crates/pop-parachains/src/templates.rs#L194 showing how it can then be obtained. This could be reimplemented as a custom enum property which is statically defined on the enum, and can be used to charge the defined amount of reads/weight BEFORE execution of the read. Your suggestion of attaching it to the output of read_state wont work as charging after a read opens an attack vector.

Yes, a match may be required, but so what. The important thing is accurate weight charging before a read. This can be defined within an additional read_weight function, which could even potentially be defined as a trait with a default implementation. Further improvements could refactor any match out completely.

The point is making it easy to specify the weight/number of reads per query by decorating the enum variant so it is defined in a single place. Returning the value should then be straightforward.

[Daanvdplas]

Closed by #284