Is pBFT the best non-PoW consensus algorithm?

Protocol Features & Updates
1

After a short discussion with friend who is quite knowledgable about blockchain protocols, I was left with the impression that pBFT is a great way to reach consensus without relying on PoW for Sybil attack protection. He suggested this research paper on the topic:

What do you think? Can pBFT be a solid alternative to PoW-centric concensus building?

2

PBFT has very high communication overhead and is not sybil resistant. Tendermint uses PoS for validator sets.

That being said, pBFT is certainly one alternative to Nakamoto consensus.

3 Likes
3

Agree. pBFT is not suitable for public chain with large number of blockchain nodes.

4

So if we add PoS to pBFT, how does it compare to BitcoinNG and PoW? In other words, do the disadvantages outweigh the advantages? I suppose the tps metric will be higher, staking could allow more users to join the “mining” process, less electricity consumption, possibly less exposure to 51% attacks.

5

There are a lot of different dimensions along which these can be compared. First, both PoS and PoW can be used in leader election for pBFT and Bitcoin-NG.

  1. Transactions per second could be the same in both cases. There’s nothing inherent to PBFT, that makes it faster as far as raw transaction throughput is concerned. It could even be argued that in theory Nakamoto consensus should be able to churn out more transactions.
    Now if we talk about confirmation latency/finality, then PBFT would be a clear winner.

Again, it depends on how you look at it. Let’s consider:

  1. Initial friction: acquiring staking rights versus computers. That is, accessing an exchange to buy cryptocurrency or getting a computer with graphics card. Both cases would probably require setup of some software. Not sure which approach wins here.
  2. Operation: setting up mining hardware—not on a huge scale—is fairly painless and doesn’t require much attention, especially when using a mining pool. At scale things definitely get much more complicated, both for PoW and PoS.
    Operating staking software can require a significant amount of administrative overhead, setting up and maintaining redundant setups, to have no downtime. When slashing of stake is involved, then even more care needs to be taken that no punishable mistakes are made. Now if stake can be delegated, or similar, then it makes things much easier for the end-user.
  3. Payouts: given that these are probabilistic processes, payouts will exhibit similar characteristics, different schemes have varying variance, which is mostly remedied by pooling/delegating. That being said, without

Most certainly, but then some people will argue that PoW encourages to find cheap/establish cheap and sustainable energy sources and will find a price equilibrium somewhere. :slight_smile:

It seems like it but again there is a lot to this. Is it easier to buy up stake or buy and deploy hardware? Or maybe loan stake in a trustless manner vs. hardware? Use DAOs to automate cartel formation?
If the attack ruins the network, will the stake or hardware be more worth for re-sale?
If the attack does not ruin the network then stake will most certainly be the better option, since an attacker would lose (almost) everything.
Which brings me to probably the most exciting aspect of PoS: punishment can be done on the protocol level and much more gradually. If I misbehave with PoW then nobody can just come and take my hardware—well not yet anyway ;)—but with PoS the protocol has mechanisms to punish me.

6

hey,

Agreed with everything except your 1, 2, 3 about whether it’s more accessible to mining

Clearly it’s easier to go on an exchange and purchase AE than to setup any kind of software. The friction that installing software (compared to just going on a web page) is not negligible.

Also, with a Cosmos-like BDSM PoS, you don’t need to have a redundant setup with no downtime. You can simply “delegate” your tokens to a certain validator.

Re tps: pBFT makes it more straightforward to achieve higher tps with some parameter tweaking (max number of validators, max timeouts, etc.)

yes, more time will be lost in the network overhead of getting everyone to agree, but there’d be no uncles/orphans

another huge advantage is how much easier it is to do a light client; if you have the current validator set, you only need to check if some piece of the state is included in a merkle tree that’s signed by that validator set; if you don’t have it, you need to check block signatures recursively back to the beginning of the chain, but only for blocks that change the validator set

again, in cosmos, the gaia cli is able to do that for mere milliseconds for testnets with millions of blocks

finally, the biggest advantage of pbft to me is the fast-finality (some would say “instant finality”); this property makes interoperability much easier because blocks cannot be reverted

one might argue that finality could be a bad thing - cause it prioritizes safety over availablility; e.g. if there’s a network partition, the chain will stall; depending on what you’re trying to aciheve, this might not be a bad thing; but even if you prioritize availability - there is a solution - polkadot has a hybrid consensus mechanism called GRANDPA, which mixes aurand and a tendermint-style pbft (GRANDPA: Block Finality in Polkadot | by asynchronous rob | Polkadot Network | Medium)
That way, new blocks are always produced, and getting finalized at some point via the pBFT working in the background. It’s somewhat similar to what aeternity is already doing with bitcoin-ng.

2 Likes
7

The assumption there was that we do participate in consensus ourselves but I agree that the process for PoS is better, given that you can delegate fairly easily—still requires some sort of software to at least sign the authorisation. For PoW you could rent hashpower, which ends up having a similar UX but is of course not really trustless.

At some point someone will need such a setup. It’s either you who has to do it or someone else who then can charge you fees. Same can be said about pools but running a validator is, imho, much harder than running a mining pool. Especially given the fact that you can actually lose stake if you make mistakes.

Makes DoS attacks also easier, given that doing all that work is much harder for a client than just validating whether a hash prefix fits the difficulty parameter :slight_smile:

And you’re right, I totally did not talk about liveness differences, although I did mention finality.
I’m not super familiar with GRANDPA but from skimming that article it seems sort of similar to Casper just that finality is off-chain and not recorded. I’ll have to take a closer look, though.

1 Like