# Push Kusama Limits with PoV / Weight Limit System Parachains **URL:** \ **Category:** Tech Talk\ **Created:** [November 14, 2022, 3:22pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068 "2022-11-14T15:22:29Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![joepetrowski](https://avatars.discourse-cdn.com/v4/letter/j/2acd7d/32.png) [@joepetrowski](https://forum.polkadot.network/u/joepetrowski)\ **Post date:** [November 14, 2022, 3:22pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/1 "2022-11-14T15:22:29Z")
It’s been a while since we encountered the limit on the number of parachains that a Relay Chain can handle. Further, not every parachain exhausts its PoV limits, meaning that the erasure coded chunks sent over the network are not their maximum size. So we don’t know how the Relay Chain will handle heavy usage on all the existing parachains. On a call today, an idea came up of creating a parachain runtime that has no transactional API, but has an `on_initialize` that scrambles some trie values and runs some computations such that the PoV size and time used are near or at the limits. These would simulate parachains under maximal load. We can then register multiple `ParaId`s of the same runtime until until Kusama starts to have problems. This would give us insight into a current reasonable max number of parachains and indicate where the next wave of optimizations should be focused. Some other ways we can experiment: - Increase the number of validators assigned to each parachain (e.g. from 5 to 10) - Have these limit parachains send messages over XCMP(-lite) to each other I opened this thread to see what other people think of the idea and if it’s worth pursuing. I think it’s quite aligned with Kusama’s role as canary network. ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [November 14, 2022, 10:33pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/2 "2022-11-14T22:33:44Z")
I like the idea leverage Kusama more and do some experiments and pushing some limits. Expect chaos! Just to make sure it is not too chaotic as we do have many live parachains running with some real tokens worth something. It probably won’t cost too much to spam current Kusama parachains and spamming XCMs so we might as well do it ourselves in a controlled manner. So we could do something like: - X testing common good parachain - Free transaction for whitelisted account only - Bots to spam the parachain with controlled manner (like how any load testing tool does) - Monitor the whole Kusama network at the same time - Shutdown the bots if other live parachain performance get impacted too much ---
**Author:** ![joepetrowski](https://avatars.discourse-cdn.com/v4/letter/j/2acd7d/32.png) [@joepetrowski](https://forum.polkadot.network/u/joepetrowski)\ **Post date:** [November 15, 2022, 6:34am UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/3 "2022-11-15T06:34:31Z")
Yeah, I like this idea as well. Right now we all assume (a) that one parachain’s activity has no effect on other parachains, and (b) that Kusama/Polkadot can support at least 45 parachains. But without them fully using their blockspace, we really don’t know that either of these are true. The thing that will be tough with transaction bots is that it will probably be easy to fill one dimension of weight (time or PoV size), but not both at the same time. But in reality, using a variety of testing strategies will probably yield the best results. So I think a mix of both our ideas (plus others if they’re out there) will be a good approach. ---
**Author:** ![xlc](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/xlc/32/690_2.png) [@xlc](https://forum.polkadot.network/u/xlc)\ **Post date:** [November 15, 2022, 8:09am UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/4 "2022-11-15T08:09:51Z")
We can totally have an extrinsic with two input parameters: compute & storages. ```rust fn fill_block(origin, compute: u32, storage: u32) { for _ in 0..compute { do_some_math() } for i in 0..storage { read_write_storaeg(i) } } ``` In that way we can have a good control of compute usage and proof size usage for each block and can try whatever scenarios we want. ---
**Author:** ![joepetrowski](https://avatars.discourse-cdn.com/v4/letter/j/2acd7d/32.png) [@joepetrowski](https://forum.polkadot.network/u/joepetrowski)\ **Post date:** [November 15, 2022, 2:23pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/5 "2022-11-15T14:23:07Z")
Yes, but the `read_write_storage` function takes time as well, so any compute needs to deduct the storage op time. ---
**Author:** ![kianenigma](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/kianenigma/32/6153_2.png) [@kianenigma](https://forum.polkadot.network/u/kianenigma)\ **Post date:** [November 18, 2022, 9:11am UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/6 "2022-11-18T09:11:18Z")
I am very confident if you describe this in a well defined issue in substrate and mention as `mentor`, our contributors will build the pallet/runtime 🙂 ---
**Author:** ![joepetrowski](https://avatars.discourse-cdn.com/v4/letter/j/2acd7d/32.png) [@joepetrowski](https://forum.polkadot.network/u/joepetrowski)\ **Post date:** [November 23, 2022, 8:41pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/7 "2022-11-23T20:41:52Z")
> > > As discussed in https://forum.polkadot.network/t/push-kusama-limits-with-pov-wei…ght-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. ---
**Author:** ![OliverTY](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/oliverty/32/2986_2.png) [@OliverTY](https://forum.polkadot.network/u/OliverTY)\ **Post date:** [November 23, 2022, 9:52pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/8 "2022-11-23T21:52:51Z")
Why does this need to happen in `on_initialize`? Could we not have a permissioned origin like `LoadTester` who can submit PoV heavy transactions? Using `on_initialize` for that seems dangerous to me. ---
**Author:** ![joepetrowski](https://avatars.discourse-cdn.com/v4/letter/j/2acd7d/32.png) [@joepetrowski](https://forum.polkadot.network/u/joepetrowski)\ **Post date:** [November 24, 2022, 6:58am UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/9 "2022-11-24T06:58:27Z")
I think we need to test constant load, because we would want to add several of these parachains until Kusama breaks to find what the next limiting factor is. If you have 10 of these, then it’d be impossible to ensure that they’re all getting hit at the same time if you rely on a `LoadTester` to submit calls. Not saying an implementation _must_ use `on_initialize`, but it was my first thought. We could order the pallets such that the DMP queue gets processed first and could have a `LoadTester` origin from the Relay Chain that says “fill blocks to (s%, t%)” (space, time). So if the network got congested then Kusama could send a message to back off. ---
**Author:** ![OliverTY](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/oliverty/32/2986_2.png) [@OliverTY](https://forum.polkadot.network/u/OliverTY)\ **Post date:** [November 24, 2022, 12:08pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/10 "2022-11-24T12:08:54Z")
> We could order the pallets such that the DMP queue gets processed first and could have a `LoadTester` origin from the Relay Chain that says “fill blocks to (s%, t%)” (space, time). Or we limit the number of blocks that it goes on for. So like your "fill blocks to (space%, time%)” but for at most `x` blocks and then stop. Otherwise we nuke the network with no way of stopping it. But yea, having a way to stop it before `x` blocks could also be good. Just thinking out loud: Would the `on_idle` not be the perfect fit? ---
**Author:** ![joepetrowski](https://avatars.discourse-cdn.com/v4/letter/j/2acd7d/32.png) [@joepetrowski](https://forum.polkadot.network/u/joepetrowski)\ **Post date:** [November 24, 2022, 12:32pm UTC](https://forum.polkadot.network/t/push-kusama-limits-with-pov-weight-limit-system-parachains/1068/11 "2022-11-24T12:32:55Z")
> [@OliverTY](#): > > Just thinking out loud: Would the `on_idle` not be the perfect fit? Yeah, that is a good idea, probably better indeed. By setting (space%, time%) and configuring the number of paras, we should be able to do things like: - Set all to (50, 50) and see how many paras we can add until things break - Set some to (100, 0) and (0, 100) and see if some have problems (I’d expect network to be a bottleneck on large size PoVs but not on compute, but maybe running secondary checks is the bottleneck on compute).