-
Notifications
You must be signed in to change notification settings - Fork 2.6k
PoV Limit Pallet #12772
Comments
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 |
Argon2 is good if you need to hit ram lots, but you may need to hit storage really. |
cc @Szegoo ;) ? |
@kianenigma I would like to tackle this issue if it is not urgent since I am a bit sick at the moment :/ |
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. |
@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? |
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. |
We need to do two things: Runtime Storage access to inflate the PoV and wasting some Computation time (PoW). 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. |
@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 |
@joepetrowski Now that the Glutton pallet has been merged what are the further plans? I assume the work on the Glutton parachains will continue on the Cumulus repository, but I couldn't find any PRs over there so I was wondering if there is some work being done regarding this at the moment. |
Yes, the future plans are to make a new parachain runtime and deploy to Kusama. I am planning to open a PR (although you are welcome to :)), but am currently waiting for the dust to settle on (a) upgrading current system para XCM configs/tests to XCM v3 and (b) move of runtimes to the Polkadot Fellowship control. Once we release a runtime then I will make a referendum on Kusama to register the first glutton parachain. |
Sure, I would like to write the Glutton parachain runtime :) |
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-release-analysis-v0-9-39/2277/1 |
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:system.set_storage
that will consume the PoV size,for
loop performing arbitrary computation like hashing values to consume any remaining time limit.The text was updated successfully, but these errors were encountered: