1 Introduction
This paper presents a new Byzantine fault tolerant (BFT) consensus algorithm that can work under asynchronous conditions. Like Hashgraph baird2016swirlds and Aleph gkagol2018aleph , it has no leaders, no round robin, no proofofwork and reaches eventual consensus with probability one. It is also fully open, and a workinprogress implementation written in Rust is available parsec . Like HoneyBadger BFT miller2016honey , this algorithm is built by composing a number of good ideas present in the literature. A gossip protocol is used to allow efficient communication between nodes guerraoui2010lifting , as in Hashgraph baird2016swirlds , Aleph gkagol2018aleph and Avalanche rocket2018snowflake .
The general problem of reaching Byzantine agreement on any value is reduced to the simpler problem of reaching binary Byzantine agreement on the nodes participating in each decision. This allows us to reuse the elegant binary Byzantine agreement protocol described in aba after adapting it to the gossip protocol.
Finally, even though a trusted dealer (or another trusted external source of private key shares) is still required to initialise the instances of the algorithm (like in miller2016honey ), changes to the set of processes executing the instances (which we call dynamic membership) can be made without the need for such external sources. The resulting algorithm is a Protocol for Asynchronous, Reliable, Secure and Efficient Consensus. PARSEC is a key building block of the SAFE Network, an ethical decentralized network of data and applications providing Secure Access For Everyone penland2016towards .
The key contribution of this paper is the creation of an asynchronous BFT protocol, and which is resilient to 1/3 byzantine nodes. This is an optimal model. It also satisfies an agreement with probability one (unlike some probabilistic methods), and with a common coin for source of randomization that it respects the FLP impossibility result borowsky1993generalized fischer1982impossibility . The algorithm uses gossip for efficient and resilient communication. It is leaderless (with a caveat at network startup) and the paper outlines how it can be adapted it to a dynamic membership context, while remaining leaderless after startup. In comparable work, HBBFT (Honey Badger of BFT) has a less efficient communication mechanism with a secure broadcast miller2016honey , and HashGraph is not rigorous in a liveness proof alpern1985defining and where the published work only discusses the possibility of using a common coin in passing baird2016swirlds . AlephZero gkagol2018aleph is more recent than our initial work parsec and is an improvement on HashGraph, and which also includes the use of a common coin. Avalanche rocket2018snowflake differs from our work in that is uses a synchronous context. None of these methods, though, includes dynamic membership, and this is a key differentiator in this paper.
2 Related work
A gossip protocol has been likened to office workers spreading a rumour, and where Alice starts a new rumour, and then passes it to Bob, who then passes it to Dave. Alice then tells it to Frank, and who might have already heard it from Dave. In this way the rumour propagates quickly through a network, depending on the frequency that those spreading the rumours will pass them on. The advantages of gossip protocols was outlined by birman2007promise and who defined that they could be used with autonomic selfmanagement, repair of inconsistencies, reliable multicast and distributed search. In actual operation, a gossip protocol involves a group of agents who hold private information, and who can communicate with each other. The core objective is for all of the agents to learn the private information apt2017computational , and where distributed epistemic methods lead to simplified system models. A core weakness of the gossip protocols is that the dissemination of the rumour might not be radiated across a whole network of connections. Recent applications of gossip protocols has included the verifying the consistency of certificate logs chuat2015efficient .
Honey Badger is Byzantine Fault Tolerant miller2016honey which is asynchronous in its scope. It does not involve a leader node beyond the trusted setup phase and can cope with corrupted nodes. It does not actually make any commitments around the timing of the delivery of a message, and where even if Eve control the scheduling of messages, there will be no impact of the overall consensus. It can reach a consensus within an infrastructure of failed nodes, and where the total number of node () is greater than .
Hashgraph builds on the Directed Acyclic Graphs (DAG) approach baird2016swirlds with gossip communications; gossipaboutgossip methods; and Byzantine voting algorithms. The gossipaboutgossip method allows for the history of all the communications within an infrastructure to be reconstructed. Avalanche rocket2018snowflake focuses on a scaleable electronic payment system. It uses synchronous communications with a leaderless BFT. In the face of adversaries, it uses a probabilistic safety guarantee.
3 The algorithm description
3.1 The network model
We assume the network to be a set of instances of the algorithm communicating via asynchronous connections, which means that messages sent over these connections are all delivered eventually, but we make no assumptions regarding the delays between sending the message and its reception. In such a setup, it is impossible to distinguish between an instance failing by completely stopping and a large delay in message delivery.
We allow a possibility of up to Byzantine (arbitrary) failures, where . We will call the instances that have not failed correct or honest, and the failing instances faulty or malicious  as the Byzantine failure model allows for malicious behaviour and collaboration. We will refer to any set of instances containing more than of them as a supermajority.
3.2 Data structures
A node executing the algorithm keeps two data structures: a gossip graph and an ordered set of blocks. The vertices of the gossip graph, called gossip events, contain the following fields:

