On-demand & Coretime parachain upgrade fees

[Szegoo]

Summary

When a parachain is registered, the parachain manager is responsible for the cost of storing the validation code on-chain. After successful registration in the current system, parachains are allowed to perform code upgrades without being required to pay for the differences in validation code size. This means that someone could theoretically register a parachain with minimal code and then, at a later point, freely register validation code that is significantly larger than the original code.

This is obviously a problem that needs to be fixed, as being imprecise about the deposit requirements for storing data on-chain can lead to issues in the system.

Additionally, this PR introduces a 'code upgrade fee', that is charged whenever an upgrade is scheduled. This is used to discourage parachains from spamming code upgrades.

Paying for para upgrades

All on-demand and Coretime parachains will be charged for performing validation code upgrades. Upon registration, the billing account responsible for covering the deposit and paying upgrade fees is set to None.
Before scheduling code upgrades the billing account has to be explicitly set by calling the set_parachain_billing_account_to_self extrinsic which will allow setting the billing account to either the sovereign account or the manager.

Whenever the billing account of a parachain changes, the new account will have the entire required deposit reserved, and the previous account will have its associated deposit unreserved.

Rebate

If the new required deposit for storing the validation code changes during a code upgrade, the billing account will receive a refund once the upgrade is successfully performed

System & Lease holding parachains

Since we want to avoid causing a breaking change, all current lease-holding parachains that are registered will be eligible to continue performing code upgrades without any costs.

Since this PR allows Root to perform upgrades for free, it also means all system chains do not require any code upgrade costs.

Additional benefits

These additional deposit requirements will enable us to reduce the deposit needed for reserving a ParaId. Without this change, if we significantly lower it, there's a risk of making it cheap to exploit the network by registering a bunch of paras with small validation codes and then upgrading them for free to a much larger size.

Should Close: #669

TODOs:

• Add events
• Improve docs
• Merge BillingInfo into ParaInfo
• Add test to ensure that the billing account has to be explicitly set for lease holding paras
• Clean up the code
• Generate weights
• Update PR description to explain the setting of the billing account in more detail

[eskimor]

Looks sensible on a quick fist pass. 🚀

[Szegoo]

@eskimor @antonva The PR should be ready for a review now :)

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/4958532

[eskimor]

I just realized that this is too late. We need to drop the candidate in backing already, but in a way that should be safe. Mainly there exists a mechanism for this already: UpgradeRestrictionSignal. If an upgrade is not allowed for whatever reason this signal should be set. This is read by the parachain and it won't even try (which is mandatory otherwise it would be bricked, if we only had the filtering of candidates here, called here from verify_backed_candidate).

Reason being: If we only drop the upgrade in inclusion we did not actually prevent the spam vector, as most of the work has already been done. Most importantly a relay chain block was already filled with megabytes of data, affecting other candidates.

Also we should update the guide as well. In particular I forgot again why we need fees at all:

1. Deposit is large for large runtimes.
2. Frequency of updates is limited by cool down.
3. Block validation is already being paid for.

I think the major reason is that upgrading a runtime is rather costly, not only in terms of block utilization (size), but also because of pre-checking. This essentially breaks sharding (all validators do it). So it makes sense to be a bit cautious here. The more important part of this PR is surely that we adjust the deposit.

[eskimor]

In order to not delay this further, let's make this a follow up.

[bkchr]

I just realized that this is too late. We need to drop the candidate in backing already, but in a way that should be safe. Mainly there exists a mechanism for this already: UpgradeRestrictionSignal. If an upgrade is not allowed for whatever reason this signal should be set. This is read by the parachain and it won't even try (which is mandatory otherwise it would be bricked, if we only had the filtering of candidates here, called here from verify_backed_candidate).

