PoV Limit Pallet

[joepetrowski]

As discussed in https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068, we could write a pallet whose on_initialize would consume up to the weight limit of the block (or some percentage as a config parameter). For parachains with PoV and execution time limits, this could roughly look like:

1. Call(s) to system.set_storage that will consume the PoV size,
2. Some for loop performing arbitrary computation like hashing values to consume any remaining time limit.

[Polkadot-Forum]

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

https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/7

[burdges]

Argon2 is good if you need to hit ram lots, but you may need to hit storage really.

[kianenigma]

cc @Szegoo ;) ?

[Szegoo]

@kianenigma I would like to tackle this issue if it is not urgent since I am a bit sick at the moment :/

[sandreim]

I think the pallet approach is better than what we have already built as a test parachain for ZombieNet tests: https://github.com/paritytech/polkadot/blob/master/parachain/test-parachains/undying/collator/src/cli.rs#L67

We're planning to deploy it soon on Versi to test the limits when parachains actually do something.

[Szegoo]

@burdges If we were to use Argon2 we would need a new dependency(e.g. https://docs.rs/rust-argon2/latest/argon2/), would that be ok?

[burdges]

Yeah why not? You can use any memory hard hash function, but they'd all bring an external dependency, and this is all testing so who cares about the dependencies anyways? You're not adding a host call, just building it in WASM.

We'll need to do something else when you want to hit storage lots.

[ggwpez]

We need to do two things: Runtime Storage access to inflate the PoV and wasting some Computation time (PoW).
There is no need for special case hash functions. We can just use blake2 or whatever for the Compute time and use storage::unhashed::get to inflate the PoV.

You probably need to reverse-calculate how many iterations of the hash function need to happen to acquire a specific CPU time amount, but that should be possible with one division.

Another thing to consider: Once this goes live we have to make sure not to ramp it up too quickly since this could result in a lot of validator slashes if they are using sub-par hardware.

[Szegoo]

You probably need to reverse-calculate how many iterations of the hash function need to happen to acquire a specific CPU time amount, but that should be possible with one division.

@ggwpez I was originally thinking of writing a benchmark for the function that does the hashing so that we can calculate how many times should it be called for the specified weight percentage of the max block weight. But since it is not a good idea to call extrinsics from on_initialize I will do your suggestion.