Payload  data the node wants to pass to other nodes

Selfparent (optional)  a cryptographic hash of another gossip event created by the same node

Otherparent (optional)  a hash of another gossip event created by some other node

Cause  cause of creation for this event; can be sync, observation or coin share

Creator ID  the public key of the event’s creator

Signature  a cryptographic signature of the above fields
The selfparent and otherparent are always present, except for the first events created by respective nodes, as there are no parent events to be referred to in such cases. Otherparent is also absent in events created because of an observation or a coin share  because there is no gossip partner in such a case.
The blocks in the ordered set are network events signed by a subset of the nodes in the network. This set is the output of the algorithm, and represents an order of network events that all nodes agree upon. We call the blocks that are elements of the ordered set stable blocks. Let us also define a few useful terms regarding the gossip graph for future use.
Definition 3.0.
We say that event is an ancestor of event iff: , or is an ancestor of ’s selfparent, or is an ancestor of ’s otherparent.
Definition 3.0.
We say that event is a selfancestor of event iff: , or is a selfancestor of ’s selfparent.
Definition 3.0.
We say that event is a descendant of event iff is an ancestor of .
Definition 3.0.
We say that event is a selfdescendant of event iff is a selfancestor of .
Following Hashgraphbaird2016swirlds , we also define two additional useful notions:
Definition 3.0.
An event is said to see an event iff is an ancestor of , and there doesn’t exist any pair of events by ’s creator , , such that and are ancestors of , but is neither an ancestor nor a descendant of (see fig. 2). We call a situation in which such a pair exists a fork.
Definition 3.0.
An event is said to strongly see an event iff sees a set of events created by a supermajority of nodes in the system that all see (see fig. 2).
3.3 General overview of the algorithm
The nodes execute two main steps in an infinite loop:

Synchronise the gossip graph with another random node

Determine whether any new blocks should be appended to the ordered set
3.3.1 Synchronisation
This step is responsible for building the gossip graph and spreading information around the network. Nodes continually make random calls, called sync calls, to other nodes and exchange information about the graph, so that all correct nodes end up with the same data in their graphs. The hashes and signatures in gossip events make sure that malicious nodes won’t be able to tamper with any part of the graph.
Whenever a node receives a sync call, it creates a new gossip event. The selfparent of this event is the hash of the last gossip event created by the recipient, and the otherparent is the hash of the last event created by the sender (which the recipient learns about from the call). The new event also stores the reason for which it was created (cause: sync).
If the recipient of a sync call believes it knows a network event that should be appended as the next one in the chain, it records its vote as the payload of the newly created event. The other nodes will learn of this vote during subsequent sync calls made by its creator.
Lemma 3.7.
If A and B are correct nodes, then every event created by A will eventually have a descendant created by B.
Proof.
This trivially follows from the network assumption that every message is eventually delivered, and from the fact that nodes continue to make sync calls, which result in the callee creating a descendant of the caller’s last event. ∎
3.3.2 Determining order
During this step, a node analyses the graph, counts the votes and decides which block should become the next one. This step is a complex one and so it is described in detail in a separate subsection below.
3.4 Calculating the order
To be able to order blocks, we need first to have some blocks that can be ordered.
Every event has a set of interesting payloads associated with it, which are some of the network events its ancestors contain votes for. The exact way the set of interesting payloads is calculated is left to the user; however, it has to satisfy some constraints:

If event has an interesting payload , there exists an ancestor of containing a vote for .

If has an interesting payload , no selfdescendants of have an interesting payload .

