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
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.