This is not really true, UpgradeRestrictionSignal is for telling the parachain that it is currently not allowed to do an upgrade. However, we currently have no way to signal that we want to do an upgrade to the relay chain without sending the full new wasm. You are right that the spam vector isn't closed with the current implementation and we should fix it. I mean we could maybe abuse UpgradeRestrictionSignal, but then we should entirely drop the dynamic reserve based on the size of the wasm blob. We should instead charge a constant fee for this (probably just based on the maximum blob size). Then we could use the UpgradeRestrictionSignal to communicate if the billing account has the required UpgradeFee. But yeah, still not a super solution. Someone could still announce an upgrade and move the funds in between backing and availability.

The real proper solution is really to rewrite the current signaling to the relay chain to first only announce the size plus hash of the blob. Then we should reserve the amount on the billing account and signal that it is okay to send the code.

[eskimor]

Fixed deposit would be indeed a lot simpler, I see two downsides with it:

1. People are not incentivized to save space.
2. If we ever increase the limit, those earlier parachains can now increase their size for free.

both are not dramatic and also if we would ever find those to be a problem we can still write code to adjust it on upgrades.

I hate to say this, but maybe we should just adjust the deposit to fixed maximum for now and get back to this later, e.g. with me actually writing a solid design for this first (proper signaling, actual concerns, potential solutions, actually picked solution with reason) and ideally also then also clean up the code while we are at it.

[Szegoo]

Probably a dumb question, but what if we restricted code upgrades to only be scheduled from the registrar pallet through the extrinsic? This way the spam vector wouldn't be possible.

[eskimor]

Maybe let's see what @eskimor thinks.

I had similar thoughts: Is the complexity really worth it?

@Szegoo has a very good point about incentivization: If the upgrade costs something, then we incentivize teams to not "needlessly" upgrade, which is very sensible as there is a significant cost for the network. But I like @bkchr idea of having a very long cooldown period (which is enforced also on failed upgrades) and then you could optionally pay to reduce the cooldown. This would get us all the benefits, without risking irritation about having to set up some account and stuff. People would only need to look into it once they are unhappy with the cooldown time.

So the simplest way forward would be:

Phase 1:

1. Make the deposit always account for the maximum code size.
2. Increase cooldown period .... actually this is also something we would need to communicate ... but likely less irritating than suddenly having to setup an account.
3. Make cooldown to also be enforced on failed updates.

Phase 2:

Then we can have a second (not time critical) phase:

This phase is then merely an optimization, as opposed to a necessity. Hence we should also write an RFC here (design document), highlighting exactly all the requirements and options considered.

4. Find good solution for deposit size: Having it dependent on actual size is a good thing in general as it just aligns incentives with cost, leading to better utilization of resources.
5. Implement/adjust what we already have in this PR to enable being able to pay for a reduced cooldown.
6. See downsides: For rent based model/reduced deposit fees, upgrade fees might be mandatory.

Downsides

If we don't charge for upgrades (usually), then this also increases pressure on deposits not getting too low. As deposits then serve two purposes:

1. Limit state used (obviously).
2. Limit number of upgrades that can happen (together with cooldown)

Phase 1: Should be fast to implement ... if not, maybe we can rely on the large deposit for now and move (2) and (3) to phase 2 as well. Just changing the deposit calculation (making it bigger) should not even require a security audit.

[eskimor]

For the rent based model. Indeed there was quite some confusing on pruning, I don't think Gav nor Shawn understood what was actually meant here. Pruning was specifically designed to not be able to break anything - at least not anymore than an ending lease would for example.

The real question whether the rent based model is feasible is, whether we are for security mostly relying on the opportunity costs of the provided deposit or the actually locked capital. In a very first analysis of mine, it is unfortunately in part also the amount of locked capital: Basically if you fill up the storage, managing to degrade the service enough, this would have an impact on the price of DOT, so your deposited DOT would decrease in value -> Disincentivizing the attack.

[eskimor]

For moving forward in launching coretime on Kusama, @Szegoo would you be interested into implementing phase 1? Phase 1 MVP, would entail only changing the deposit amount to the maximum PVF size.

[bkchr]

3. Make cooldown to also be enforced on failed updates.

This is already the case, at least I checked this last week. We set the cooldown before we kick off the pvf check.

[Szegoo]

@Szegoo would you be interested into implementing phase 1?

Yes, I will open a PR for that.