Serai Consensus

[kayabaNerve]

The required effects of consensus are firmly detailed in https://github.com/serai-dex/serai/blob/develop/docs/protocol/Consensus.md. While it's not perfect, namely already describing itself as a modified Aura, it does describe the needed UX.

Substrate offers Inherent transactions, which, combined with per-block finalization, should hit all bases. The question becomes:

1. Can we properly validate inherent transactions? It seems like we'll be able to suitably populate a DB.
2. Can we bypass inherent transaction finalization if a block has been confirmed by the BFT process? It looks like nodes will currently always reject a block if it has invalid inherents.
3. Do we work with Aura, BABE + Grandpa, a fork of them, or another algorithm entirely? The template suggested it was using Aura + Grandpa, not just Aura, while Grandpa isn't immediately feasible due to the lack of per-block finalization. Aura doesn't use a VRF to decide the next producer, which enables DoSs, however.

[kayabaNerve]

Relation to #6, which tracks a different aspect.

[kayabaNerve]

So, at its core:

• Block production needs to bypass inherent checks if the block is already finalized.
• Block finality needs to come per-block.

GRANDPA could potentially be forked for the latter, yet we need to merge it with Aura/BABE which has to be forked to bypass checks. I'd be potentially more interested in implementing Tendermint, which is dead simple, instead, with the caveat that Tendermint has the same problem as Aura regarding producer selection.

Immediately, the work is solely to move from the current accept-any to something, even if it's a no-fault-tolerant PoA setup.

[TheArchitect108]

@kayabaNerve let's outline something temporary for protonet that will get us moving towards local cluster setups then open a new testnet focused issue to focus on finalizing our ultimate approach.

[kayabaNerve]

Immediate is just the accept-any with a single node config. When we do have a multi-node setup, we can do no fault tolerant PoA where every node does a round robin, as I said. Then for mainnet, Tendermint with a randomized selection instead of a linear one or BABE + GRANDPA.

[kayabaNerve]

I briefly reviewed HotStuff as another candidate. It's notable as it's proposed as an evolution of Tendermint, yet unlike Narwhal/Tusk, maintains the linear blockchain structure (anything larger would be far too much effort to discuss here, not to mention potentially incompatible with our inherent transactions design).

They claim O(n), where Tendermint is O(n^2), yet detail that Tendermint using threshold signatures would also be just O(n). Considering dragging in BLS is out of the discussion right now, I question how much HotStuff would actually contribute.

While it does have other efficiencies, they're not 1000x faster and necessary. Simple reading:

• https://threadreaderapp.com/thread/1141040292767789056.html
• https://decentralizedthoughts.github.io/2019-06-23-what-is-the-difference-between/

I will note Narwhal/Bullshark has a case study on integration into cosmos: https://www.paradigm.xyz/2022/07/experiment-narwhal-bullshark-cosmos-stack

This suggests it is feasible to have them produce a blockchain structure, however clumsy. The new question would be performance, which isn't provided.

[kayabaNerve]

Tendermint currently produces blocks with a single validator and lets other nodes sync. It only checks inherents as part of the BFT process, not when validating.

It needs to be integrated with pallet_staking/pallet_sessions, and we probably want to grab ImOnline while we're at it.

I will note there's a current issue where syncers report multiple finalizations, printing a warning each time. I don't know why.

[kayabaNerve]

Closed by #145