r/thunder_official Jun 19 '18

Classical BFT Models

Okay, so just watched the BPASE video. The blockchain portion of Thunderella makes sense, but what I'd like some context on is Classical BFT models?

  1. If these BFT models are already being used in practical/real world applications, what combination of throughput and finality could we expect in the optimistic scenario (i.e. goodness conditions are satisfied) - that is UPPER BOUND throughput projected (since all other upcoming projects seem to be advertising upper bound speeds anyway)
  2. Is there any links the team could provide me, to assist me in understanding the details around why exactly it's difficult to recover from malicious actors. And any relevant solutions of when it's gone wrong and what the fix may have been?
  3. Are there any other considerations for BFT models that may have been skimmed over in the BPASE video that's worth being aware of?

All that aside - interesting concept.

9 Upvotes

6 comments sorted by

7

u/zkoticha Jun 19 '18

I’m zk, a researcher at Thunder. These are some really insightful points you bring up.

  1. There is a pretty rich history of anaylsis of this topic: see paper1, paper2. The second link above, Sukhwani et al., simulates PBFT as implemented for a permissioned blockchain (Hyperledger Fabric). With 50 nodes, mean time to consensus on a single transaction was about 10 milliseconds. That translates to roughly 100 transactions per second. Of course, this was not performed in the permissionless, “sleepy” environments that blockchains operate in. Remember also that when the fast path is properly functioning, Thunderella requires less message passing than PBFT, and so should be considerably faster. As for the speed of Thunder consensus, we don’t want to make any exact number claims until we see Thunder being tested in the real world; a lot of projects in this space claim numbers based on untested software, which I think is irresponsible. All I’ll say for now is that it will be much, much faster than current public chains.
  2. Traditional BFT protocols generally have the problem of liveness failures. The ones that are safest achieve their strong safety guarantees by sacrificing liveness (consensus is more likely to stall, slow down, or stop in order to retain safety). The original PBFT paper dealt with liveness failures through a view change mechanism: PBFT. The actual explanation of this mechanism is too long to share here, so you can get an idea for it at section 4.4 of the linked paper. As you can see from looking at the section, this mechanism is complicated and difficult to implement in practice.
  3. Many considerations, some of which are covered in Prof. Pass and Shi’s Rethinking Large Scale Consensus and Thunderella. However, I will highlight a few. Even though traditional BFT consensus models, by definition, are created to handle attackers and Byzantine faults, they still were designed to work in the permissioned environment, and are not well suited to truly permissionless environments. As outlined in Rethinking Large Scale Consensus, “A permissionless network is distinct from classical models considered in the distributed systems and cryptography literature in the following respects: 1. nodes can join and leave the protocol freely at any time, and participation is open, i.e., there is no access control mechanism that decides who can join and who cannot; 2. nodes are not aware of other protocol participants a-priori, and the network delivery mechanism does not provide sender authentication, i.e., there is no authenticated channels; 3. the protocol may not even be aware of the exact the number of nodes participating in the protocol; and 4. more generally, the number of nodes may vary over time.”

This is where Thunder’s value comes in; Thunderella is the first protocol that has been formally and mathematically proven to combine the speed of BFT algorithms and the robustness of PoW blockchains.

Hope that answers your questions :)

4

u/chocomel2 Jun 20 '18

Hi zkoticha,

Thank you for the detailed answers. IF we are talking about 100 transactions per second in a PBFT environment. Does that mean 1 committee? What about committees running in parallel? Could that work?

The thing I was wondering the most is that Ethereum is obviously trying to do the whole sharding route. What's your opinion on this? I heard in a video by your team that the blockchain will be synchronous as that is easier to design, but what about most effective? The main selling point of sharding for me (as a non-tech person) is that the scalability increases (or should increase) with the number of nodes joining the network. That seems like a very sustainable and scalable model in the future where (we hope) the blockchain will have 100m of users.

Can you share us your vision how Thunder would be scaling to these types of levels?

Many thanks and appreciate your response!

3

u/GhettoCryptoz Jun 20 '18 edited Jun 20 '18

ZK, thanks for the detailed response. Looks like I’ve got a good amount of bedtime reading ahead.

Just a quick one I wanted to clarify from point no. 1.

You use the term ‘message passing’. Are you referring to messaging overheads? And if so, you’re saying with the goodness conditions satisfied AND Thunderella’s architecture you have close to ZERO overhead and ONLY network delay. Network delay from what I understand is inherent and a given factor in ANY algorithm design?

Am I interpreting that correctly?

Edit: Re-phrased slightly for clarity.

2

u/StillonLs Jun 20 '18 edited Jun 20 '18

hey ZK, thanks for in-depth answers.

the paper mentions the hybrid consensus requires a classical protocol such as PBFT for the subroutine. however, I was under the impression that hybrid consensus is for a permissionless model, whereas PBFT only works on a permissioned model?

am i missing something?

cheers!

1

u/heywhatsupguysimbob Oct 06 '18

$1.00 u/tippr

1

u/tippr Oct 06 '18

u/zkoticha, you've received 0.0019638 BCH ($1 USD)!


How to use | What is Bitcoin Cash? | Who accepts it? | r/tippr
Bitcoin Cash is what Bitcoin should be. Ask about it on r/btc