search

paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.com/
1.94k stars 710 forks source link

Reduce storage deposit for parachain PVFs #5012

Open eskimor opened 4 months ago

eskimor commented 4 months ago

We would like to reduce the amount of locked token needed for PVF (Parachain Validation Function), but this comes with a number of challenges that need to be resolved first:

  1. https://github.com/paritytech/polkadot-sdk/issues/4737
  2. (Re-)preparing artifacts for thousands of PVFs might take too much time, e.g. on executor parameter changes: Solution 2.1. Migrate to PolkaVM (Instant preparation) 2.2. Only enact executor paramater changes after valiators confirmed that they have the artifacts prepared with the new parameters prepared already.
  3. Thousands of registered PVFs and flexible coretime would allow for the possibility of lot's of runtime upgrades to happen at the same time, causing DoS/reduced service to other parachains. See RFC-102 for a suggested solution.
  4. Anything else?

Further Improvements

Once we brought storage deposits down (with off-chain storage we also actually bring real costs down), we should also reduce the minimum fee for on-demand, given how low bulk cores are sold right now on Kusama.

s0me0ne-unkn0wn commented 4 months ago

Only enact executor paramater changes after valiators confirmed that they have the artifacts prepared with the new parameters prepared already.

A closely related discussion: https://github.com/paritytech/polkadot-sdk/pull/4791#discussion_r1647962487

Indeed, if we have in-advance preparation and we already know executor params for the next session, we have a whole session worth of time to prepare the PVFs. Preparing a lot of them will still be slow, but given the session times on the production networks, it would probably suffice. Then we wouldn't need the separate logic for postponed executor params enactment.

kianenigma commented 4 months ago
  1. What will happen today if all parachains switch to on-demand, and schedule themselves somewhat unpredictably? how hard is it for validators to prepare the wasms, offload, etc
  2. What is the breakdown for the current deposit that's needed?
burdges commented 4 months ago

We've always wanted all artifacts built in advance, preferably an epoch in advance. Afaik we'll never change this goal, not even for polkavm, and https://github.com/paritytech/polkadot-sdk/pull/4791 improves this. We could simply rate limit code upgrades for 3 above, but https://github.com/polkadot-fellows/RFCs/pull/102 includes some tunable cost for upgrades.

I'd think the deposit cost would represent the actual storage for artifact and bytecode. In principle, the deposit would partially cover build costs incurred by validator churn and executor params churn. I suppose governance eats the executor params churn costs morally, meaning some slowdown becomes acceptable. Also newly ellected validators spend the build time during their ellection, so again whatever.