7

I am trying to prepare the pallets for Weights v2 at Encointer and a couple of questions arose.

Where can I find documentation on what exactly has to be done in terms of bounded types?

What is the unit of proof_size in Weight v2?

From what I understand all storage needs to be of bounded types in order to make sure that the proof_size is bounded as well. Is this correct?

I saw here an example of migrating Vec to BoundedVec and Call to Bounded<Call>. Is it sufficient to only have bounded types as keys/values in storage or do we also need to limit the size of Storage(Double)Maps? If yes, how to determine those limits? Is there a maximum proof_size that we can use as a benchmark? Can you provide pointers to the Substrate repo of such an implementation?

1 Answer 1

4

Great questions!

Where can I find documentation on what exactly has to be done in terms of bounded types?

The docs are quite sparse. Ideally the compiler should be able to lead the path. You "only" have to remove the pallet::without_storage_info from your pallet and resolve all compile errors.

What is the unit of proof_size in Weight v2?

The unit is Byte. There are constants for them here but the conversion is 1:1 as you can see.

From what I understand all storage needs to be of bounded types in order to make sure that the proof_size is bounded as well. Is this correct?

Yes. Otherwise when your pallet has unbounded storage types, then the proof size will have to be approximated through measuring. This is not as secure as having it computed, but can help as a make-shift solution to ease the transition.
This is mostly important for para-chains, as relay chains don't have a proof size limit.

Is it sufficient to only have bounded types as keys/values in storage or do we also need to limit the size of Storage(Double)Maps?

This is a bit tricky. The FRAME benchmarking assumes StorageMaps to have a maximum of 1M entries at most. This can be changed either through the MaxValues generic, or for all maps via --worst-case-map-values on the CLI. This is an assumption that holds in most cases, but it is admittedly not a great solution since the pallet developers have to enforce that limit on their own without help from the StorageMap API.

If yes, how to determine those limits?

The same way that you would determine bounds on BoundedVecs. Not much advice I can give there. Just pick a reasonable upper bound and keep in mind that the proof size grows by the log16 of that plus a constant factor.

Is there a maximum proof_size that we can use as a benchmark?

Polkadot/Kusama/Westend/Rococo parachains have (and always had AFAIK) a 5MiB proof limit.
This is the limit on the compacted, encoded and compressed Proof whereas the benchmarking only calculates the encoded and compacted proof size without extrinsic length. There is an issue here to tackle this. Otherwise a too high PoV estimate could hurt block utilization.

Can you provide pointers to the Substrate repo of such an implementation?

I think the difficult part is to bound all storage items and migrate them. Substrate did this here for its parachain pallets. For the most part you really just have to remove the without_storage_info and fix the fallout.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.