### Tasks
- [ ] Design and open fellowship RFC for interactions between AH staking and the relay-chain
- [ ] Implement `pallet-staking-rc-client`
The relay chain and AH staking need to interact with each other over an era in different phases of an election. The communication must be done through XCM and each of functions have different requirements and time/space constraints.
Era rotation and new validator set
The relay-chain does not have the concept of "era". Staking and EPM-MB will run the elections in AH and once a new set of validators is ready, it notifies the relay-chain to change the validator set through XCM. This means that if no election happens within the expected time, the current validator set will remain active in the relay-chain.
[ ] time/space requirements for propagating a new full set of validators to the relay-chain
Register/unregister validator keys
Currently, the session pallet in the relay-chain exposes Call::set_keys and Call::purge_keys for wannabe validators to set/unset their session keys. With AH staking, these extrinsics should be exposed in the pallet-staking-rc-client (or in the pallet-staking). This information should be propagated through XCM to the pallet-staking-client in the relay chain with a similar behaviour as currently (i.e. set_keys will be placed in the NextKeys storage, etc).
[ ] time/space requirements for setting keys -- does it require batching?
[ ] session pallet in AH vs session pallet in relay chain will not be in sync. How to ensure that the rotating NextKeys in relay-chain is in sync with the new session/era expected by AH?
Block producing era points
Currently, the staking pallet implements the pallet_authorship::EventHandler to receive the era points of a block author for the current session. As similar interface must be implemented with XCM as i/o instead.
Given the potential delays in calling and propagating EventHandler::reward_by_ids between rc and AH, the reward payout may be done only after era+1 ("era" being the active era of the validator).
[ ] session pallet in AH vs session pallet in relay chain will not be in sync and that's expected by the current implementation. How to ensure that the points are credited to the correct (session, validator) tuple?
[ ] time/space requirements for setting keys -- does it require batching?
Offences
There are 2 types of offence reports currently, implicit and explicit. The implicit offences are generated in the relay chain and should be propagated to AH staking for slashing. The explicit (i.e. signed offences) are reported by signed origins through an extrinsic. This extrinsic should be implemented in the pallet-staking-rc-client (i.e. in AH) and relayed to the relay chain with XCM.
The relay chain should implement a thin disablement layer to ensure that the implicit offences result in a timely validator disablement in the relay-chain without having to wait for the RC -> AH -> RC XCM message passing.
I was thinking we could have only one pallet for both chains, this (AH) and RC since they need to work well together. Then both can be configured to act as Session Client (AH) or Staking Client (RC). Wdyt?
gpestana
commented
1 month ago 
Ank4n
Design and implement the relay-chain client pallet (i.e. deployed in the staking parachain) that handles i/o from the relay chain, most notably:
New pallet being worked at https://github.com/paritytech/polkadot-sdk/compare/gpestana/staking-rc-client. Opening a PR asap.
Counter-part pallet of
pallet-staking-client(https://github.com/paritytech/polkadot-sdk/issues/6167).The relay chain and AH staking need to interact with each other over an era in different phases of an election. The communication must be done through XCM and each of functions have different requirements and time/space constraints.
Era rotation and new validator set
The relay-chain does not have the concept of "era". Staking and EPM-MB will run the elections in AH and once a new set of validators is ready, it notifies the relay-chain to change the validator set through XCM. This means that if no election happens within the expected time, the current validator set will remain active in the relay-chain.
new_validator_setXCM message passing (pallet-staking-rc-client-> relay-chain) with message batchingRegister/unregister validator keys
Currently, the session pallet in the relay-chain exposes
Call::set_keysandCall::purge_keysfor wannabe validators to set/unset their session keys. With AH staking, these extrinsics should be exposed in thepallet-staking-rc-client(or in thepallet-staking). This information should be propagated through XCM to thepallet-staking-clientin the relay chain with a similar behaviour as currently (i.e.set_keyswill be placed in theNextKeysstorage, etc).set_keys/purge_keysextrinsic ad XCM message passing (pallet-staking-rc-client-> relay-chain)NextKeysin relay-chain is in sync with the new session/era expected by AH?Block producing era points
Currently, the staking pallet implements the
pallet_authorship::EventHandlerto receive the era points of a block author for the current session. As similar interface must be implemented with XCM as i/o instead.Given the potential delays in calling and propagating
EventHandler::reward_by_idsbetween rc and AH, the reward payout may be done only after era+1 ("era" being the active era of the validator).(session, validator)tuple?Offences
There are 2 types of offence reports currently, implicit and explicit. The implicit offences are generated in the relay chain and should be propagated to AH staking for slashing. The explicit (i.e. signed offences) are reported by signed origins through an extrinsic. This extrinsic should be implemented in the
pallet-staking-rc-client(i.e. in AH) and relayed to the relay chain with XCM.The relay chain should implement a thin disablement layer to ensure that the implicit offences result in a timely validator disablement in the relay-chain without having to wait for the RC -> AH -> RC XCM message passing.
report_offence) extrinsic and XCM message passing (pallet-staking-rc-client-> relay-chain)pallet-staking-client(in relay-chain). Related to https://github.com/paritytech/polkadot-sdk/issues/6167