From 572e887e171e7ffeef07be957f695bc0738a0ec2 Mon Sep 17 00:00:00 2001 From: Szegoo Date: Fri, 3 Nov 2023 17:24:29 +0100 Subject: [PATCH 1/8] incomplete --- 0000-template.md | 59 ------ text/0000-rent-based-para-registration.md | 207 ++++++++++++++++++++++ 2 files changed, 207 insertions(+), 59 deletions(-) delete mode 100644 0000-template.md create mode 100644 text/0000-rent-based-para-registration.md diff --git a/0000-template.md b/0000-template.md deleted file mode 100644 index e5086b97a..000000000 --- a/0000-template.md +++ /dev/null @@ -1,59 +0,0 @@ -# RFC-0000: Feature Name Here - -| | | -| --------------- | ------------------------------------------------------------------------------------------- | -| **Start Date** | Date of initial proposal | -| **Description** | One-sentence description | -| **Authors** | | - -## Summary - -One paragraph summary of the RFC. - -## Motivation - -Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution. - -## Stakeholders - -A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal. - -## Explanation - -Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements. - -## Drawbacks - -Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. - -## Testing, Security, and Privacy - -Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. - -## Performance, Ergonomics, and Compatibility - -Describe the impact of the proposal on the exposed functionality of Polkadot. - -### Performance - -Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? - -### Ergonomics - -If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? - -### Compatibility - -Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. - -## Prior Art and References - -Provide references to either prior art or other relevant research for the submitted design. - -## Unresolved Questions - -Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. - -## Future Directions and Related Material - -Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. diff --git a/text/0000-rent-based-para-registration.md b/text/0000-rent-based-para-registration.md new file mode 100644 index 000000000..0c2d6311d --- /dev/null +++ b/text/0000-rent-based-para-registration.md @@ -0,0 +1,207 @@ +# RFC-0000: New model for PVF storage + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | Date of initial proposal | +| **Description** | A new rental model for storing PVF on-chain. | +| **Authors** | Sergej Sakac | + +## Summary + +This RFC proposes a new model for a sustainable on-demand parachain registration, involving a smaller initial deposit and periodic rent payments. The new model considers that on-demand chains may be unregistered and later re-registered. The proposed solution also ensures a quick startup for on-demand chains on Polkadot in such cases. + +## Motivation + +With the support of on-demand parachains on Polkadot, there is a need to explore a new, more cost-effective model for registering validation code. In the current model, the parachain manager is responsible for reserving a unique `ParaId` and covering the cost of storing the validation code of the parachain. These costs can escalate, particularly if the validation code is large. We need a better, sustainable model for registering on-demand parachains on Polkadot to help smaller teams deploy more easily. + +This RFC suggests a new payment model to create a more financially viable approach to parathread registration. In this model, a lower initial deposit is required, followed by recurring payments upon parathread registration. + +This new model will coexist with the existing one-time deposit payment model, offering teams seeking to deploy on-demand parachains on Polkadot a more cost-effective alternative. + +## Requirements + +1. The solution SHOULD NOT affect the current model for registering validatoin code. +2. The solution SHOULD offer an easily configurable way for governance to adjust the initial deposit and recurring rent cost. +3. The solution SHOULD provide an incentive to prune validation code for which rent is not paid. +4. The solution SHOULD allow anyone to re-register validation code under the same `ParaId` without the need for redundant pre-checking if it was already verified before. +5. The solution MUST allow anyone to pay the rent. +6. The solution MUST prevent the removal of validation code if it could still be required for disputes or approval checking. + +## Stakeholders + +- Future Polkadot on-demand Parachains + +## Explanation + +This RFC proposes a set of changes that will enable the new rent based approach to registering and storing validation code on-chain. Importantly, this solution doesn't require any storage migrations in the current system. The following provides a detailed description of this solution. + +On-demand parachains should still be able to utilize the current one-time payment model. However, given the size of the deposit required, it's highly likely that most on-demand parachains will opt for the new rent-based model. + +### Registering an on-demand parachain + +In the current implementation of the registrar pallet, there are two constants that specify the necessary deposit for parachains to register and store their validation code: +```rust +/// The deposit required for reserving a `ParaId`. +#[pallet::constant] +type ParaDeposit: Get>; + +/// The deposit to be paid per byte stored on chain. +#[pallet::constant] +type DataDepositPerByte: Get>; +``` + +This RFC proposes the addition of three new constants that will determine the payment amount and the frequency of the recurring rent payment: +```rust +/// Defines how frequently the rent needs to be paid. +/// +/// The duration is set in sessions instead of block numbers. +#[pallet::constant] +type RentDuration: Get; + +/// The initial deposit amount for reserving a `ParaId` +/// +/// This is defined as a percentage of the deposit that would be required in the regular +/// model. +#[pallet::constant] +type InitialRentDeposit: Get; + +/// The recurring rental cost as a percentage of the initial rental registration deposit. +#[pallet::constant] +type RecurringRentCost: Get; +``` + +Users will be able to reserve a `ParaId` and register their validation code for a percentage of the regular deposit required. However, they must also make additional rent payments at intervals of `T::RentDuration`. + +For registering using the new rental system we will have to make modifications to the `paras-registrar` pallet. We should expose two new extrinsics, as well as make a small modification to the existing `reserve` extrinsic: +```rust +#[pallet::call_index(5)] +#[pallet::weight(::WeightInfo::reserve())] +pub fn reserve(origin: OriginFor, rent_based_payment: bool) -> DispatchResult { + // The logic remains the same; however, if `rent_based_payment` is true, the + // required deposit is only `T::InitialRentDeposit` percent of `T::ParaDeposit`. +} + +pub fn register_rental( + origin: OriginFor, + id: ParaId, + genesis_head: HeadData, + validation_code: ValidationCode, +) -> DispatchResult { /* ... */ } + +pub fn pay_rent(origin: OriginFor, id: ParaId) -> DispatchResult { + /* ... */ +} +``` + +A call to `register_rental` will require the reservation of only a percentage of the deposit that would otherwise be required to register the validation code when using the regular model. +As described later in the *Quick para re-registering* section below, we will also store the code hash and the head data of each parachain to enable faster re-registration after a parachain has been pruned. For this reason the total initial deposit amount is increased to account for that. +```rust +let validation_code_deposit = T::ParaDeposit::get() + .saturating_add(per_byte_fee.saturating_mul((validation_code.0.len() as u32).into())); + +let head_deposit = per_byte_fee.saturating_mul((genesis_head.0.len() as u32).into()) +let hash_deposit = per_byte_fee.saturating_mul(HASH_SIZE); + +let deposit = T::InitialRentDeposit::get().mul_ceil(validation_code_deposit) + .saturating_add(head_deposit) + .saturating_add(hash_deposit) +``` +Once the `ParaId` is reserved and the validation code is registered the rent must be periodically paid to ensure the on-demand parachain doesn't get removed from the state. The `pay_rent` extrinsic should be callable by anyone. + +### On-demand parachain pruning + +If the rent is not paid, anyone has the option to prune the on-demand parachain and claim the initial deposit as a reward, minus the deposit for storing the validation code hash and the head data, as that won't be removed after the pruning operation. + +The moment the rent is no longer paid, the parachain won't be able to purchase on-demand access, meaning no new blocks are allowed. This stage is called the "hibernation" stage, during which all the parachain-related data is still stored on-chain, but new blocks are not permitted. The reason for this is to ensure that the validation code is available in case it is needed in the dispute or approval checking subsystems. Waiting for one entire session will be enough to ensure it is safe to deregister the parachain. + +This means that anyone can prune the parachain only once the "hibernation" stage is over, which lasts for an entire session after the moment that the rent is not paid. + +### Ensuring rent is paid +The `paras` pallet will be loosely coupled with the `para-registrar` pallet through a `RentStatusProvider` trait. This approach enables all the pallets tightly coupled with the `paras` pallet to have access to the rent status information. + +```rust +pub trait RentStatusProvider { + /// Checks whether the rent is paid for storing the PVF on-chain. + /// + /// In case the parachain is registered using the regular registration model + /// this will simply return true. + fn rent_paid(id: ParaId) -> bool; +} +``` + +Once the validation code is stored without having its rent paid the `assigner_on_demand` pallet will ensure that an order for that parachain cannot be placed. This is easily achievable given that the `assigner_on_demand` pallet is tightly coupled with the `paras` pallet. + +### Quick para re-registration + +If the rent isn't paid on time, and the parachain gets pruned, the new model should provide a quick way to re-register the same validation code under the same `ParaId`. This can be achieved by skipping the pre-checking process. + +This will be accomplished by introducing a new storage map within the `paras` pallet. The reason for not utilizing the existing `CurrentCodeHash` storage map is because it contains code hashes associated with non pre-checked validation code. + +```rust +/// Stores the validation code hash and head data for parachains that successfully completed the +/// pre-checking process. +/// +/// This is stored to enable faster on-demand para re-registration in case its pvf has been earlier +/// registered and checked. +/// +/// NOTE: During a runtime upgrade where the pre-checking rules change this storage map should be +/// cleared. +#[pallet::storage] +#[pallet::getter(fn checked_code_hash)] +pub(super) type CheckedParachains = + StorageMap<_, Twox64Concat, ParaId, (ValidationCodeHash, HeadData)>; +``` + +To perform a parachain re-registration, we can adapt the existing `register` extrinsic with a few necessary adjustments. The modified extrinsic will include a new argument that indicates the caller's intention to re-register the parachain. + +```rust +#[pallet::call_index(0)] +#[pallet::weight(::WeightInfo::register())] +pub fn register( + origin: OriginFor, + id: ParaId, + genesis_head: HeadData, + validation_code: ValidationCode, + reregistering: bool, +) -> DispatchResult { + // If the `reregistering` parameter is set to true, it's not necessary for the caller to be + // the para manager. In this case, the caller only needs to cover the initial deposit + // required for storing the validation code. +} +``` + +## Drawbacks + +TODO + +## Testing, Security, and Privacy + +Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. + +## Performance, Ergonomics, and Compatibility + +Describe the impact of the proposal on the exposed functionality of Polkadot. + +### Performance + +Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? + +### Ergonomics + +If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? + +### Compatibility + +Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. + +## Prior Art and References + +Provide references to either prior art or other relevant research for the submitted design. + +## Unresolved Questions + +Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. + +## Future Directions and Related Material + +Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. From 9b455114a166ce7b9576a978e409288f705953c1 Mon Sep 17 00:00:00 2001 From: Szegoo Date: Mon, 6 Nov 2023 09:23:30 +0100 Subject: [PATCH 2/8] update --- 0000-template.md | 59 ++++++ ...ion.md => 0044-rent-based-registration.md} | 179 +++++++++--------- 2 files changed, 146 insertions(+), 92 deletions(-) create mode 100644 0000-template.md rename text/{0000-rent-based-para-registration.md => 0044-rent-based-registration.md} (53%) diff --git a/0000-template.md b/0000-template.md new file mode 100644 index 000000000..e5086b97a --- /dev/null +++ b/0000-template.md @@ -0,0 +1,59 @@ +# RFC-0000: Feature Name Here + +| | | +| --------------- | ------------------------------------------------------------------------------------------- | +| **Start Date** | Date of initial proposal | +| **Description** | One-sentence description | +| **Authors** | | + +## Summary + +One paragraph summary of the RFC. + +## Motivation + +Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution. + +## Stakeholders + +A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal. + +## Explanation + +Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements. + +## Drawbacks + +Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. + +## Testing, Security, and Privacy + +Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. + +## Performance, Ergonomics, and Compatibility + +Describe the impact of the proposal on the exposed functionality of Polkadot. + +### Performance + +Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? + +### Ergonomics + +If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? + +### Compatibility + +Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. + +## Prior Art and References + +Provide references to either prior art or other relevant research for the submitted design. + +## Unresolved Questions + +Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. + +## Future Directions and Related Material + +Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. diff --git a/text/0000-rent-based-para-registration.md b/text/0044-rent-based-registration.md similarity index 53% rename from text/0000-rent-based-para-registration.md rename to text/0044-rent-based-registration.md index 0c2d6311d..5ef057f4e 100644 --- a/text/0000-rent-based-para-registration.md +++ b/text/0044-rent-based-registration.md @@ -1,9 +1,9 @@ -# RFC-0000: New model for PVF storage +# RFC-0044: Rent based registration model | | | | --------------- | ------------------------------------------------------------------------------------------- | -| **Start Date** | Date of initial proposal | -| **Description** | A new rental model for storing PVF on-chain. | +| **Start Date** | 6 November 2023 | +| **Description** | A new rent based parachain registration model | | **Authors** | Sergej Sakac | ## Summary @@ -14,7 +14,7 @@ This RFC proposes a new model for a sustainable on-demand parachain registration With the support of on-demand parachains on Polkadot, there is a need to explore a new, more cost-effective model for registering validation code. In the current model, the parachain manager is responsible for reserving a unique `ParaId` and covering the cost of storing the validation code of the parachain. These costs can escalate, particularly if the validation code is large. We need a better, sustainable model for registering on-demand parachains on Polkadot to help smaller teams deploy more easily. -This RFC suggests a new payment model to create a more financially viable approach to parathread registration. In this model, a lower initial deposit is required, followed by recurring payments upon parathread registration. +This RFC suggests a new payment model to create a more financially viable approach to on-demand parachain registration. In this model, a lower initial deposit is required, followed by recurring payments upon parachain registration. This new model will coexist with the existing one-time deposit payment model, offering teams seeking to deploy on-demand parachains on Polkadot a more cost-effective alternative. @@ -24,8 +24,9 @@ This new model will coexist with the existing one-time deposit payment model, of 2. The solution SHOULD offer an easily configurable way for governance to adjust the initial deposit and recurring rent cost. 3. The solution SHOULD provide an incentive to prune validation code for which rent is not paid. 4. The solution SHOULD allow anyone to re-register validation code under the same `ParaId` without the need for redundant pre-checking if it was already verified before. -5. The solution MUST allow anyone to pay the rent. -6. The solution MUST prevent the removal of validation code if it could still be required for disputes or approval checking. +5. The solution MUST be compatible with the Agile Coretime model, as described in RFC#0001 +6. The solution MUST allow anyone to pay the rent. +7. The solution MUST prevent the removal of validation code if it could still be required for disputes or approval checking. ## Stakeholders @@ -33,109 +34,110 @@ This new model will coexist with the existing one-time deposit payment model, of ## Explanation -This RFC proposes a set of changes that will enable the new rent based approach to registering and storing validation code on-chain. Importantly, this solution doesn't require any storage migrations in the current system. The following provides a detailed description of this solution. +This RFC proposes a set of changes that will enable the new rent based approach to registering and storing validation code on-chain. +The new model, compared to the current one, will require periodic rent payments. The parachain won't be pruned automatically if the rent is not paid, but by permitting anyone to prune the parachain and rewarding the caller, there will be an incentive for the removal of the validation code. On-demand parachains should still be able to utilize the current one-time payment model. However, given the size of the deposit required, it's highly likely that most on-demand parachains will opt for the new rent-based model. +Importantly, this solution doesn't require any storage migrations in the current system nor does it introduce any breaking changes. The following provides a detailed description of this solution. + ### Registering an on-demand parachain In the current implementation of the registrar pallet, there are two constants that specify the necessary deposit for parachains to register and store their validation code: ```rust -/// The deposit required for reserving a `ParaId`. -#[pallet::constant] -type ParaDeposit: Get>; +trait Config { + // -- snip -- + + /// The deposit required for reserving a `ParaId`. + #[pallet::constant] + type ParaDeposit: Get>; -/// The deposit to be paid per byte stored on chain. -#[pallet::constant] -type DataDepositPerByte: Get>; + /// The deposit to be paid per byte stored on chain. + #[pallet::constant] + type DataDepositPerByte: Get>; +} ``` This RFC proposes the addition of three new constants that will determine the payment amount and the frequency of the recurring rent payment: ```rust -/// Defines how frequently the rent needs to be paid. -/// -/// The duration is set in sessions instead of block numbers. -#[pallet::constant] -type RentDuration: Get; +trait Config { + // -- snip -- -/// The initial deposit amount for reserving a `ParaId` -/// -/// This is defined as a percentage of the deposit that would be required in the regular -/// model. -#[pallet::constant] -type InitialRentDeposit: Get; - -/// The recurring rental cost as a percentage of the initial rental registration deposit. -#[pallet::constant] -type RecurringRentCost: Get; + /// Defines how frequently the rent needs to be paid. + /// + /// The duration is set in sessions instead of block numbers. + #[pallet::constant] + type RentDuration: Get; + + /// The initial deposit amount for registering validation code. + /// + /// This is defined as a percentage of the deposit that would be required in the regular + /// model. + #[pallet::constant] + type InitialRentDeposit: Get; + + /// The recurring rental cost as a percentage of the initial rental registration deposit. + #[pallet::constant] + type RecurringRentCost: Get; +} ``` Users will be able to reserve a `ParaId` and register their validation code for a percentage of the regular deposit required. However, they must also make additional rent payments at intervals of `T::RentDuration`. -For registering using the new rental system we will have to make modifications to the `paras-registrar` pallet. We should expose two new extrinsics, as well as make a small modification to the existing `reserve` extrinsic: +For registering using the new rental system we will have to make modifications to the `paras-registrar` pallet. We should expose two new extrinsics for this: ```rust -#[pallet::call_index(5)] -#[pallet::weight(::WeightInfo::reserve())] -pub fn reserve(origin: OriginFor, rent_based_payment: bool) -> DispatchResult { - // The logic remains the same; however, if `rent_based_payment` is true, the - // required deposit is only `T::InitialRentDeposit` percent of `T::ParaDeposit`. -} - -pub fn register_rental( - origin: OriginFor, - id: ParaId, - genesis_head: HeadData, - validation_code: ValidationCode, -) -> DispatchResult { /* ... */ } - -pub fn pay_rent(origin: OriginFor, id: ParaId) -> DispatchResult { - /* ... */ +mod pallet { + // -- snip -- + + #[pallet::call_index(9)] + pub fn register_rental( + origin: OriginFor, + id: ParaId, + genesis_head: HeadData, + validation_code: ValidationCode, + ) -> DispatchResult { /* ... */ } + + #[pallet::call_index(10)] + pub fn pay_rent(origin: OriginFor, id: ParaId) -> DispatchResult { + /* ... */ + } } ``` A call to `register_rental` will require the reservation of only a percentage of the deposit that would otherwise be required to register the validation code when using the regular model. As described later in the *Quick para re-registering* section below, we will also store the code hash and the head data of each parachain to enable faster re-registration after a parachain has been pruned. For this reason the total initial deposit amount is increased to account for that. ```rust -let validation_code_deposit = T::ParaDeposit::get() - .saturating_add(per_byte_fee.saturating_mul((validation_code.0.len() as u32).into())); +// The logic for calculating the initial deposit for parachain registered with the +// new rent-based model: + +let validation_code_deposit = per_byte_fee.saturating_mul((validation_code.0.len() as u32).into()); let head_deposit = per_byte_fee.saturating_mul((genesis_head.0.len() as u32).into()) let hash_deposit = per_byte_fee.saturating_mul(HASH_SIZE); let deposit = T::InitialRentDeposit::get().mul_ceil(validation_code_deposit) + .saturating_add(T::ParaDeposit::get()) .saturating_add(head_deposit) .saturating_add(hash_deposit) ``` -Once the `ParaId` is reserved and the validation code is registered the rent must be periodically paid to ensure the on-demand parachain doesn't get removed from the state. The `pay_rent` extrinsic should be callable by anyone. +Once the `ParaId` is reserved and the validation code is registered the rent must be periodically paid to ensure the on-demand parachain doesn't get removed from the state. The `pay_rent` extrinsic should be callable by anyone, removing the need for the parachain to depend on the parachain manager for rent payments. ### On-demand parachain pruning -If the rent is not paid, anyone has the option to prune the on-demand parachain and claim the initial deposit as a reward, minus the deposit for storing the validation code hash and the head data, as that won't be removed after the pruning operation. +If the rent is not paid, anyone has the option to prune the on-demand parachain and claim a portion of the initial deposit reserved for storing the validation code. Pruning only removes the validation code, while the head data and validation code hash are retained. The validation code hash is stored to allow anyone to register it again as well as to enable quicker re-registration by skipping the pre-checking process. The moment the rent is no longer paid, the parachain won't be able to purchase on-demand access, meaning no new blocks are allowed. This stage is called the "hibernation" stage, during which all the parachain-related data is still stored on-chain, but new blocks are not permitted. The reason for this is to ensure that the validation code is available in case it is needed in the dispute or approval checking subsystems. Waiting for one entire session will be enough to ensure it is safe to deregister the parachain. This means that anyone can prune the parachain only once the "hibernation" stage is over, which lasts for an entire session after the moment that the rent is not paid. ### Ensuring rent is paid -The `paras` pallet will be loosely coupled with the `para-registrar` pallet through a `RentStatusProvider` trait. This approach enables all the pallets tightly coupled with the `paras` pallet to have access to the rent status information. - -```rust -pub trait RentStatusProvider { - /// Checks whether the rent is paid for storing the PVF on-chain. - /// - /// In case the parachain is registered using the regular registration model - /// this will simply return true. - fn rent_paid(id: ParaId) -> bool; -} -``` +The `paras` pallet will be loosely coupled with the `para-registrar` pallet. This approach enables all the pallets tightly coupled with the `paras` pallet to have access to the rent status information. Once the validation code is stored without having its rent paid the `assigner_on_demand` pallet will ensure that an order for that parachain cannot be placed. This is easily achievable given that the `assigner_on_demand` pallet is tightly coupled with the `paras` pallet. -### Quick para re-registration - -If the rent isn't paid on time, and the parachain gets pruned, the new model should provide a quick way to re-register the same validation code under the same `ParaId`. This can be achieved by skipping the pre-checking process. +### On-demand para re-registration -This will be accomplished by introducing a new storage map within the `paras` pallet. The reason for not utilizing the existing `CurrentCodeHash` storage map is because it contains code hashes associated with non pre-checked validation code. +If the rent isn't paid on time, and the parachain gets pruned, the new model should provide a quick way to re-register the same validation code under the same `ParaId`. This can be achieved by skipping the pre-checking process, as the validation code hash will be stored on-chain, allowing us to easily verify that the uploaded code remains unchanged. ```rust /// Stores the validation code hash and head data for parachains that successfully completed the @@ -145,63 +147,56 @@ This will be accomplished by introducing a new storage map within the `paras` pa /// registered and checked. /// /// NOTE: During a runtime upgrade where the pre-checking rules change this storage map should be -/// cleared. +/// cleared appropriately. #[pallet::storage] #[pallet::getter(fn checked_code_hash)] pub(super) type CheckedParachains = StorageMap<_, Twox64Concat, ParaId, (ValidationCodeHash, HeadData)>; ``` -To perform a parachain re-registration, we can adapt the existing `register` extrinsic with a few necessary adjustments. The modified extrinsic will include a new argument that indicates the caller's intention to re-register the parachain. - -```rust -#[pallet::call_index(0)] -#[pallet::weight(::WeightInfo::register())] -pub fn register( - origin: OriginFor, - id: ParaId, - genesis_head: HeadData, - validation_code: ValidationCode, - reregistering: bool, -) -> DispatchResult { - // If the `reregistering` parameter is set to true, it's not necessary for the caller to be - // the para manager. In this case, the caller only needs to cover the initial deposit - // required for storing the validation code. -} -``` +To enable parachain re-registration, we should introduce a new extrinsic in the `paras-registrar` pallet that allows this. The logic of this extrinsic will be same as regular registration, with the distinction that it can be called by anyone, and the required deposit will be smaller since it only has to cover for the storage of the validation code. ## Drawbacks -TODO +A drawback of this RFC is that it does not reduce the cost of reserving a `ParaId`. This decision is based on the desire to avoid additional complexity in the system, as the current reservation cost is already considered reasonable. + +Even though this RFC doesn't delve into the specifics of the configuration values for parachain registration but rather focuses on the mechanism, configuring it carelessly could lead to potential problems. + +Since the validation code hash and head data are not removed when the parachain is pruned but only when the `deregister` extrinsic is called, the `T::DataDepositPerByte` must be set to a higher value to create a strong enough incentive for removing it from the state. ## Testing, Security, and Privacy -Describe the the impact of the proposal on these three high-importance areas - how implementations can be tested for adherence, effects that the proposal has on security and privacy per-se, as well as any possible implementation pitfalls which should be clearly avoided. +The implementation of this RFC will be tested on Rococo first. -## Performance, Ergonomics, and Compatibility +Proper research should be conducted on setting the configuration values of the new system since these values can have great impact on the network. -Describe the impact of the proposal on the exposed functionality of Polkadot. +An audit is required to ensure the implementation's correctness. + +The proposal introduces no new privacy concerns. + +## Performance, Ergonomics, and Compatibility ### Performance -Is this an optimization or a necessary pessimization? What steps have been taken to minimize additional overhead? +This RFC should not introduce any performance impact. ### Ergonomics -If the proposal alters exposed interfaces to developers or end-users, which types of usage patterns have been optimized for? +This RFC does not affect the current parachains, nor the parachains that intend to use the one-time payment model for parachain registration. ### Compatibility -Does this proposal break compatibility with existing interfaces, older versions of implementations? Summarize necessary migrations or upgrade strategies, if any. +This RFC does not break compatibility. ## Prior Art and References -Provide references to either prior art or other relevant research for the submitted design. +Prior discussion on this topic: https://github.com/paritytech/polkadot-sdk/issues/1796 ## Unresolved Questions -Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. +None at this time. ## Future Directions and Related Material -Describe future work which could be enabled by this RFC, if it were accepted, as well as related RFCs. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. +As noted in [this GitHub issue](https://github.com/paritytech/polkadot-sdk/issues/1796), we want to raise the per-byte cost of on-chain data storage. However, a substantial increase in this cost would make it highly impractical for on-demand parachains to register on Polkadot. +This RFC offers an alternative solution for on-demand parachains, ensuring that the per-byte cost increase doesn't overly burden the registration process. From 142b24219e3da73b940e7321f1be3de676f81790 Mon Sep 17 00:00:00 2001 From: Szegoo Date: Mon, 6 Nov 2023 09:28:01 +0100 Subject: [PATCH 3/8] remove specifics --- text/0044-rent-based-registration.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/text/0044-rent-based-registration.md b/text/0044-rent-based-registration.md index 5ef057f4e..757c70668 100644 --- a/text/0044-rent-based-registration.md +++ b/text/0044-rent-based-registration.md @@ -89,7 +89,6 @@ For registering using the new rental system we will have to make modifications t mod pallet { // -- snip -- - #[pallet::call_index(9)] pub fn register_rental( origin: OriginFor, id: ParaId, @@ -97,7 +96,6 @@ mod pallet { validation_code: ValidationCode, ) -> DispatchResult { /* ... */ } - #[pallet::call_index(10)] pub fn pay_rent(origin: OriginFor, id: ParaId) -> DispatchResult { /* ... */ } @@ -149,7 +147,6 @@ If the rent isn't paid on time, and the parachain gets pruned, the new model sho /// NOTE: During a runtime upgrade where the pre-checking rules change this storage map should be /// cleared appropriately. #[pallet::storage] -#[pallet::getter(fn checked_code_hash)] pub(super) type CheckedParachains = StorageMap<_, Twox64Concat, ParaId, (ValidationCodeHash, HeadData)>; ``` From db0b89d2f6121f961797601ea65386d8c671d502 Mon Sep 17 00:00:00 2001 From: Szegoo Date: Mon, 6 Nov 2023 11:35:41 +0100 Subject: [PATCH 4/8] fix --- text/0044-rent-based-registration.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0044-rent-based-registration.md b/text/0044-rent-based-registration.md index 757c70668..7a70b2679 100644 --- a/text/0044-rent-based-registration.md +++ b/text/0044-rent-based-registration.md @@ -103,7 +103,7 @@ mod pallet { ``` A call to `register_rental` will require the reservation of only a percentage of the deposit that would otherwise be required to register the validation code when using the regular model. -As described later in the *Quick para re-registering* section below, we will also store the code hash and the head data of each parachain to enable faster re-registration after a parachain has been pruned. For this reason the total initial deposit amount is increased to account for that. +As described later in the *Quick para re-registering* section below, we will also store the code hash of each parachain to enable faster re-registration after a parachain has been pruned. For this reason the total initial deposit amount is increased to account for that. ```rust // The logic for calculating the initial deposit for parachain registered with the // new rent-based model: @@ -138,7 +138,7 @@ Once the validation code is stored without having its rent paid the `assigner_on If the rent isn't paid on time, and the parachain gets pruned, the new model should provide a quick way to re-register the same validation code under the same `ParaId`. This can be achieved by skipping the pre-checking process, as the validation code hash will be stored on-chain, allowing us to easily verify that the uploaded code remains unchanged. ```rust -/// Stores the validation code hash and head data for parachains that successfully completed the +/// Stores the validation code hash for parachains that successfully completed the /// pre-checking process. /// /// This is stored to enable faster on-demand para re-registration in case its pvf has been earlier @@ -147,8 +147,8 @@ If the rent isn't paid on time, and the parachain gets pruned, the new model sho /// NOTE: During a runtime upgrade where the pre-checking rules change this storage map should be /// cleared appropriately. #[pallet::storage] -pub(super) type CheckedParachains = - StorageMap<_, Twox64Concat, ParaId, (ValidationCodeHash, HeadData)>; +pub(super) type CheckedCodeHash = + StorageMap<_, Twox64Concat, ParaId, ValidationCodeHash>; ``` To enable parachain re-registration, we should introduce a new extrinsic in the `paras-registrar` pallet that allows this. The logic of this extrinsic will be same as regular registration, with the distinction that it can be called by anyone, and the required deposit will be smaller since it only has to cover for the storage of the validation code. From 7547e97bf9fdd7f942eb6d1d260c5a9fa702f877 Mon Sep 17 00:00:00 2001 From: Szegoo Date: Thu, 9 Nov 2023 14:47:08 +0100 Subject: [PATCH 5/8] typo fix & add more description for pruning --- text/0044-rent-based-registration.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/text/0044-rent-based-registration.md b/text/0044-rent-based-registration.md index 7a70b2679..cb8fcc2a7 100644 --- a/text/0044-rent-based-registration.md +++ b/text/0044-rent-based-registration.md @@ -20,7 +20,7 @@ This new model will coexist with the existing one-time deposit payment model, of ## Requirements -1. The solution SHOULD NOT affect the current model for registering validatoin code. +1. The solution SHOULD NOT affect the current model for registering validation code. 2. The solution SHOULD offer an easily configurable way for governance to adjust the initial deposit and recurring rent cost. 3. The solution SHOULD provide an incentive to prune validation code for which rent is not paid. 4. The solution SHOULD allow anyone to re-register validation code under the same `ParaId` without the need for redundant pre-checking if it was already verified before. @@ -122,12 +122,14 @@ Once the `ParaId` is reserved and the validation code is registered the rent mus ### On-demand parachain pruning -If the rent is not paid, anyone has the option to prune the on-demand parachain and claim a portion of the initial deposit reserved for storing the validation code. Pruning only removes the validation code, while the head data and validation code hash are retained. The validation code hash is stored to allow anyone to register it again as well as to enable quicker re-registration by skipping the pre-checking process. +If the rent is not paid, anyone has the option to prune the on-demand parachain and claim a portion of the initial deposit reserved for storing the validation code. This type of 'light' pruning only removes the validation code, while the head data and validation code hash are retained. The validation code hash is stored to allow anyone to register it again as well as to enable quicker re-registration by skipping the pre-checking process. The moment the rent is no longer paid, the parachain won't be able to purchase on-demand access, meaning no new blocks are allowed. This stage is called the "hibernation" stage, during which all the parachain-related data is still stored on-chain, but new blocks are not permitted. The reason for this is to ensure that the validation code is available in case it is needed in the dispute or approval checking subsystems. Waiting for one entire session will be enough to ensure it is safe to deregister the parachain. This means that anyone can prune the parachain only once the "hibernation" stage is over, which lasts for an entire session after the moment that the rent is not paid. +The pruning described here is a light form of pruning, since it only removes the validation code. As with all parachains, the parachain or para manager can use the `deregister` extrinsic to remove all associated state. + ### Ensuring rent is paid The `paras` pallet will be loosely coupled with the `para-registrar` pallet. This approach enables all the pallets tightly coupled with the `paras` pallet to have access to the rent status information. From 6872c894a38cfb693705927e4709b555610c40c6 Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Wed, 6 Dec 2023 21:12:20 +0100 Subject: [PATCH 6/8] rename constants --- text/0044-rent-based-registration.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0044-rent-based-registration.md b/text/0044-rent-based-registration.md index cb8fcc2a7..5ff1eee66 100644 --- a/text/0044-rent-based-registration.md +++ b/text/0044-rent-based-registration.md @@ -74,11 +74,11 @@ trait Config { /// This is defined as a percentage of the deposit that would be required in the regular /// model. #[pallet::constant] - type InitialRentDeposit: Get; + type RentalDepositProportion: Get; /// The recurring rental cost as a percentage of the initial rental registration deposit. #[pallet::constant] - type RecurringRentCost: Get; + type RentalRecurringProportion: Get; } ``` @@ -113,7 +113,7 @@ let validation_code_deposit = per_byte_fee.saturating_mul((validation_code.0.len let head_deposit = per_byte_fee.saturating_mul((genesis_head.0.len() as u32).into()) let hash_deposit = per_byte_fee.saturating_mul(HASH_SIZE); -let deposit = T::InitialRentDeposit::get().mul_ceil(validation_code_deposit) +let deposit = T::RentalDepositProportion::get().mul_ceil(validation_code_deposit) .saturating_add(T::ParaDeposit::get()) .saturating_add(head_deposit) .saturating_add(hash_deposit) From 64ccb0a432d8248766b73c5963beeee6dc80306e Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Wed, 6 Dec 2023 21:17:05 +0100 Subject: [PATCH 7/8] more general --- text/0044-rent-based-registration.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0044-rent-based-registration.md b/text/0044-rent-based-registration.md index 5ff1eee66..375e70579 100644 --- a/text/0044-rent-based-registration.md +++ b/text/0044-rent-based-registration.md @@ -71,18 +71,18 @@ trait Config { /// The initial deposit amount for registering validation code. /// - /// This is defined as a percentage of the deposit that would be required in the regular + /// This is defined as a proportion of the deposit that would be required in the regular /// model. #[pallet::constant] type RentalDepositProportion: Get; - /// The recurring rental cost as a percentage of the initial rental registration deposit. + /// The recurring rental cost defined as a proportion of the initial rental registration deposit. #[pallet::constant] type RentalRecurringProportion: Get; } ``` -Users will be able to reserve a `ParaId` and register their validation code for a percentage of the regular deposit required. However, they must also make additional rent payments at intervals of `T::RentDuration`. +Users will be able to reserve a `ParaId` and register their validation code for a proportion of the regular deposit required. However, they must also make additional rent payments at intervals of `T::RentDuration`. For registering using the new rental system we will have to make modifications to the `paras-registrar` pallet. We should expose two new extrinsics for this: ```rust From af6fd425c56971d54c3f2158337862b9f2b66b24 Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Tue, 19 Dec 2023 10:18:04 +0100 Subject: [PATCH 8/8] rephrase --- text/0044-rent-based-registration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0044-rent-based-registration.md b/text/0044-rent-based-registration.md index 375e70579..bc7ac387e 100644 --- a/text/0044-rent-based-registration.md +++ b/text/0044-rent-based-registration.md @@ -157,7 +157,7 @@ To enable parachain re-registration, we should introduce a new extrinsic in the ## Drawbacks -A drawback of this RFC is that it does not reduce the cost of reserving a `ParaId`. This decision is based on the desire to avoid additional complexity in the system, as the current reservation cost is already considered reasonable. +This RFC does not alter the process of reserving a `ParaId`, and therefore, it does not propose reducing it, even though such a reduction could be beneficial. Even though this RFC doesn't delve into the specifics of the configuration values for parachain registration but rather focuses on the mechanism, configuring it carelessly could lead to potential problems.