Add BEEFY capabilities to Westend and Kusama #7591
Conversation
Signed-off-by: Adrian Catangiu <[email protected]>
Signed-off-by: Adrian Catangiu <[email protected]>
Signed-off-by: Adrian Catangiu <[email protected]>
acatangiu
added
A0-please_review
…ative Since these keys are only used for development/local chains, also publish the secret seeds used to generate the public keys, so that developers can recover/generate the private key pairs if needed. Signed-off-by: Adrian Catangiu <[email protected]>
|
Also regarding session keys, when this gets deployed we'll have to ask validators to rotate their session keys so that BEEFY keys are generated and set on-chain. We'll need to monitor this before triggering the activation. |
|
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-kusama-bridge/2971/4 |
acatangiu
changed the title
There was a problem hiding this comment.
@ggwpez or @kianenigma this is my first runtime migration, how do I properly test it? 😄
I tested the migration locally on Westend using @andresilva PTAL |
| @@ -1385,6 +1498,14 @@ construct_runtime! { | |||
| Staking: pallet_staking::{Pallet, Call, Storage, Config<T>, Event<T>} = 6, | |||
| Offences: pallet_offences::{Pallet, Storage, Event} = 7, | |||
| Historical: session_historical::{Pallet} = 34, | |||
|
|
|||
| // BEEFY Bridges support. | |||
| Beefy: pallet_beefy::{Pallet, Call, Storage, Config<T>, ValidateUnsigned} = 200, | |||
There was a problem hiding this comment.
nit: not sure about choice of pallet index, but looking at the list there doesn't seem to be any real rule to it
There was a problem hiding this comment.
yes, couldn't find an exact rule either, other than pallet indices are somewhat grouped by functionality with XCM for example starting at 100, so I think bridge-related ones could start from 200 as we shouldn't need 50 of them to reach 255 😛
|
bot rebase |
|
Rebased |
runtime/kusama/src/lib.rs
Outdated
| impl frame_support::traits::OnRuntimeUpgrade for UpgradeSessionKeys { | ||
| fn on_runtime_upgrade() -> Weight { | ||
| Session::upgrade_keys::<OldSessionKeys, _>(transform_session_keys); | ||
| Perbill::from_percent(50) * BlockWeights::get().max_block |
There was a problem hiding this comment.
| Perbill::from_percent(50) * BlockWeights::get().max_block | |
| BlockWeights::get().max_block |
50% sounds rather random. Just let's take all the weight.
There was a problem hiding this comment.
I'm not familiar with block production code, if we take full Weight::max_block, do we run the risk of unable to produce block because of it being "overweight"?
I saw all past session key migrations "used" 50% max_weight, which seems safer to the untrained eye.
Co-authored-by: Bastian Köcher <[email protected]>
|
bot merge |
This enables BEEFY capabilities on Westend and Kusama.
Governance/sudo call is later required to enable/start consensus.
Part of paritytech/parity-bridges-common#2462
Notes:
Validators can still opt-out of running BEEFY using
--no-beefyflag, but this should be used in case of stability issues only. Ideally validators should run BEEFY consensus.Westend and Kusama validators (or at least archive nodes), should also run with
--enable-offchain-indexing=trueso that MMR proof generation is available for submitting to light-clients.cumulus companion: paritytech/cumulus#3021