If event has an interesting payload , is an ancestor of event and has no selfancestor having an interesting payload , then has an interesting payload .

If has an interesting payload , then no stable block contains .
For example, might become an interesting payload of if has a single ancestor that contains a vote for . Another option is that only becomes an interesting payload if there is a supermajority of ancestors of containing votes for . An event that has a nonempty set of interesting payloads is called an interesting event.
From the first constraint on interesting payloads it follows that an interesting event always has a selfparent. Only the initial events have no selfparents, but they are their only ancestors, and they never contain votes, so they can’t be interesting.
The first gossip event created by any given node which strongly sees interesting events created by a supermajority of nodes is said to be an observer. The interesting events don’t need to have the same interesting payloads  in fact, it is the case when they have different payloads that is the most interesting.
Since observers are descendants of interesting events, and interesting events always have selfparents, it follows that observers always have selfparents as well. An observer implicitly carries a list of metavotes. Every metavote is just a binary value denoting whether a corresponding node’s interesting event is to be taken into account when determining the order. An observer casts a metavote of on a node if it can strongly see an interesting event by that node. Each node casts a metavote on every node, hence each node casts metavotes, and since an observer strongly sees a supermajority of interesting events, by definition, more than of them are .
Metavotes reduce the problem of Byzantine agreement about the order to that of binary Byzantine agreement, which has been solved previouslyaba . The algorithm described in aba , like many ABFT algorithms, requires a device called a common coin. PARSEC is no different in this regard. In PARSEC, we utilise a common coin based on a threshold cryptography scheme using BonehLynnShacham signatures bls .
3.4.1 Binary agreement
For the sake of simplicity, we will define the algorithm in terms of deciding a single metaelection  that is, deciding whether or not to take a single node’s opinion into account when trying to choose a single new block. We can view a metaelection for node with latest agreed block as a function on a subset of the gossip graph , which is the set of all events that are descendants of any observer of this metaelection:
The value means that the result has not been decided yet at this point in the graph.
Any gossip event which is an element of and is not an observer trivially has a selfparent in .
From this point on, until section 3.4.3, whenever we mention a metaelection, we mean a single metaelection regarding a single node, with a specific block being the last stable one.
In order to calculate the metaelection value for events in , we will need to calculate a few helper values as well:

 a counter denoting the calculation stage

 a set of one or two values estimating the final result

 a helper set of binary values

 a helper binary value
