3

I'm new to the substrate. I'm trying to improve the availability of block generation of permissioned networks by substituting Aura with Raft/PBFT like consensus algorithm. I'm referring to an algorithm that solves the "who can generate blocks" problem by electing a leader (via libp2p) among authorized nodes.

After running the tutorials and viewing Aura's source code, I'm still confused about if it is possible to do that. some of the questions are below:

  1. Is that possible to implement leader selection off-chain, and get the result in runtime? (It seems that an off-chain worker can only submit a transaction. but how can runtime reading data from that?)
  2. How to communicate the off-chain worker of another node in the current off-chain worker? It seems that sc-network has the ability to do that.
  3. Why does Aura's implementation have code in both sc-consensus-aura and frame-aura. What does the client do in sc-consensus-aura?
  4. Here says "Polkadot uses a hybrid PBFT / Aurand consensus mechanism", is that mean a yes to my question? And somehow I can not find related code.

And if that is possible, is there any work/example I can learn from?

Thanks for your help!

Lavoris
  • 71
  • 5
  • > but how can runtime reading data from that?) The transaction that an offchain worker submits can alter the state, effectively like writing to the state. – kianenigma Oct 04 '22 at 14:25

2 Answers2

1

I'm confident that the answer is YES after reading AURA and [GRANDPA][grandpaimplementation ]'s and even implementing finality-pbft[1] myself.

The basic idea here is that any leader based (or not leader based) concensus could be a alternative to the GRANDPA. AURA is just a way to generate (seal) the blocks.

  1. Leader elections should be implemeneted in the finality-grandpa. It's natively embedded into the Substrate.
  2. Using an off-chain worker is not necessary if you are only implementing a consensus mechanism.
  3. In Substrate, client/sc- behaves as native code, whereas frame/sp- defines the Runtime behaviour. AURA, for example, is a block-generation algorithm so it must be implemented as native code. In the meanwhile, AURA provide some hooks/functions for runtime. This is the reason why it has both code in client and frame.
  4. Still, I can't seem to find that code. But the response is in the affirmative.

[1] finality-pbft and substrate-with-pBFT

Lavoris
  • 71
  • 5
1

I think it's certainly possible to do that with Substrate! Be warned though that this will involve tapping into the internals of Substrate which sadly right now it's not something that's heavily documented (most users just want to build and run their own runtime).

You would have to implement the Raft protocol completely outside the runtime, and you could use the networking capabilities in Substrate to communicate with other peers (https://paritytech.github.io/substrate/master/sc_network/struct.NetworkService.html, https://paritytech.github.io/substrate/master/sc_network_common/service/trait.NetworkEventStream.html). I think the code in Substrate for sc-finality-grandpa is a good place to look.

You can communicate the result of the leader election to the runtime by either sending a transaction or including an inherent whenever you create a block. You would then create your own pallet that either processes this inherent or handles the transaction, and updates a storage entry with the current elected leader. I think you still want the authorities to be defined by the runtime though, so that you could e.g. use staking in your runtime to elect the authorities. Therefore your Raft worker would also need to interact with the runtime to figure out who the authorities are (and then run leader election among those).

The link you posted wrt Polkadot being a hybrid system is a bit outdated (here's a better one https://wiki.polkadot.network/docs/learn-consensus#hybrid-consensus), but it still holds true. In Polkadot there are two distinct consensus protocols for the relay chain: BABE for block production and GRANDPA for finality. With Raft (or PBFT) there would only be one consensus protocol for both block production and finality (since every block would be instantly finalized).

Keep in mind that Raft is not byzantine fault tolerant, the nodes can go offline but they are assumed to act honestly. Therefore this would not be suitable for an adversarial environment.

Lastly, have a look at https://github.com/Cardinal-Cryptography/aleph-node since they also implemented a BFT consensus protocol in Substrate.

André
  • 237
  • 1
  • 3
  • 8