Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serai Consensus #47

Closed
kayabaNerve opened this issue Jul 17, 2022 · 7 comments
Closed

Serai Consensus #47

kayabaNerve opened this issue Jul 17, 2022 · 7 comments
Labels
discussion This requires discussion tendermint
Milestone

Comments

@kayabaNerve
Copy link
Member

kayabaNerve commented Jul 17, 2022

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 kayabaNerve added discussion This requires discussion protocol labels Jul 17, 2022
@kayabaNerve
Copy link
Member Author

kayabaNerve commented Jul 17, 2022

Relation to #6, which tracks a different aspect.

@TheArchitect108 TheArchitect108 added this to the Testnet milestone Jul 20, 2022
@kayabaNerve
Copy link
Member Author

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
Copy link
Collaborator

@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
Copy link
Member Author

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
Copy link
Member Author

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:

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
Copy link
Member Author

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
Copy link
Member Author

Closed by #145

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This requires discussion tendermint
Projects
None yet
Development

No branches or pull requests

2 participants