is an integer value which represents the stage of the protocol we are considering when looking at a specific gossip event. A number is associated with each gossip event, such that the of the observers is always 0. The of any other gossip event is either the of its selfparent, or the stage of its selfparent plus one under specific conditions. The exact conditions under which the stage is incremented will be described later in more details. Other variables such as , and all depend on the stage.
(abbreviated ) is a set of binary values that represent the perceived opinion(s) of the creator of any gossip event on the outcome of a metaelection. The initial of an observer is the set containing just its own metavote, and it is the set of the selfparent’s for other events, except the events which increase the stage  it is then calculated from the results of the previous stage.
If the initial estimates for an event contain a single value , and that event sees more than events with in their (which means that at least one honest node estimated ), this opposite value gets added to its (so it will contain both true and false).
Note: the convention in function definitions below is that the value of the function is the first value for which the corresponding condition is satisfied. We also use the common convention of denoting false, and denoting true.
denotes ’s selfparent, and and will be defined later, once we have defined more values related to the events.
Once an event can see a supermajority of events by different nodes which agree in their estimates, this agreed estimate becomes an element of this event’s (abbreviated ). This set serves to validate values proposed by other nodes  if they propose something we don’t have in , we will reject it, as we have no way to ensure its validity.
If an event’s parent has an empty value, and the event itself has nonempty , it can propose a value to be agreed. This proposing is realised by having a nonempty value. If contains just one value, this value becomes the value; otherwise, we can pick an arbitrary value, so we will pick true. If the parent’s value isn’t empty, it becomes our value as well.
Whenever an event sees a supermajority of events with valid values, we perform the common coin protocol (described in section 3.4.2), which will lead either to deciding the final agreed value, or updating the estimates and moving to the next stage.
First, let us define some helper functions:
Now we can define how to determine a decided value:
is the value of the common coin flip and will be defined later, in section 3.4.2.
If an event sees a supermajority of valid values, but isn’t able to decide, the next event will mark the beginning of the next stage of the algorithm. This lets us finally define :
If we don’t decide in a stage, we need new estimates for the next one. This is being taken care of by the common coin protocol briefly mentioned before, and described in more detail in section 3.4.2.
In every stage, when the coin value is known, we can either decide or calculate the initial estimate for the next stage. The general rule is this: we decide if we see a supermajority of values of and the coin value is . If we see a supermajority of values of and the coin value is , we estimate in the next stage. If we don’t see any supermajority, we estimate the coin value in the next stage.
To calculate new estimates, we will define a function (which appeared already in the definition of ):
We can now start defining the function.
3.4.2 Common coin
The common coin protocol is used to calculate the value of the coin flip in a stage. Every stage can either have a predefined coin value, or demand a genuine flip. The exact pattern of which stage has which option associated with it can be defined by the user, as long as there will be infinitely many genuine flips with the stage number tending towards infinity (otherwise the termination property of the algorithm  explained later in the paper  will not hold).
The simplest pattern would be to require a genuine flip at every stage. But other patterns miller , e.g. 1, 0, flip, 1, 0, fliptrivial , etc. can be used to avoid some of the expensive flips, and optimise more for the optimistic case. Using fixed values at some stages may speed up reaching consensus in some cases, as it doesn’t require the exchange of coin shares and returns the coin value right away.
For the genuine flip, the nodes do need to exchange coin shares. In order to define what they are, let us first define the round hash as follows. This hash will help us uniquely identify one particular stage of a specific metaelection for a given node’s meta vote:
All nodes are assumed to possess private key shares  parts of a BonehLynnShacham private key in a threshold scheme, in which at least signature shares (signatures generated with private key shares) are needed to reconstruct a full signature, and any signature shares will result in the same, bitbybit identical signature. All nodes are also in possession of public keys corresponding to all other nodes, so that they can verify each signature share independently, as well as the full signature.
When a node creates an event with corresponding to a genuine flip, that sees a supermajority of aux values in its stage, it signs with its private key share and publishes the resulting signature share in a gossip event with cause coin share. Once an event sees enough events with valid coin shares, it can collect them and calculate the full signature, of which the lowest order bit will be taken as the coin flip value.
Let us define analogously to :
The genuine flip can then be defined as:
Let us denote the set of stages with coin value fixed to 1 as , the set of stages with coin value fixed to 0 as , and the set of genuine flip stages as . The sets satisfy , , and . Then, the full coin flip will be defined as follows:
This is all we need to reach consensus on the metavotes.
3.4.3 Agreement about the next block
Using the above, every node can calculate the results of all metaelections. Once the results are known, they can be used to determine the next block in the ordered set.
Let us remember that the metaelections started with a set of observers  a set of events that all strongly see a supermajority of interesting events. The results of the metaelections tell us which interesting events are to be taken into account.
The properties of metaelections ensure that all nodes will agree on the considered set of nodes. What we need to do is change that into an agreement on what the next block should be. This is pretty trivial, although we must consider two issues: every node could create multiple interesting events, and every interesting event could contain multiple interesting payloads.
To counter the first issue, we can just take the earliest interesting event created by a given node. The events created by a single node form a linear sequence, so the earliest one is welldefined. This narrows the considered set down to a single interesting event per node.
The next step is to choose a valid block among potentially multiple ones seen by the chosen interesting event. To do that, we can take the lexicographically first one, or use really any method that will always choose the same element of a set.
Once we have one vote on a block per node, we just count them and the next agreed block will be the one with the most votes. Any ties can be broken again by lexicographic ordering, or some other method.
It is also possible to repeat the steps above for other interesting payloads of the interesting events that have been selected by the metaelection as an optimisation, so that a single metaelection results in appending multiple stable blocks.
This completes the description of the algorithm. The next section will prove that it is correct, that is, that it provides robust consensus in an asynchronous setting, and in the presence of Byzantine faults.
4 Proof of correctness
Let us begin by stating two important properties of the gossip graph.
Definition 4.0.
We call two gossip graphs consistent iff for every gossip event that is present in both graphs, both contain the same set of ancestors of with the same sets of edges between them.
Lemma 4.9.
All nodes in the network have consistent gossip graphs.
Lemma 4.10.
If a pair of gossip events is a fork, and another gossip event strongly sees , then no other gossip event in a consistent graph can strongly see .
We won’t prove the above lemmas  they have been proved in baird2016swirlds (as Lemma 5.11 and 5.12, respectively). Note that lemma 4.10 only holds if , but we assume that anyway.
Let us now prove some properties of our approach stemming from it being an adaptation of aba .
Lemma 4.11 (Interesting events).
If a correct node creates an interesting event with payload , then all correct nodes will eventually create an interesting event with payload .
Proof.
Let be the event created by a correct node that has interesting payload . By lemma 3.7, eventually every correct node will create a descendant of . By the properties of interesting payloads, either this descendant or one of its selfancestors will then have interesting payload . Thus, for every correct node, there will be an event that is an interesting event with payload , which completes the proof. ∎
Lemma 4.12 (Aux values).
If all correct nodes created an event in stage , then all correct nodes will eventually create an event with an value in stage .
Proof.
Every event in stage has at least one estimate. There is a supermajority of correct nodes, so there will exist a value such that at least correct nodes have in estimates. Thus, there will exist a value that will eventually be estimated by all honest nodes, which means it will get promoted to binvalues by all honest nodes. Once is not empty for an event, this event also has an aux value. Since all honest nodes will eventually create events with nonempty binvalues, these events will have aux values, which completes the proof. ∎
Lemma 4.13 (Progress).
If a correct node created a gossip event in stage , every other correct node will eventually create an event in stage as well.
Proof.
Assume . The first gossip event in stage 0 is an observer. If a correct node created an observer, it must have strongly seen a supermajority of interesting events. A supermajority always contains a correct node, so at least one correct node created an interesting event. By lemma 4.11, all correct nodes will eventually have created interesting events.
If all correct nodes created interesting events, it means that eventually all correct nodes will create an event strongly seeing a supermajority of interesting events  as there is a supermajority of correct nodes, they continue gossipping and they never fork. Thus, all correct nodes will eventually create observers, which completes the proof for .
Assume the lemma holds for stage . We will now prove that this implies it holds for stage .
Assume a correct node created an event in stage . This means that this event sees a supermajority of events in stage with some aux values. This means that at least one honest node created an event in stage , so by our assumption, all honest nodes will have eventually created an event in stage . By lemma 4.12, this means that all honest nodes will eventually have created an event in stage with an aux value. All honest nodes will eventually create events that see all these events with aux values, which constitutes a supermajority, which is enough to progress to the next stage  so all honest nodes will create an event in stage . By induction, the proof is complete. ∎
Lemma 4.14.
If all correct nodes created events in stage and stage is a genuine flip stage, then the estimates of the nodes’ events in the next stage will be in agreement with probability .
Proof.
Let us consider the worst case scenario, in which there are malicious nodes among the nodes. Let us also assume that the adversary controls the timing of the messages, so by controlling which messages are delivered when, they can control the gossip pattern and effectively, to some extent, the values associated with the gossip events.
Assume the adversary tries to force a disagreement among the honest nodes. The only way to do so is to make some honest nodes see no agreeing supermajority among the aux values, which will make them take the coin value as the next estimate, and other honest nodes to see a supermajority of aux values opposite to the coin value. In other cases the honest nodes will automatically have agreeing estimates in stage .
The adversary cannot control the coin value, so they need to learn its value first. It is only possible if at least one honest node published its coin share, which means it has already seen a supermajority of aux values. Then, for the first aux values seen by the correct node, exactly one of the following is true:

