7

I have no idea why this call uses such a lot proof size (around 4MB).

It looks like it doesn't change too many storage items.

https://github.com/darwinia-network/darwinia-messages-substrate/blob/e5d24b2fa56abf512fe944a7ab22ecd21f0eed66/modules/grandpa/src/lib.rs#L166

https://github.com/darwinia-network/darwinia/blame/fc35306420e515de56575c483c6fcfe8b357b285/runtime/crab/src/weights/pallet_bridge_grandpa.rs#L78

Improve this question

1 Answer 1

Reset to default
3

You can see where the bulk part comes from:

BridgePolkadotGrandpa CurrentAuthoritySet (max_values: Some(1), max_size: Some(4000012), added: 4000507, mode: MaxEncodedLen)

It is using the MaxEncodedLen of that type to calculate the worst-case proof size. You configured MaxBridgedAuthorities to be 100k.
That means it will assume the worst case to have 100k entries in the authority set - therefore resulting in 4 MB, which seems to be in line with 40 byte per authority from here.
I am not sure why 100k (or if that is a good number) but it should be possible to do post-dispatch correction with the unused_proof_size function to refund the unused Proof weight.

The MaxEncodedLen is used since that represents the worst case. Note that benchmarking always has to consider the worst case scenario. There exists an alternative benchmarking mode; measured that will use the size of the actual accessed storage elements and add some overhead estimations on top. It looks like this: #[pov_mode = Measured] but should not be needed in 99% of cases.

Improve this answer
5
  • I still feel weightv2 is very unstable and dangerous. Our production chain encountered this. Please check this github.com/darwinia-network/darwinia/blob/…. This is crazy, we don't have sudo, and democracy use pallet-scheduler. Any schedule will fail. And we can't do runtime upgrade to fix this (because runtime upgrade requires a scheduler if there is no sudo). And this exists in official release polkadot-v0.9.40 branch.
    – AurevoirXavier
    Jun 16 at 14:04
  • Finally, we found that there is an inline preimage option. It could bypass the scheduler weight checks.
    – AurevoirXavier
    Jun 16 at 14:06
  • Thanks for your answer! And I want to learn more detail about how benchmark works to generate this. E.G. Why does it use MaxEncodedLen to calculate the size?
    – AurevoirXavier
    Jun 16 at 14:26
  • That weight for the scheduler looks wrong indeed. but you are running the benchmarking with STEPS: 2, REPEAT: 1 that does not make any sense. It should indeed depend on s, which it also does in polkadot-v0.9.40. I will extend the answer later.
    – Oliver Tale-Yazdi
    Jun 16 at 15:49
  • I added some sanity checks here that should error before that happens again github.com/paritytech/substrate/pull/14408
    – Oliver Tale-Yazdi
    Jun 16 at 16:21

Your Answer

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

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