Open eskimor opened 1 month 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.
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.
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:
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.