There are at least true aux values.

There are at least false aux values.
Whichever one is true, no matter what control the adversary has over the remaining aux values, it cannot make other honest nodes see a supermajority for the opposite value. Thus, it is out of the adversary’s control to make the nodes disagree, as they couldn’t have known beforehand which value they need to have a supermajority of.
If there is no supermajority of agreeing aux values, the honest nodes will automatically be in agreement. If there is one and all of them see it, they will also be in agreement. If not all of them see it, there is a probability that the coin value will agree, thus also making all honest nodes agree.
Thus, the probability of the honest nodes agreeing in stage is at least . ∎
Lemma 4.15.
If all correct nodes’ first events in stage had , either they will decide in stage , or their first events in stage will also have .
Proof.
If all correct nodes only estimate , there is no way for any event to see even of estimates for  so no event by a correct node will have it in its estimates in stage .
For a value to be an element of , there must be a supermajority of events estimating that value. Because of the above, the only value that can have a supermajority is . Thus, every event with nonempty will have it equal to . Hence, every event with an value will have it equal to .
In order to proceed to the next stage, an event has to see a supermajority of valid values. No event can have a value other than as in stage , so there will always be a supermajority for . Depending on the coin flip value, this can either lead to deciding , or estimating in stage . Either way, the agreement will still hold. ∎
Lemma 4.16.
If all correct nodes’ first events in stage had , they will all decide eventually.
Proof.
No matter what malicious nodes do, there is less than a third of them, so no event by a correct node will have in estimates (by definition of the function). This means that for of an event to be nonempty, it must see a supermajority of estimates for , as there will never be a supermajority for .
The above means that no correct node will add to , so all of them will eventually create an event with . This means there will be a supermajority of events by different creators with , which will make the correct nodes either decide in stage (if ), or estimate for the next stage. This will repeat until and the nodes decide . Since there will be infinitely many genuine flips with the number of stages tending to infinity, and each genuine flip will result in with probability , this will eventually happen with probability 1. ∎
Theorem 4.17 (Binary Byzantine Consensus).
The algorithm for calculating metaelection results presented in this paper satisfies the general properties of a Byzantine fault tolerant consensus algorithm:

