Generate ownership proof for `SessionKeys`

[bkchr]

This RFC changes the SessionKeys runtime api to support generating a proof of ownership of the generated session keys.

[burdges]

In this RFC, all session keys first acknowledge their controller key by signing it, after which their controller key certifies them. Yes, we do obtain the desired back certificates this way, but I'd envisioned doing this in part the other way round, plus adding a master session key.

It'd look like this:

1. All other subordinate session keys back certify this master session key, likely the grandpa key.
2. The master session key certifies all other subordinate session keys, along with their certificates of the master session key, probably as pairs (subordinate_session_key,its_signature_on_grandpa_key).
3. Operator certifies the master session key with their controller key.
4. At node start, the master session key certifies the controller key along with both its certificate of the master session key and a random nonce. We call this the active certificate.
5. Pre-sync, the starting node announces its certificate collection, including this new one created upon startup.
6. An already active synced node posts the active certificate on-chain via some intrinsic, replacing the previous one.
7. The starting node waits until its active certificate get finalized before running protocols with equivocation slashing, like grandpa or babe.
8. Any node shuts down if its active certificate get replaced on-chain.

In emergencies, a command line option could overrides 7, and maybe this could happen automatically, but usually 7 prevents nodes being slashed for operator error.

In this, 1-2 have same orientation as proposed here, but 3-4 have the reversed orientation. We must check a two step certificate chain, including two back certificates, before believing a session key, but this should be a rare enough it does not matter. Our nonce in 4 could be some ephemeral key like maybe the transport layer key.

Anyways..

If there is a pressing need to do something simpler first then fine, and validator operators rarely get slashed for equivocations these days, maybe they get 0% slashed or we refund them, but it's maybe worth defending against the equivocations footgun like this. A master session key permits changing session keys without impacting user experience for validator operators, and consolidates the nonce lock under one session key, but this could be done without the master session key.

[bkchr]

/rfc propose

[paritytech-rfc-bot[bot]]

Hey @bkchr, here is a link you can use to create the referendum aiming to approve this RFC number 0048.

Instructions

1. Open the [link](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-collectives-rpc.polkadot.io#/extrinsics/decode/0x3d003e02015901000049015246435f415050524f564528303034382c32633564323765623232306132303565306336363334333739613461396366366236323038333632646537656232323636303330356635646366656637616233290100000000). 2. Switch to the `Submission` tab. 3. Adjust the transaction if needed (for example, the proposal Origin). 4. Submit the Transaction

---

It is based on commit hash adb59579ee424853a3174740b65e991a2a8d31aa.

The proposed remark text is: RFC_APPROVE(0048,2c5d27eb220a205e0c6634379a4a9cf6b6208362de7eb22660305f5dcfef7ab3).

[burdges]

We'd reduce slashing risks considerably if we handle this like I propsed above: https://github.com/polkadot-fellows/RFCs/pull/48#issuecomment-1809483250

[github-actions[bot]]

Voting for this referenda is ongoing.

Vote for it here

[github-actions[bot]]

PR can be merged.

Write the following command to trigger the bot

/rfc process 0x34f2bcbf3ef8b5ef7d7ab74cef6d391c1f6aee227daa5a67108f9e9c8ffd00aa

[bkchr]

/rfc process 0x34f2bcbf3ef8b5ef7d7ab74cef6d391c1f6aee227daa5a67108f9e9c8ffd00aa

[paritytech-rfc-bot[bot]]

The on-chain referendum has approved the RFC.