Add storage size component to weights

[KiChjang]

This PR adds the long-awaited storage size weight component to the Weight struct in sp-weights.

Part of paritytech/polkadot-sdk#256.

[kianenigma]

This will need a migration?

[shawntabrizi]

yes. but the whole PR will need migration, since weight is now 2-dimensional, so good to have both of these changes in at once.

[ggwpez]

Just ideas and nits.

[ggwpez]

Just an idea: Could have opted for a private field iter, such that this becomes something like:

Suggested change

	Self {
	ref_time: self.ref_time.saturating_add(rhs.ref_time),
	proof_size: self.proof_size.saturating_add(rhs.proof_size),
	}
	self.fields_iter().map(|s| saturating_add(s, rhs)).collect::<Self>()

Then it is future proof when changing or adding fields. But could be overkill for now.

[KiChjang]

That also assumes that all fields are u64, which might not be the case in the future.

[ggwpez]

No... it just assumes that they are Saturating. This iter would probably not be a homogeneous collection but a custom type.
I just saw that my example code does not work, since it would need to be zipped with the rhs.fields_iter() first.

[KiChjang]

That, and the fact that all the fields must be homogeneous, because you're mapping over a collection of Items, which must have the same type.

[ggwpez]

Not sure if we could make this std only, since the runtime should not use unsafe math anyway.

[bkchr]

Not really unsafe math.

[ggwpez]

Is Rust not default implementing these?!

Suggested change

	*self = Self {
	ref_time: self.ref_time + other.ref_time,
	proof_size: self.proof_size + other.proof_size,
	};
	*self = *self + other

[ggwpez]

Suggested change

	*self = Self {
	ref_time: self.ref_time - other.ref_time,
	proof_size: self.proof_size - other.proof_size,
	};
	*self = *self - other

[BustaNit]

fmt lgtm

[bkchr]

Not really unsafe math.

[shawntabrizi]

needs migration before we can merge right?

[KiChjang]

What I just realized is that we don't need a CompactAs implementation when the fields of the Weight struct are compact by default. In that case, when Weight appears in a parameter of an extrinsic, no #[pallet::compact] is necessary at all.

[KiChjang]

What I'm not 100% certain about here is this: for 1D Weight structs that were originally marked with #[compact], would the above code be enough to migrate the old struct over to the new 2D Weight struct?

[ggwpez]

You could write a small test that encoded a WeightV1 and tries to decode it as new WeightV2. Probably need to account for the compact?

[KiChjang]

It is a bit difficult, since it requires a place where I can annotate #[pallet::compact], and the only place I know is within the parameters of a dispatchable function. I'm not sure exactly how I can encode a Weight in the old way and try decoding it in the new way -- you can't really suddenly change the Weight parameter to a 2D weight type from a 1D one, yeah?

[ggwpez]

I am not sure if i really understood your pain-point, but is this not enough?

#[test]
fn compact_weight_v1_can_be_decoded_as_v2() {
	use codec::{Decode, Encode, Compact};
	type WeightV1 = u64;

	let weight_v1: WeightV1 = 12345;
	let compact_weight_v1 = Compact(weight_v1);
	let encoded = Compact::<WeightV1>::encode(&compact_weight_v1);

	// Decode as weight v2
	let decoded: Weight = Decode::decode(&mut &encoded[..]).unwrap();
	assert_eq!(decoded.ref_time(), weight_v1);
}

[KiChjang]

It is not a bad unit test on its own, but it doesn't really test the #[pallet::compact] OldWeight to the NewWeight transition directly. This is important, as we don't know whether the bytes passed to decode is wrapped inside a Compact or that it's already been unwrapped.

[KiChjang]

bot merge

[nazar-pc]

Hm... this is really annoying for chains that don't have PoV, now I need to learn the concept which is not applicable to the chain whatsoever. Is there a chance to make it optional somehow?

[KiChjang]

You can do so by setting the max proof size to u64::MAX. The docs somewhere should mention this, but unsure where exactly.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-release-analysis/1026/2