-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rental model for storing PVF #1971
Conversation
The CI pipeline was cancelled due to failure one of the required jobs. |
BTW, this should really be done as a RFC. |
<T as Config>::Currency::reserve(&who, rent_info.rent_cost)?; | ||
|
||
let now = shared::Pallet::<T>::session_index(); | ||
rent_info.last_rent_payment = now; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if the next rent gets paid, before the old expired? Shouldn't this be set to now + remaining
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, this should be set to now + remaining
. (NOTE: This is still an early draft :))
@@ -395,15 +398,17 @@ impl<T: Config> Pallet<T> { | |||
// the back of the claimqueue. | |||
for drop in dropped_claims { | |||
match T::AssignmentProvider::pop_assignment_for_core(core_idx, drop) { | |||
Some(assignment) => { | |||
Some(assignment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving this as a defensive check might make sense, but I feel like this should be checked earlier in the process. E.g. for on-demand an order should be deemed invalid if rent has not been paid.
The associated RFC: polkadot-fellows/RFCs#44 |
Going to close based on the discussion from last week at the fellowship meetup. |
The PR aims to implement a rental payment mechanism for storing PVF for on-demand paras, reducing the initial cost of registering a para and paying for PVF storage
The plan is to have a smaller initial payment compared to regular PVF registration. However, an additional rent must be paid every
T::RentDuration
period.In case the rent is not paid, the scheduler won't assign the para anymore, and it will be moved into the 'hibernation' stage. During this period, the PVF is still stored on-chain for an entire session in case it is needed for approval checking or disputes.
Once the para is no longer in the 'hibernation' stage, the 'prune_para' extrinsic can be called by anyone, and the caller will receive the initial deposit as a reward.
This PR is in its early draft stage and a work in progress.
This is part of: #1796 where more information can be found related to this.