Runtime should select Consensus Authorities

[JoshOrndorff]

The Tuxedo Template currently uses Aura and Grandpa consensus exactly like the FRAME node template. However, the runtime does not do anything interesting in terms of choosing the authorities. The template runtime just has a hard-coded list of authorities.

For a real-world chain we need some better method of choosing authorities. At minimum a simple PoA scheme, and Ideally even some DPoS at some point. (But for the sake of scoping this issue, let's say simple PoA where you can add and remove authorities via transactions).

The problem, as ever, is that there are no well-known storage locations. In FRAME, there is just a specific storage location where the authority IDs are stored, and the aura api is implemented simply by reading that storage. With UTXOs this is not possible. Soo here are some options.

Regarding Author Selection

Continue With Aura

I honestly don't have a good idea of how to do this. The best thing I can think of is to make a "special case" storage location like we do with the header and runtime code. This is not very UTXO-y and not ideal in my opinion.

Switch to Nimbus

I wrote nimbus when I was working on Moonbeam, so I probably have some inherent bias toward using it. That being said, it does allow nicer compatibility with the UTXO model.

The main difference between nimbus and Parity's consensus implementations (aura, babe, sasafrass) is that nimbus does very little on the client side, and leaves most of the checking to the runtime. Consequently, the runtime does not have to specify a complete authority set to the client-side. In fact, in nimbus, the authority set can be unbounded. Here is how the Nimbus/Tuxedo authoring-import-execution flow would look.

1. Authorities register by submitting a transaction. This stores their registration in a UTXO. Later they can de-register by submitting a transaction that consumes that same UTXO.
2. To begin authoring, they include a pre-runtime digests that contains their public authority ID.
3. As part of extrinsic inclusion, they include a nimbus inherent that peeks at their on-chain registration.
4. To complete authoring, they attach a seal digest that contains a signature over the entire pre-block (the entire block except for the seal that we are constructing).
5. When a foreign node imports the block, they pop the seal digest and check that the signature is valid by the identity specified in the pre-digest. This is the extent of the client-side checks. They do not (yet) verify that the author is the correct authority for this slot.
6. When executing the block (specifically the nimbus inherent) we read the on-chain registration, check that it contains the same public authority ID as the pre-digest, and then decide if it is the correct authority for this slot.

Regarding Finality

None of what I sketched above has anything to do with Grandpa or finality in general. One observation is that Parachain's won't need a finality gadget because they just follow the relay chain. It is also possible to run a solo chain without finality. Perhaps we could make a modified version of grandpa that somehow.... Not a fully baked idea.

Anyway, this first issue is complete when authoring is addressed, and we can handle finality in a followup.