From abb8a605e8cdd1791c629f230e77298afebdf27d Mon Sep 17 00:00:00 2001 From: Sergey Shulepov Date: Fri, 3 Dec 2021 16:37:12 +0000 Subject: [PATCH] configuration: Rename validation_upgrade_{frequency -> cooldown} This just renames a member of `HostConfiguration` from validation_upgrade_frequency to -//-_cooldown. As was already pointed out in #4460 the existing name is a misnomer, the member actually represents a minimum time period between upgrades, which is neatly expressed by a word cooldown. I've been planning this rename already for some time and the term is already used in paras module: https://github.com/paritytech/polkadot/blob/0f1a67114ad4c849223f87fa48c3dd3d9743832c/runtime/parachains/src/paras.rs#L1568-L1574 --- node/service/src/chain_spec.rs | 2 +- node/test/service/src/chain_spec.rs | 2 +- primitives/src/v1/mod.rs | 2 +- .../src/runtime/inclusion.md | 2 +- .../implementers-guide/src/runtime/paras.md | 2 +- .../implementers-guide/src/types/README.md | 2 +- .../implementers-guide/src/types/runtime.md | 2 +- runtime/parachains/src/configuration.rs | 31 ++++++++++--------- .../parachains/src/configuration/migration.rs | 4 +-- runtime/parachains/src/paras.rs | 18 +++++------ 10 files changed, 34 insertions(+), 33 deletions(-) diff --git a/node/service/src/chain_spec.rs b/node/service/src/chain_spec.rs index b2cf24c90ec2..913519f1128d 100644 --- a/node/service/src/chain_spec.rs +++ b/node/service/src/chain_spec.rs @@ -179,7 +179,7 @@ fn default_parachains_host_configuration( use polkadot_primitives::v1::{MAX_CODE_SIZE, MAX_POV_SIZE}; polkadot_runtime_parachains::configuration::HostConfiguration { - validation_upgrade_frequency: 2u32, + validation_upgrade_cooldown: 2u32, validation_upgrade_delay: 2, code_retention_period: 1200, max_code_size: MAX_CODE_SIZE, diff --git a/node/test/service/src/chain_spec.rs b/node/test/service/src/chain_spec.rs index 3aed0210e363..492e6f856010 100644 --- a/node/test/service/src/chain_spec.rs +++ b/node/test/service/src/chain_spec.rs @@ -161,7 +161,7 @@ fn polkadot_testnet_genesis( sudo: runtime::SudoConfig { key: Some(root_key) }, configuration: runtime::ConfigurationConfig { config: polkadot_runtime_parachains::configuration::HostConfiguration { - validation_upgrade_frequency: 10u32, + validation_upgrade_cooldown: 10u32, validation_upgrade_delay: 5, code_retention_period: 1200, max_code_size: MAX_CODE_SIZE, diff --git a/primitives/src/v1/mod.rs b/primitives/src/v1/mod.rs index 4719f9fa44ba..2b53f1b9c4f3 100644 --- a/primitives/src/v1/mod.rs +++ b/primitives/src/v1/mod.rs @@ -1031,7 +1031,7 @@ pub struct AbridgedHostConfiguration { /// This parameter affects the upper bound of size of `CandidateCommitments`. pub hrmp_max_message_num_per_candidate: u32, /// The minimum period, in blocks, between which parachains can update their validation code. - pub validation_upgrade_frequency: BlockNumber, + pub validation_upgrade_cooldown: BlockNumber, /// The delay, in blocks, before a validation upgrade is applied. pub validation_upgrade_delay: BlockNumber, } diff --git a/roadmap/implementers-guide/src/runtime/inclusion.md b/roadmap/implementers-guide/src/runtime/inclusion.md index d332333e41e0..6df34ae4ddc1 100644 --- a/roadmap/implementers-guide/src/runtime/inclusion.md +++ b/roadmap/implementers-guide/src/runtime/inclusion.md @@ -85,7 +85,7 @@ All failed checks should lead to an unrecoverable error making the block invalid 1. check that each candidate's `validation_data_hash` corresponds to a `PersistedValidationData` computed from the current state. > NOTE: With contextual execution in place, validation data will be obtained as of the state of the context block. However, only the state of the current block can be used for such a query. 1. If the core assignment includes a specific collator, ensure the backed candidate is issued by that collator. - 1. Ensure that any code upgrade scheduled by the candidate does not happen within `config.validation_upgrade_frequency` of `Paras::last_code_upgrade(para_id, true)`, if any, comparing against the value of `Paras::FutureCodeUpgrades` for the given para ID. + 1. Ensure that any code upgrade scheduled by the candidate does not happen within `config.validation_upgrade_cooldown` of `Paras::last_code_upgrade(para_id, true)`, if any, comparing against the value of `Paras::FutureCodeUpgrades` for the given para ID. 1. Check the collator's signature on the candidate data. 1. check the backing of the candidate using the signatures and the bitfields, comparing against the validators assigned to the groups, fetched with the `group_validators` lookup. 1. call `Ump::check_upward_messages(para, commitments.upward_messages)` to check that the upward messages are valid. diff --git a/roadmap/implementers-guide/src/runtime/paras.md b/roadmap/implementers-guide/src/runtime/paras.md index 375b1fb91d73..af2e7add54e5 100644 --- a/roadmap/implementers-guide/src/runtime/paras.md +++ b/roadmap/implementers-guide/src/runtime/paras.md @@ -258,7 +258,7 @@ CodeByHash: map ValidationCodeHash => Option * `schedule_parachain_downgrade(ParaId)`: Schedule a parachain to be downgraded to a parathread. * `schedule_code_upgrade(ParaId, new_code, relay_parent: BlockNumber, HostConfiguration)`: Schedule a future code upgrade of the given parachain. In case the PVF pre-checking is disabled, or the new code is already present in the storage, the upgrade will be applied after inclusion of a block of the same parachain - executed in the context of a relay-chain block with number >= `relay_parent + config.validation_upgrade_delay`. If the upgrade is scheduled `UpgradeRestrictionSignal` is set and it will remain set until `relay_parent + config.validation_upgrade_frequency`. + executed in the context of a relay-chain block with number >= `relay_parent + config.validation_upgrade_delay`. If the upgrade is scheduled `UpgradeRestrictionSignal` is set and it will remain set until `relay_parent + config.validation_upgrade_cooldown`. In case the PVF pre-checking is enabled, or the new code is not already present in the storage, then the PVF pre-checking run will be scheduled for that validation code. If the pre-checking concludes with rejection, then the upgrade is canceled. Otherwise, after pre-checking is concluded the upgrade will be scheduled and be enacted as described above. * `note_new_head(ParaId, HeadData, BlockNumber)`: note that a para has progressed to a new head, where the new head was executed in the context of a relay-chain block with given number. This will diff --git a/roadmap/implementers-guide/src/types/README.md b/roadmap/implementers-guide/src/types/README.md index 7c8bec153527..31f2889921fd 100644 --- a/roadmap/implementers-guide/src/types/README.md +++ b/roadmap/implementers-guide/src/types/README.md @@ -316,7 +316,7 @@ digraph { max_upward_message_sizeu32 max_upward_messages_num_per_candidateu32 hrmp_max_message_num_per_candidateu32 - validation_upgrade_frequencyBlockNumber + validation_upgrade_cooldownBlockNumber validation_upgrade_delayBlockNumber >] diff --git a/roadmap/implementers-guide/src/types/runtime.md b/roadmap/implementers-guide/src/types/runtime.md index f72f902e36dc..d3d00d5163b3 100644 --- a/roadmap/implementers-guide/src/types/runtime.md +++ b/roadmap/implementers-guide/src/types/runtime.md @@ -9,7 +9,7 @@ The internal-to-runtime configuration of the parachain host. This is expected to ```rust struct HostConfiguration { /// The minimum period, in blocks, between which parachains can update their validation code. - pub validation_upgrade_frequency: BlockNumber, + pub validation_upgrade_cooldown: BlockNumber, /// The delay, in blocks, before a validation upgrade is applied. pub validation_upgrade_delay: BlockNumber, /// How long to keep code on-chain, in blocks. This should be sufficiently long that disputes diff --git a/runtime/parachains/src/configuration.rs b/runtime/parachains/src/configuration.rs index dc303ef40672..88b7a78c52bc 100644 --- a/runtime/parachains/src/configuration.rs +++ b/runtime/parachains/src/configuration.rs @@ -77,7 +77,8 @@ pub struct HostConfiguration { /// PVF pre-checking can take. Intuitively, this number should be greater than the duration /// specified by [`pvf_voting_ttl`]. Unlike, [`pvf_voting_ttl`], this parameter uses blocks /// as a unit. - pub validation_upgrade_frequency: BlockNumber, + #[cfg_attr(feature = "std", serde(alias = "validation_upgrade_frequency"))] + pub validation_upgrade_cooldown: BlockNumber, /// The delay, in blocks, before a validation upgrade is applied. pub validation_upgrade_delay: BlockNumber, @@ -218,7 +219,7 @@ impl> Default for HostConfiguration Pallet { - /// Set the validation upgrade frequency. + /// Set the validation upgrade cooldown. #[pallet::weight(( T::WeightInfo::set_config_with_block_number(), DispatchClass::Operational, ))] - pub fn set_validation_upgrade_frequency( + pub fn set_validation_upgrade_cooldown( origin: OriginFor, new: T::BlockNumber, ) -> DispatchResult { ensure_root(origin)?; Self::schedule_config_update(|config| { - config.validation_upgrade_frequency = new; + config.validation_upgrade_cooldown = new; }) } @@ -1345,11 +1346,11 @@ mod tests { let old_config = Configuration::config(); let mut config = old_config.clone(); config.validation_upgrade_delay = 100; - config.validation_upgrade_frequency = 100; + config.validation_upgrade_cooldown = 100; assert!(old_config != config); assert_ok!(Configuration::set_validation_upgrade_delay(Origin::root(), 100)); - assert_ok!(Configuration::set_validation_upgrade_frequency(Origin::root(), 100)); + assert_ok!(Configuration::set_validation_upgrade_cooldown(Origin::root(), 100)); assert_eq!(Configuration::config(), old_config); assert_eq!(::PendingConfigs::get(), vec![(2, config.clone())]); @@ -1373,7 +1374,7 @@ mod tests { HostConfiguration { validation_upgrade_delay: 100, ..initial_config.clone() }; let final_config = HostConfiguration { validation_upgrade_delay: 100, - validation_upgrade_frequency: 99, + validation_upgrade_cooldown: 99, ..initial_config.clone() }; @@ -1388,7 +1389,7 @@ mod tests { // We are still waiting until the pending configuration is applied and we add another // update. - assert_ok!(Configuration::set_validation_upgrade_frequency(Origin::root(), 99)); + assert_ok!(Configuration::set_validation_upgrade_cooldown(Origin::root(), 99)); // This should result in yet another configiguration change scheduled. assert_eq!(Configuration::config(), initial_config); @@ -1420,7 +1421,7 @@ mod tests { HostConfiguration { validation_upgrade_delay: 100, ..initial_config.clone() }; let final_config = HostConfiguration { validation_upgrade_delay: 100, - validation_upgrade_frequency: 99, + validation_upgrade_cooldown: 99, code_retention_period: 98, ..initial_config.clone() }; @@ -1436,7 +1437,7 @@ mod tests { // The second call should fall into the case where we already have a pending config // update for the scheduled_session, but we want to update it once more. - assert_ok!(Configuration::set_validation_upgrade_frequency(Origin::root(), 99)); + assert_ok!(Configuration::set_validation_upgrade_cooldown(Origin::root(), 99)); assert_ok!(Configuration::set_code_retention_period(Origin::root(), 98)); // This should result in yet another configiguration change scheduled. @@ -1545,7 +1546,7 @@ mod tests { fn setting_pending_config_members() { new_test_ext(Default::default()).execute_with(|| { let new_config = HostConfiguration { - validation_upgrade_frequency: 100, + validation_upgrade_cooldown: 100, validation_upgrade_delay: 10, code_retention_period: 5, max_code_size: 100_000, @@ -1592,9 +1593,9 @@ mod tests { assert!(::PendingConfig::get(shared::SESSION_DELAY).is_none()); - Configuration::set_validation_upgrade_frequency( + Configuration::set_validation_upgrade_cooldown( Origin::root(), - new_config.validation_upgrade_frequency, + new_config.validation_upgrade_cooldown, ) .unwrap(); Configuration::set_validation_upgrade_delay( @@ -1813,7 +1814,7 @@ mod tests { .max_upward_message_num_per_candidate, hrmp_max_message_num_per_candidate: ground_truth .hrmp_max_message_num_per_candidate, - validation_upgrade_frequency: ground_truth.validation_upgrade_frequency, + validation_upgrade_cooldown: ground_truth.validation_upgrade_cooldown, validation_upgrade_delay: ground_truth.validation_upgrade_delay, }, ); diff --git a/runtime/parachains/src/configuration/migration.rs b/runtime/parachains/src/configuration/migration.rs index 2d84dc5ec323..4963b61acb5d 100644 --- a/runtime/parachains/src/configuration/migration.rs +++ b/runtime/parachains/src/configuration/migration.rs @@ -156,7 +156,7 @@ max_upward_queue_size : pre.max_upward_queue_size, max_upward_message_size : pre.max_upward_message_size, max_upward_message_num_per_candidate : pre.max_upward_message_num_per_candidate, hrmp_max_message_num_per_candidate : pre.hrmp_max_message_num_per_candidate, -validation_upgrade_frequency : pre.validation_upgrade_frequency, +validation_upgrade_cooldown : pre.validation_upgrade_frequency, validation_upgrade_delay : pre.validation_upgrade_delay, max_pov_size : pre.max_pov_size, max_downward_message_size : pre.max_downward_message_size, @@ -347,7 +347,7 @@ mod tests { assert_eq!(v1.max_upward_message_size , v2.max_upward_message_size); assert_eq!(v1.max_upward_message_num_per_candidate , v2.max_upward_message_num_per_candidate); assert_eq!(v1.hrmp_max_message_num_per_candidate , v2.hrmp_max_message_num_per_candidate); - assert_eq!(v1.validation_upgrade_frequency , v2.validation_upgrade_frequency); + assert_eq!(v1.validation_upgrade_frequency , v2.validation_upgrade_cooldown); assert_eq!(v1.validation_upgrade_delay , v2.validation_upgrade_delay); assert_eq!(v1.max_pov_size , v2.max_pov_size); assert_eq!(v1.max_downward_message_size , v2.max_downward_message_size); diff --git a/runtime/parachains/src/paras.rs b/runtime/parachains/src/paras.rs index 93c080af2137..4274145734c9 100644 --- a/runtime/parachains/src/paras.rs +++ b/runtime/parachains/src/paras.rs @@ -1565,7 +1565,7 @@ impl Pallet { UpgradeRestrictionSignal::::insert(&id, UpgradeRestriction::Present); weight += T::DbWeight::get().reads_writes(1, 1); - let next_possible_upgrade_at = relay_parent_number + cfg.validation_upgrade_frequency; + let next_possible_upgrade_at = relay_parent_number + cfg.validation_upgrade_cooldown; ::UpgradeCooldowns::mutate(|upgrade_cooldowns| { let insert_idx = upgrade_cooldowns .binary_search_by_key(&next_possible_upgrade_at, |&(_, b)| b) @@ -2179,7 +2179,7 @@ mod tests { fn code_upgrade_applied_after_delay() { let code_retention_period = 10; let validation_upgrade_delay = 5; - let validation_upgrade_frequency = 10; + let validation_upgrade_cooldown = 10; let original_code = ValidationCode(vec![1, 2, 3]); let paras = vec![( @@ -2197,7 +2197,7 @@ mod tests { config: HostConfiguration { code_retention_period, validation_upgrade_delay, - validation_upgrade_frequency, + validation_upgrade_cooldown, pvf_checking_enabled: false, ..Default::default() }, @@ -2218,7 +2218,7 @@ mod tests { let expected_at = { // this parablock is in the context of block 1. let expected_at = 1 + validation_upgrade_delay; - let next_possible_upgrade_at = 1 + validation_upgrade_frequency; + let next_possible_upgrade_at = 1 + validation_upgrade_cooldown; Paras::schedule_code_upgrade( para_id, new_code.clone(), @@ -2287,7 +2287,7 @@ mod tests { fn code_upgrade_applied_after_delay_even_when_late() { let code_retention_period = 10; let validation_upgrade_delay = 5; - let validation_upgrade_frequency = 10; + let validation_upgrade_cooldown = 10; let original_code = ValidationCode(vec![1, 2, 3]); let paras = vec![( @@ -2305,7 +2305,7 @@ mod tests { config: HostConfiguration { code_retention_period, validation_upgrade_delay, - validation_upgrade_frequency, + validation_upgrade_cooldown, pvf_checking_enabled: false, ..Default::default() }, @@ -2324,7 +2324,7 @@ mod tests { let expected_at = { // this parablock is in the context of block 1. let expected_at = 1 + validation_upgrade_delay; - let next_possible_upgrade_at = 1 + validation_upgrade_frequency; + let next_possible_upgrade_at = 1 + validation_upgrade_cooldown; Paras::schedule_code_upgrade( para_id, new_code.clone(), @@ -2378,7 +2378,7 @@ mod tests { fn submit_code_change_when_not_allowed_is_err() { let code_retention_period = 10; let validation_upgrade_delay = 7; - let validation_upgrade_frequency = 100; + let validation_upgrade_cooldown = 100; let paras = vec![( 0u32.into(), @@ -2395,7 +2395,7 @@ mod tests { config: HostConfiguration { code_retention_period, validation_upgrade_delay, - validation_upgrade_frequency, + validation_upgrade_cooldown, pvf_checking_enabled: false, ..Default::default() },