Proof Skipped in benchmark

Question

We're updating our weights to weights 2.0 but we're getting a lot of Proof Skipped lines in the output. What is the impact of this, and how do we fix it?

Example output:

/// Proof Skipped: Escrow Locked (max_values: None, max_size: None, mode: Measured)

Answer 1

Good question and sorry for the confusion - the comment is poorly chosen.

It indicates that the worst-case Proof Size limit could not be estimated. This can come from either:

• The pallet of the storage item does not expose storage information. You can check this by looking for #[pallet::without_storage_info] in the accessed pallet. It needs to be removed in order to have correct proof benchmarking.
• The storage item is not MaxEncodedLen bound (MEL). This implies the former. As soon as there is a not MEL bound storage item in a pallet, it cannot expose these storage info.

If your pallet is missing this exact information then FRAME measures the proof size that was required, hence the indication mode: Measured instead of mode: MaxEncodedLen. The impact is that the results may not reflect the worst-case scenario. So to say; there could scenarios to exploit that and inflate the PoV over the pre-dispatch estimations. In the worst case this means missed block production slots and stalled para-chains.
However for relay chains this is not an issue, since they do not produce proofs. You can basically ignore that for all pallets that will only be used on relay/solo chains.

Storage bounding pallets is not that easy. We tried in Substrate and it is quite time intensive. One tip is to use the Preimage pallet for large blobs instead of trying to re-implement something like that.

MEL

A T: MaxEncodedLen bound expresses that all instances of T will always encode to at most MaxEncodedLen::max_encoded_len() bytes. This is important since it provides up-front information about the worst case storage requirement for encoding any T. It is used to calculate the worst-case size of the Proof.