search

polkadot-fellows / RFCs

Proposals for change to standards administered by the Fellowship.
https://polkadot-fellows.github.io/RFCs/
Creative Commons Zero v1.0 Universal
111 stars 51 forks source link

Rent Based Registration Model #44

Open Szegoo opened 8 months ago

Szegoo commented 8 months ago

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

phillux commented 8 months ago

@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 commented 8 months ago

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: https://github.com/paritytech/polkadot-sdk/issues/669#issuecomment-1798487994)