Design and implement pallet-staking-rc-client

[gpestana]

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:

• Set the new validator set, when ready (push-based, message through XCM)
• Receive era points from relay chain through (batched) XCM
• Receive XCM messages notifying of new (unsigned) offences
• Exposes extrinsic for signed offences and propagate them to the relay-chain through XCM
• Set and propagate session keys

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 (#6167).

Tasks

Preview Give feedback

1. Design and open fellowship RFC for interactions between AH staking and the relay-chain
2. 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.

• Implement new_validator_set XCM message passing (pallet-staking-rc-client -> relay-chain) with message batching
• 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).

• Implement set_keys/ purge_keys extrinsic ad XCM message passing (pallet-staking-rc-client -> relay-chain)
• 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.

• Implement report_offence) extrinsic and XCM message passing (pallet-staking-rc-client -> relay-chain)
• Implement thin disablement layer in pallet-staking-client (in relay-chain). Related to Design and implement pallet-staking-client #6167
• time constraints of propagating the XCM of explicit reported offences to relay chain?

[gpestana]

Being worked at https://github.com/paritytech/polkadot-sdk/compare/gpestana/staking-rc-client

EDIT: PR open #6259

[Ank4n]

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?