Validity  if a correct node decides on a value, it has been proposed by a correct node.

Agreement  if a correct node decides on a value, all correct nodes decide on that value.

Integrity  once a correct node decides on a value, it never decides on another value.

Termination  all correct nodes eventually decide with probability 1.
Validity.
We will prove an equivalent statement: that if initially all correct nodes propose , then all correct nodes will decide . Since is a binary value, a node can only decide a value not proposed by a correct node if all correct nodes propose , and the node decides . Thus, deciding when all correct nodes propose is equivalent to always deciding on a value proposed by a correct node.
If all correct nodes propose , they will all put in their estimates. By Lemma 4.16, they will all decide eventually. ∎
Agreement.
Assume there is an event created by a correct node which was able to decide a value . It means that and this event must have seen a supermajority of events with . This means there was no supermajority for . Thus, if a correct node has seen a supermajority in this stage, it must have been for , so it would decide . If it hasn’t, it would estimate for the next stage, which means there will be agreement at the start of the next stage. Following Lemma 4.15, this agreement will propagate to the end of the stage and the next stages, until everyone decides . ∎
Integrity.
Once an event created by a correct node decides on a value , all later events created by that node will have event as an ancestor. Following the definition of , all later events will also decide . ∎
Termination.
By Lemma 4.13, if a correct node creates an event in stage , then every correct node eventually creates an event in stage . This means there will be events by correct nodes, which will eventually be seen by every correct node. Every such event will have nonempty estimates. It is not possible for both 0 and 1 to be estimated by events by different correct nodes, so at least one of those values will eventually be an element of estimates of every correct node’s event.
Eventually, the events with agreeing estimates will all be seen by an event created by every correct node. Hence, every correct node will eventually create an event with nonempty , and so an value.
The events with values will eventually be seen by every correct node’s event, which means every correct node will eventually either decide or progress to the next stage.
By Lemma 4.14, after every stage with a genuine coin flip, all nodes’ estimates agree with probability . This means that the probability of estimates still not agreeing at stage is less than:
where is the number of genuine flips up to stage . Since we assume an infinite number of genuine flip stages as tends to infinity, grows to infinity as grows, which implies that the probability of estimates not agreeing tends to 0. This means that the estimates will eventually agree with probability 1. By Lemma 4.16, the nodes will decide eventually after that happens. ∎
The above theorem proves that our algorithm will reach agreement about every single metaelection in a Byzantine fault tolerant way. This is not the end, though  we also need to prove that metaelections lead to agreement about the next block in the ordered set. The proof of that is presented below.
Lemma 4.18.
If the result of a metaelection is , there have been at least metavotes for .
Proof.
Assume there have been less than metavotes for and has been decided. When nodes that initially metavoted create an event that sees a supermajority of metavotes, this supermajority must contain at least votes for  so their estimates will contain . On the other hand, no node that metavoted can ever create an event that will see at least estimates for , so they won’t add to estimates.
Due to the above, any supermajority among the estimates must be for . Any event with nonempty can thus only have in this set, which means that all valid values will also be , which will lead to a decision on eventually.
This is a contradiction. Such a situation is impossible, which proves the lemma. ∎
Lemma 4.19.
The set of nodes for which the result of metaelection is is always nonempty.
Proof.
Assume all metaelections resulted in . By Lemma 4.18, at least nodes metavoted for every node, so there have been at least metavotes for .
On the other hand, by definition of an observer, every node voted for more than nodes  so there have been more than metavotes for , which leaves less than metavotes for (there are metavotes in total: nodes metavote in metaelections).
This is a contradiction, which proves the lemma. ∎
Theorem 4.20 (Byzantine Consensus).
The algorithm for calculating the next block presented in this paper satisfies the general properties of a Byzantine fault tolerant consensus algorithm:

