Properly set the max proof size weight on defaults and tests

[KiChjang]

Part of paritytech/polkadot-sdk#256.

This PR sets the default proof size weight correctly, so that it passes unit tests as intended.

The default max proof size is set at u64::MAX, because not all substrate-based chains require submitting PoV blocks to the relay -- standalone sovereign chains can safely ignore this weight component.

For parachains however, the proper parameter to set for the max proof size comes from the relay chain, and is stored a field called max_pov_size in this struct: https://github.com/paritytech/cumulus/blob/032540dbf9afc9f5a0d5db7279fc81048f3a168b/pallets/parachain-system/src/lib.rs#L526.

[ggwpez]

Much needed, thanks.

You chose u64::MAX as a default since it would get rejected by any sensible relay-chain config (if used in a para-chain)?

[KiChjang]

You chose u64::MAX as a default since it would get rejected by any sensible relay-chain config?

Because it allows chains that don't care about PoV sizes to safely ignore this weight component. Maybe I should write this in the docs somewhere so that people know that they should use u64::MAX for the proof size if their chain doesn't need to care about it.

[shawntabrizi]

if their chain doesn't need to care about it.

I guess this brings to mind that maybe this should be an Option value then... but i think for simplicity we don't need that.

But generally speaking, this kind of thing is what Rust is good at describing with explicit types, so just want to call that out.

[bkchr]

But generally speaking, this kind of thing is what Rust is good at describing with explicit types, so just want to call that out.

Exactly what I said on element :P

[KiChjang]

I guess this brings to mind that maybe this should be an Option value then... but i think for simplicity we don't need that.

I thought about this, but it actually doesn't help much, because there's actually two default values: one defaults to max where it's being used to determine the maximum proof size for a block, and the other defaults to 0 where it's sensible for measuring the proof size of an actual operation.

Even if we create new types for this, we can't escape the fact that whenever you define the max block for a chain, you'd still have to manually define the max proof size, rather than relying on the 0 default. And if we try and do it the other way around and make the default u64::MAX instead, then we need to be very careful and weigh extrinsics appropriately, otherwise they would never be able to be placed in a block due to it exceeding max block.

[bkchr]

In a general note, this will not work for Parachains. Parachains have the max proof size defined by the relay chain and this value could change any block (it isn't but it is a value that is changeable on the relay chain). So, we would need to have a dynamic way of getting the max proof size.

[mustermeiszer]

@bkchr getting the weight of the pov from the validation data is a solution here right? Because, this "could" change from the relay side dynamically, or can we just assume that MAX_POV_SIZE from the primitives is always good to use statically?

[bkchr]

Even if we create new types for this, we can't escape the fact that whenever you define the max block for a chain, you'd still have to manually define the max proof size, rather than relying on the 0 default. And if we try and do it the other way around and make the default u64::MAX instead, then we need to be very careful and weigh extrinsics appropriately, otherwise they would never be able to be placed in a block due to it exceeding max block.

Maybe we should get rid off the Default implementation for Weight at all. This would probably change a lot of code, but would it make more obvious to give these values some sensible values.

[KiChjang]

bot merge