Rent Based Registration Model

[Szegoo]

This RFC proposes a new model for sustainable on-demand parachain registration, involving a smaller initial deposit and periodic rent payments.

Initial discussion on this topic can be found here

[eskimor]

Nice work!

[eskimor]

It is a soft form of deregistration though. ParaId is still claimed, only the PVF is pruned.

[Szegoo]

Yes, I think it can be called so. The main reason for this is to allow anyone to re-register the parachain under the same ParaId after it has been pruned.

Of course, there is always the option to perform a complete deregistration of a parachain by calling the deregister extrinsic.

[phillux]

@Szegoo thanks for putting together this RFC. Overall, deposits need to be adjusted regularly and be as cheap as possible while maintaining sybil resistance and DoS protection. I think the rent model makes sense but there are two issues I'm uncertain of:

1. Effectively this may be no different than lowering the cost-per-byte to a fraction of what it is now. From an attacker's point of view, they simply now can register multiple wasm blobs for the previous cost of one, then fail to pay rent later. Failing to pay the rent later is not an issue for an attacker in a DoS scenario.
2. Besides pruning, how is rent adjusted for runtime upgrades that add more bytes to their wasm blob?

For No. 2, this comes from a recent question I have not yet gotten a clear answer on, which is:

Can an attacker pay one deposit, get a parachain registered, then perform runtime upgrades once per block (or are they only allowed one per epoch?) that spams the validators on the network without registering a new or modified deposit?

Overall, I think the RFC takes a good approach by increasing cost-per-byte while lowering initial setup costs. Provided the issues I've raised are clarified or addressed, I'd fully support this RFC.

[Szegoo]

Effectively this may be no different than lowering the cost-per-byte to a fraction of what it is now. From an attacker's point of view, they simply now can register multiple wasm blobs for the previous cost of one, then fail to pay rent later. Failing to pay the rent later is not an issue for an attacker in a DoS scenario.

I don't think this is a problem since the attacker is risking their initial deposit.

Besides pruning, how is rent adjusted for runtime upgrades that add more bytes to their wasm blob?

This is a good point and I was a bit surprised to realize that the current implementation doesn't cover this scenario. The solution should probably be to simply request a deposit to cover the difference in the wasm blob size and based on that also re-adjust the recurring payment. I will add a new section to cover this. (Related issue: paritytech/polkadot-sdk#669 (comment))