Validity  if a correct node decides on a next block, its payload was in at least one interesting event created by a correct node.

Agreement  if a correct node decides on a next block, all correct nodes decide on that block.

Integrity  once a correct node decides on a next block, it never decides on another block.

Termination  all correct nodes eventually decide with probability 1.
Validity.
Assume that no correct node created an interesting event with payload , but was still decided as the payload of the next block.
This means that only faulty nodes could create interesting events with payload , so there is less than such interesting events. Furthermore, if a correct node created a descendant of such an interesting event, then either it or one of its selfancestors would have to be an interesting event with payload as well. This would contradict our assumption, so no correct node could have created a descendant of an interesting event with payload .
It follows from this that when correct nodes create observers, no such observer can metavote true for a creator of an interesting event with payload (as it would require the observer to be a descendant of such an event). This means that after the metaelection is complete, no interesting event with payload will be taken into consideration, so will not be decided as the payload of the next stable block.
QED by contradiction. ∎
Agreement.
Assume that a correct node decided the next block . Since a decision has been reached, this means that there is consensus about the metavotes, so every correct node will have chosen the same nodes’ interesting events.
For any observer to metavote on a node, it must have strongly seen an interesting event by that node. By Lemma 4.10, even if that node created a fork, if any other observers also voted on that node, they must have strongly seen interesting events on the same fork. Thus, we can consider interesting events by all elected nodes to form linear histories  which will be seen the same way by all nodes by Lemma 4.9.
In a linear history, the earliest interesting event is welldefined. Also, because all correct nodes see the same history, they will all choose the same interesting event as the earliest. If the interesting events has multiple payloads, all correct nodes will use the same tiebreaker algorithm and choose the same single one. Thus, all correct nodes will gather the same set of votes, and because they use the same voting rules, decide the same block as the next one. ∎
Integrity.
By construction of the algorithm, once the next block has been decided, it is appended to the ordered set and no other block can be decided in its place. ∎
Termination.
The consensus algorithm starts when a correct node creates an interesting event. Once that happens, by lemma 4.11, all correct nodes will eventually create interesting events, and this in turn implies that all of them will create observers. Once there is a supermajority of observers, we start the binary agreement algorithm, which will terminate by Theorem 4.17. After binary agreement terminates, because the set of voters for the next block is nonempty (by Lemma 4.19), the next block is already determined  so the agreement about the next block also terminates. ∎
5 Conclusions
A new consensus algorithm has been presented, building upon some previous achievements in this field (baird2016swirlds , aba ), but combining their features in a novel way. It works under asynchronous conditions, uses a gossip graph (like gkagol2018aleph , baird2016swirlds and rocket2018snowflake ), and a common coin. It is also leaderless (barring the very initialisation of the network, when a trusted dealer may be required) and an open source implementation is provided. We believe this approach will be useful in numerous applications, one of which is the SAFE Network.
Appendix A : Extending the algorithm to a network with dynamic membership
The main algorithm is formulated in terms of a network in which all the members are known a priori (a static network). This is enough in some settings, but sometimes it is necessary to allow the set of members to be modified, so that members of the network can join and leave at will.
In order to accommodate dynamic membership in the network, every node has to keep a record of who the current members are. We will call this record the network members list. This list is initialised with the so called genesis group and can only be modified as a result of a block becoming stable.
Changing the membership list requires regenerating the common coin secret key shares, too. We need to generate them in a way that doesn’t allow any single node to get to know more than just their share. Fortunately, there are distributed key generation (DKG) algorithms in existence that solve this problem. One of the simplest ones is dkg , but it requires synchronous communications.
Fortunately, we can simulate synchronous communications using the instances of PARSEC held by the old set of members. DKG messages can be input as votes into the graph, and the consensus algorithm will ensure that all nodes will process them in the same order. The messages in the order that was agreed upon can also be passed to the nodes that are joining, thus allowing them to generate their key shares.
In summary, a membership change would be processed as follows:

