Swirld
Leemon Baird
J. Horacsek
June 5th, 2018
Hash-graph Consensus
Consensus
Acheive consensus on the order of events over a network.
Consider a network of the following members
A
B
C
D
Alice
Bob
Carl
Dr Dre
We want an immutable history of their interactions (which we call events) and a consistent agreement on the ordering of those events.
Communication
Members communicate through a gossip protocol
A
B
C
D
These nodes represent the member's last (known) event
This involves "telling" another node about all the events we know. This communication is called synchronization.
D'
Say Carl tells Dre everything it knows. Dre records this by creating a new event.
Communication
This event contains the hash of Carol's last event, and a hash of Dre's last event. This new event D' is signed by Dre.
A
B
C
D
D'
It can also optionally contain transactions. Events don't record history, members learn of history through gossip.
These dependencies create a directed acyclic graph. A hashgraph.
Communication
Members cannot:
- Lie about the origin of an event; all events are signed by their creator
- Retract a message from the network
A
B
C
D
D'
Example
Bob's View
A
B
C
D
Example
A
B
C
D
Alice's View
Bob's View
A
B
C
D
Bob Sends Sync
Example
A
B
C
D
Alice's View
Alice verifies that the events she receives are valid
She collects whatever transactions she likes, and the hashes of previous transactions and signs it.
She then randomly syncs with another node, telling them about the new event.
Everyone eventually learns of it via gossip.
Consistency
A
B
C
D
Alice's View
But he can lie about his present actions --- only has control over who he syncs to and his transactions.
Bob always has to send valid events, he can't lie about the past.
Could send no syncs, but then looses the ability to create transactions.
Example
A
B
C
D
Alice's View
A
B
C
D
Carl's View
Bob creates a fork
Example
A
B
C
D
Alice's View
A
B
C
D
Carl's View
But we will eventually find forks.
Hashgraph
A
B
C
D
The past is immutable, but how do we decide order?
You could try timestamps, but you cannot solely trust timestamps.
Have an election, (maybe somehow exclude forks from this election)
Straightforward elections don't work. Waste of bandwidth, potential to mislead members by lying.
Hashgraph
A
B
C
D
Use virtual voting.
Each member calculates the vote of other members.
Provided members are honest, they're always fairly represented and the correct events will get "elected".
The moment a fork is detected, the offending events will be "dealt with".
Hashgraph
A
B
C
D
To facilitate this, we divide the process into rounds. And define specific events as being witnesses.
The division of incoming events into rounds allows us to (eventually) cement the ordering of events in a given round
Witnesses are events that "touch enough events to sorta be trust worthy".
Hashgraph
A
B
C
D
Before we can talk about this, we need to define what it means for an event to see and strongly see another.
An event \(x\) can see one of its ancestors \(y\) if there is an entirely downward path from \(x\) to \(y\)
\(x\)
\(y\)
Hashgraph
A
B
C
D
Before we can talk about this, we need to define what it means for an event to see and strongly see another.
An event \(x\) can strongly see one of its ancestors \(y\) if there are possibly many entirely downward paths from \(x\) to \(y\) that cross through \(\frac{2}{3}n\) different members
\(x\)
\(y\)
Hashgraph Citizenship
A
B
C
D
An event is a witness if it is the first event created by a node (in which case it has round \(r=0\)), or if it can strongly see more than \(\frac{2}{3}n\) witnesses that share its parent's round \(r\). In the second case it belongs to round \(r+1\).
Round 0 witnesses
A
B
C
D
An event is a witness if it is the first event created by a node (in which case it has round \(r=0\)), or if it can strongly see more than \(\frac{2}{3}n\) witnesses that share its parent round \(r\). In the second case it belongs to round \(r+1\).
Round 0 witnesses
\(r=1\)
Hashgraph Citizenship
Hashgraph Citizenship
A famous witness is a witness that is seen by the super-majority of the witnesses in the next round
The witnesses for round \(r+1\) 'vote' on which witnesses for round \(r\) should be famous. They vote 'yes' for a witness in round \(r\) if they can simply see that witness.
The witnesses for round \(r+2\) collect the votes from the previous round and tally them.
If any witness in round \(r+2\) can strongly see a super majority of 'yes' votes in round \(r+1\), then it concludes that the original witness is a famous witness.
Hashgraph Citizenship
If these each witness in round \(r+2\) cannot decide whether a node should be famous or not, they vote in accordance to majority of votes they strongly see.
The owness is then on round \(r+3\) to tally votes, and so on.
If it can't be decided after a certain amount of rounds, then a coin is flipped based on the signature of the event. I.e. a coin round
This is a bit technical, so let's walk through an example
As it turns out, this can be done without sending any votes
\(A_1\)
\(A_2\)
\(B_1\)
\(B_2\)
\(B_3\)
\(C_2\)
\(C_1\)
\(D_1\)
\(D_2\)
\(D_3\)
\(A_1\)
\(A_2\)
\(B_1\)
\(B_2\)
\(B_3\)
\(C_2\)
\(C_1\)
\(D_1\)
\(D_2\)
\(D_3\)
Let's see if \(B_1\) should be famous
Yes
Yes
Yes
Yes
\(A_1\)
\(A_2\)
\(B_1\)
\(B_2\)
\(B_3\)
\(C_2\)
\(C_1\)
\(D_1\)
\(D_2\)
\(D_3\)
\(B_3\) can tally the votes
Yes
Yes
Yes
Yes
\(A_1\)
\(A_2\)
\(B_1\)
\(B_2\)
\(B_3\)
\(C_2\)
\(C_1\)
\(D_1\)
\(D_2\)
\(D_3\)
What about \(C_1\)?
\(A_1\)
\(A_2\)
\(B_1\)
\(B_2\)
\(B_3\)
\(C_2\)
\(C_1\)
\(D_1\)
\(D_2\)
\(D_3\)
What about \(C_1\)?
No
No
Yes
No
\(A_1\)
\(A_2\)
\(B_1\)
\(B_2\)
\(B_3\)
\(C_2\)
\(C_1\)
\(D_1\)
\(D_2\)
\(D_3\)
\(C_1\) not famous.
Hashgraph Citizenship
Note that a node must tally a super-majority, so a 51% Yes, 49% No split doesn't lead to a decision
This is why it may take multiple rounds.
All of this technicality is to ensure that famous witnesses are "seen by enough" events in the future to be considered "trustworthy".
(There is also a technicality here that if a member has two famous witnesses in a round due to forking, one will eventually wither away by Lemma 5.12, one fork will eventually become unseeable by famous witnesses, and will never be included in the consensus order)
Event Ordering
We still haven't ordered events. We've decided on witnesses, and as members synchronise with each other consensus will be reached on witness fame via virtual voting.
Now we use the famous witnesses to determine the order of events.
Event Ordering
Events that are seen by all famous witnesses of round \(r\) (where \(r\) is the minimum round where this happens) are said to have a round received of \(r\)
When an event \(x\) has a round received, we look at each famous witness, and find the time stamp of the earliest event that is an ancestor of the famous witness and a descendent of \(x\). The median of these is the consensus timestamp.
Event Ordering
\(A_1\)
\(B_1\)
\(C_1\)
\(D_1\)
\(D_2\)
\(C_2\)
\(B_2\)
\(A_2\)
Round 1
Round 2
Which are seen by all
famous witnesses?
Event Ordering
\(A_1\)
\(B_1\)
\(C_1\)
\(D_1\)
\(D_2\)
\(C_2\)
\(B_2\)
\(A_2\)
Round 1
Round 2
Event Ordering
\(A_1\)
\(B_1\)
\(C_1\)
\(D_1\)
\(D_2\)
\(C_2\)
\(B_2\)
\(A_2\)
Round 1
Round 2
Event Ordering
\(A_1\)
\(B_1\)
\(C_1\)
\(D_1\)
\(D_2\)
\(C_2\)
\(B_2\)
\(A_2\)
Round 1
Round 2
Median Timestamp
Event Ordering
Events are ordered by
- Round received
- Consensus timestamp
- Pseudo random combination of witness' signatures
Event Ordering
An event created by an honest user will eventually be assigned a consensus order (provided secure communication channels)
A choice will eventually be made for forks, and events on the competing branch will never be given a consensus date, because they will never be seen by a famous node when all members' hash graphs become consistent enough.
Questions?
Swirld
By Joshua Horacsek
Swirld
Hashgraph
- 937
