glutton: also increase parachain block length

[sandreim]

Glutton currently is useful mostly for stress testing relay chain validators. It is unusable for testing the collator networking and block announcement and import scenarios. This PR resolves that by improving glutton pallet to also buff up the blocks, up to the runtime configured BlockLength.

How it works

Includes an additional inherent in each parachain block. The garbage argument passed to the inherent is filled with trash data. It's size is computed by applying the newly introduced block_length percentage to the maximum block length for mandatory dispatch class. After #4765 is merged, the length of inherent extrinsic will be added to the total block proof size.

The remaining weight is burnt in on_idle as configured by the storage percentage parameter.

TODO:

• PRDoc
• Readme update
• Add tests

[bkchr]

The inherent calll is a no-op and the PoV size increase is negligible as a large zeroed buffer compresses nicely.

So, this is still a sub optimal solution. You want to benchmark something and come up with something that will again "cheat" in some way.

[sandreim]

The inherent calll is a no-op and the PoV size increase is negligible as a large zeroed buffer compresses nicely.

So, this is still a sub optimal solution. You want to benchmark something and come up with something that will again "cheat" in some way.

That is a correct observation, PoV size is actually hard to control even without my change due to the compression. This is just a synthetic workload, from that perspective I consider it optimal solution for load testing. If we want real workload then glutton is not designed for it.

Later edit:

If we use random data in the inherent then we increase the PoV size further. I haven't checked yet to see if we hit max PoV size before max block size with this random data.

[bkchr]

If we use random data in the inherent then we increase the PoV size further. I haven't checked yet to see if we hit max PoV size before max block size with this random data.

I mean we don't need to fill it perfectly. We also should not try to "predict" this, but using some more random data, would be a better reproduction.

[burdges]

We definitely cannot pad with zeros since some compression occurs. Actual parablocks create Merkle proofs when they access state, so the bandwidth never winds up being independent from the computation. You could compute the Merkle root of some random data, but..

In fact, hash function compression functions have similar exucution times in the two modes: f(old_state,segment) -> new_state (blake2) or f(left,right) -> child (blake3). You could therefore just dump all this random data into blake2 once. Any big divergence from the real costs should be stuff we could better optimize anyways.

[sandreim]

We definitely cannot pad with zeros since some compression occurs. Actual parablocks create Merkle proofs when they access state, so the bandwidth never winds up being independent from the computation. You could compute the Merkle root of some random data, but..

This is a synthetic workload, but yeah not going yo use zeroes afterall. I will use trash data to make sure the block length going up increases the PoV size. There will be a:” block_length” config percentage which tells how much of max block length we want to use. Extra weight left will be consumed proportionately to “storage” parameter. This way we can do up to max block length parachain blocks. If “block_length” is zero current behaviour is kept: tiny parachain blocks that fully stress the relay chain - 2s exec and 5MB PoV.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable 2/3
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6459568