The old set of members votes for a membership change (adding or removing a node).

A block with node addition/removal becomes stable.

Nodes from the old members set start the DKG algorithm and begin voting for DKG messages.

Blocks with DKG messages become stable. At some point, enough of them are stable to complete the DKG algorithm.

Nodes from the old set calculate their new key shares and update their members lists.

If a new node was joining, it will start receiving gossip containing the gossip events since genesis up to this point. By processing the graph, it can learn of all the blocks that became stable, including the DKG messages, from which it will be able to derive its own key share. It will also arrive at the current members list.

The membership change is complete.
This method ensures that every metaelection uses a constant list of members from start to finish  the members list only gets modified once a metaelection finishes (the one regarding the block that completed the DKG), and another one is not yet started. Thanks to this approach, the proofs of correctness apply without modifications.
References
 [1] Fackler A. Distributed Key Generation. https://github.com/poanetwork/hbbft/issues/47#issuecomment394422248.
 [2] Miller A. Optimistic Randomness for ABA. https://github.com/amiller/HoneyBadgerBFT/issues/63.
 [3] Bowen Alpern and Fred B Schneider. Defining liveness. 21(4):181–185.
 [4] Krzysztof R Apt, Eryk Kopczynski, and Dominik Wojtczak. On the computational complexity of gossip protocols. In IJCAI, pages 765–771.
 [5] Leemon Baird. The swirlds hashgraph consensus algorithm: Fair, fast, byzantine fault tolerance.
 [6] Ken Birman. The promise, and limitations, of gossip protocols. 41(5):8–13.
 [7] Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the weil pairing. 17(4):297–319.

[8]
Elizabeth Borowsky and Eli Gafni.
Generalized flp impossibility result for tresilient asynchronous
computations.
In
Proceedings of the twentyfifth annual ACM symposium on Theory of computing
, pages 91–100. ACM.  [9] Laurent Chuat, Pawel Szalachowski, Adrian Perrig, Ben Laurie, and Eran Messeri. Efficient gossip protocols for verifying the consistency of certificate logs. In 2015 IEEE Conference on Communications and Network Security (CNS), pages 415–423. IEEE.
 [10] Michael J Fischer, Nancy A Lynch, and Michael S Paterson. Impossibility of distributed consensus with one faulty process.
 [11] Rachid Guerraoui, Kévin Huguenin, AnneMarie Kermarrec, Maxime Monod, and Swagatika Prusty. Lifting: lightweight freeridertracking in gossip. In Proceedings of the ACM/IFIP/USENIX 11th International Conference on Middleware, pages 313–333. SpringerVerlag.
 [12] Adam Gągol and Michał Świętek. Aleph: A leaderless, asynchronous, byzantine fault tolerant consensus protocol.
 [13] MaidSafe. PARSEC reference implementation (WIP). https://github.com/maidsafe/parsec.
 [14] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The honey badger of bft protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 31–42. ACM.
 [15] Achour Mostefaoui, Hamouma Moumen, and Michel Raynal. Signaturefree asynchronous byzantine consensus with t< n/3 and o (n 2) messages. In Proceedings of the 2014 ACM symposium on Principles of distributed computing, pages 2–9. ACM.
 [16] A Penland, David Shrier, T Hardjono, and I WladawskyBerger. Towards an internet of trusted data: A new framework for identity and data sharing.
 [17] Team Rocket. Snowflake to avalanche: A novel metastable consensus protocol family for cryptocurrencies.
 [18] Micali S. Byzantine Agreement, Made Trivial.