July 08, 2019
RFC-340 Consensus

On Monday, the Tari community discussed RFC-340. Below is the TL;DR on Monday’s conversation (full transcript included below):
HotStuff looks promising for the DAN’s BFT.
DAG is not required as there cannot be conflicting states
Join us for our next discussion on Freenode in #tari-dev.
Discussion times proposed by the Tari community:
Mondays: 6pm CAT (12pm EST)
Thursdays: 11am CAT (5am EST)
To keep up with the latest Tari developments, you can follow the project on Twitter.
Transcript of Monday discussion

56 <@CjS77>  I propose we discuss the proposal ni https://github.com/tari-project/tari/pull/475 tonight
RFC-340 VN Consensus overview by CjS77 · Pull Request #475 · tari-project/tari
Description Provide an overview for a proposal for smart contract consensus in Tari. This PR also removes some RFC stubs that are either no longer relevant or cannot be defined at this time. Types...
00 <simian_za>  sounds good
04 <Blackwolfsa>  It looks good
04 <@CjS77>  Let's take some time to read thru it if you haven't already and then ask Q's / make comments / suggestions
04 <Hansie>  Cool
07 <Hansie>  Looks good. Some questions...
07 <Hansie>  How is `super-majority of these messages` determined?
07 <Hansie>  ... as `proposal for the next state`
14 <simian_za>  I am guessing that the number of members of the committee is known before hand
14 <@CjS77>  All the details are in the HotStuff paper, basically when we move to a view _v_, replicas send a `NewView` msg to the leader waits for that view. The leader waits for at least (n - f) NewView messages before proceeding with its proposal. where f is  (n-1)/3
14 <Blackwolfsa>  Members should know who are in the commitee at a time
14 <@CjS77>  n is known and fixed
15 <simian_za>  You mention in the report that a fork can only be a mximum of 3 views deep, is this another implementation detailof HotStuff?
16 <@CjS77>  Beyond 3 views, the state has been finalised; so as long as we have 2/3 honest nodes, they'll never try to branch off a finalised state and produce incompatible states (i.e. a fork)
17 <simian_za>  oh is that because of the three phases of the view pipeline?
17 <@CjS77>  yes
17 <simian_za>  I see
17 <@CjS77>  Yeah, it's quite slick
17 <Blackwolfsa>  Only problem there I acn see is with branching... 
17 <Blackwolfsa>  But that should be minor 
18 <@CjS77>  Branching?
18 <Hansie>  Seems to me `super-majority of these messages` will be the collection of instructions for a next block, am I right?
19 <Blackwolfsa>  What Cpus do with if statements 
19 <Blackwolfsa>  Eg it makes an assumption on a future state based on the current state 
20 <@CjS77>  We require that Every replica must deterministically get the same state when running the same input over  the same smart contract. Therefore they'll all select the same branches on conditionals, surely
20 <Blackwolfsa>  Yes but of we try to run the states in a pipeline
21 <Blackwolfsa>  If it's run single staged, it should never give issues
21 <@CjS77>  @hansie there are several places where a super-majority of votes are required.
22 <Hansie>  Ok, so practically, will a bunch of instructions be collected as a proposal for a new state?
22 <neonknight64>  I like the idea of running parallel leaders for different instructions as mentioned in the rfc.
23 <@CjS77>  In the pipeline, there could be temporary forks with competing states, yes; but the HotstuffBFT algo guarantees that this will be resolved. So VN's might have to temp run multiple copies of the contract until one of them gets selected as the "truth"
24 <@CjS77>  @hansie, yes, each proposal consists of: We had state at view n, I ran these k instructions, rejected these r instructions and achieved state n+1. Do the rest of you agree?
25 <@CjS77>  Then the replicas check this and vote Yes or No.
25 <simian_za>  neonknight64: I don't think there was mention of parallel leaders? There is only one leader per view?
26 <@CjS77>  Yes, one leader per view
26 <Hansie>  cjs77: Great, that makes sense yes. So the `super-majority of these messages` for a new state change can be tweaked for throughput.
27 <simian_za>  The signature aggregation that is discussed is it done to produce a single aggregate signature or is it essentially a concatenated list of partial sigs?
27 <@CjS77>  That's up to us
28 <@CjS77>  We need a k-of-n signature scheme
29 <@CjS77>  If that can be done without an array of sigs, it makes communication much more efficient. LinBFT uses BLS threshold sigs, for example
29 <neonknight64>  Sorry, I misinterpreted the "possible to stagger and layer these rounds on top of each other, so that there are always four voting rounds
29 <neonknight64>  happening simultaneously"
30 <@CjS77>  yes, at different stages
30 <simian_za>  Think you can get away without a full array of sigs but you will need a list of which members signed to produce a given sig but that could be a list of member indices or something much smaller than sigs
31 <Hansie>  Yip, the signature scheme must be as efficient as possible while still being secure
31 <@CjS77>  Agreed. HotStuff leaves that implementation detail out
31 <Blackwolfsa>  Personally I think we should keep the multiple stages as a later rivision and not 1st release 
34 <Hansie>  Just to be clear, no DAGs anymore?
34 <@CjS77>  I recommend everyone go and read the HotStuff paper. You get the gist on the first reading; I'm still synthesising some of the nuances myself; but it resonates on an intuitive level
35 <tar1b0t>  [mattermost] <stringhandler> Tried to find an ELI5 of it
35 <@CjS77>  I spent a lot of time on my vacation thinking about DAGs, and I cam to the conclusion that this achieves almost the same degree of performance and throughput while being way simpler
36 <Blackwolfsa>  Agreed... 
36 <neonknight64>  A great property of using the XOR Metric(Not Hamming Distance) for distance is that you can never have duplicate distances except if they have the same Node ID
36 <Blackwolfsa>  Dag might have a get a simple mayorrity and not bft and still be secure. But this has alot less messages and is much simpler 
36 <Hansie>  cjs77: Seems like a reasonable conclusion yes
36 <stanimal>  "the leader expects a set of `NewView` messages from the other replicas" - will read the paper but what is the purpose of the NewView message? Could there be a disagreement in leader election?
37 <@CjS77>  The problem I always came up against with DAG was how to effectively re-order things when branches were being joined;
37 <@CjS77>  No, the leader is chosen deterministically, but the leader must wait until 67% are ready for her
38 <Hansie>  DAG: With HotStuff correct ordering is guaranteed after forks
38 <stanimal>  Ah so a kind of stage synchronisation
41 <@CjS77>  I need to run, but great chat guys!
42 <Hansie>  Thank you for the effort!
Back to Discussions