Consensus is hard to achieve in open networks such as partial synchronous networks or complete asynchronous networks. Several practical protocols such as Paxos  and Raft  have been designed to tolerate non-Byzantine faults. For example, Google, Microsoft, IBM, and Amazon have used Paxos in their storage or cluster management systems. Lamport, Shostak, and Pease  and Pease, Shostak, and Lamport  initiated the study of reaching consensus in face of Byzantine failures and designed the first synchronous solution for Byzantine agreement. For asynchronous networks, Fischer, Lynch, and Paterson  showed that there is no deterministic protocol for the BFT problem in face of a single failure. Several researchers have tried to design BFT consensus protocols to circumvent the impossibility. The first category of efforts is to use a probabilistic approach to design BFT consensus protocols in completely asynchronous networks. This kind of work was initiated by Ben-Or  and Rabin  and extended by others such as Cachin, Kursawe, and Shoup . It should be noted that though probabilistic approach was used to design BFT protocols in asynchronous networks, some researchers used probabilistic approach to design BFT protocols for complete synchronous networks also. For example, the probabilistic approach based BFT protocols [7, 12] employed in ALGORAND blockchain  assumes a synchronous and complete point-to-point network. The second category of efforts was to design BFT consensus protocols in partial synchronous networks which was initiated by Dwork, Lynch, and Stockmeyer .
Ethereum foundation has tried to design a BFT finality gadget for their Proof of Stake (PoS) based Ethereum 2.0 blockchain. It has been shown in Wang  that their currently deployed Casper Friendly Finality Gadget (Casper FFG)  for Ethereum 2.0 beacon network does not achieve liveness property in partially synchronous networks. Ethereum foundation has been advocating the “Correct-by-Construction” (CBC) family of Casper blockchain consensus protocols [18, 19] for their future release of Ethereum 2.0 blockchain. The CBC Casper the Friendly Ghost emphasizes the safety property. But it does not try to address the liveness requirement for the consensus process. Indeed, it explicitly says that  “liveness considerations are considered largely out of scope, and should be treated in future work”. Thus in order for CBC Casper to be deployable, a lot of work needs to be done since the Byzantine Agreement Problem becomes challenging only when both safety and liveness properties are required to be satisfied at the same time. It is simple to design BFT protocols that only satisfy one of the two requirements (safety or liveness). The Ethereum foundation community has made several efforts to design safety oracles for CBC Casper to help participants to make a decision when an agreement is reached (see, e.g., ). However, this problem is at least as hard as coNP-complete problems. So no satisfactory solution has been proposed yet.
CBC Casper has received several critiques from the community. For example, Ali et al  concluded that “the definitions and proofs provided in  result in neither a theoretically sound nor practically useful treatment of Byzantine fault-tolerance. We believe that considering correctness without liveness is a fundamentally wrong approach. Importantly, it remains unclear if the definition of the Casper protocol family provides any meaningful safety guarantees for blockchains”. Though CBC Casper is not a deployable solution yet and it has several fundamental issues yet to be addressed, we think these critiques as in  may not be fair enough. Indeed, CBC Casper provides an interesting framework for consensus protocol design. In particular, the algebraic approach proposed by CBC Casper has certain advantages for describing Byzantine Fault Tolerance (BFT) protocols. The analysis in this paper shows that the current formulation of CBC Casper could not achieve liveness property. However, if one revises the CBC Casper’s algebraic approach to include the concept of “waiting” and to enhance participant’s capability to identify more malicious activities (that is, to consider general malicious activities in addition to equivocating activities), then one can design efficiently constructive liveness concepts for CBC Casper even in complete asynchronous networks.
As we have mentioned in the preceding paragraphs, Fischer, Lynch, and Paterson  showed that there does not exist a deterministic BFT protocol against a single failure in complete asynchronous networks. All existing BFT protocols for asynchronous networks in the literature are non-deterministic and are based on participant’s autonomous coin-flipping or participants’ shared common coin-flipping. In this paper, we show that it is possible to design an efficient deterministic leaderless BFT protocol XP for the blockchain applications. The protocol XP circumvents Fischer, Lynch, and Paterson’s impossibility results by leveraging certain special properties for blockchain applications. This kind of blockchain properties do not hold for general BFT application scenarios considered by Fischer, Lynch, and Paterson.
The structure of the paper is as follows. Section 3 provides a brief review of the CBC Casper framework. The author of  mentioned in several talks that CBC Casper does not guarantee liveness in asynchronous networks. Section 4 presents a protocol which shows that revised CBC Casper can indeed provide liveness property in asynchronous networks. Section 5 presents an efficient deterministic BFT protocol XP as a finality gadget for blockchains in complete asynchronous networks.
2 System model and Byzantine agreement
In this section, we describe our basic system model. For the Byzantine general problem, there are participants and an adversary that is allowed to corrupt up to of them. The adversary model is a static one wherein the adversary must decide whom to corrupt at the start of the protocol execution. For the network setting, we assume a complete asynchronous network of Fischer, Lynch, and Paterson . That is, we make no assumptions about the relative speeds of processes or about the delay time in delivering a message. We also assume that processes do not have access to synchronized clocks, so algorithms based on time-outs cannot be used. We also assume that the adversary has complete control of the network: he may schedule/reorder the delivery of messages as he wishes, and may drop or insert messages as he wishes. However, we assume that all messages are eventually delivered if the sender makes infinitely many trials to send the messages. The honest participants are completely passive: they simply follow the protocol steps and maintain their internal state between protocol steps.
The computations made by the honest participants and the adversary are modeled as polynomial-time computations. We assume that public key cryptography is used for message authentications. In particular, each participant should have authentic public keys of all other participants. This means that if two participants and are honest and receives a message from over the network, then this message must have been generated by at some prior point in time. A Byzantine agreement protocol must satisfy the following properties:
Safety: If an honest participant decides on a value, then all other honest participants decides on the same value. That is, it is computationally infeasible for an adversary to make two honest participants to decide on different values.
Liveness (termination): There exists a function such that all honest participants should decide on a value after the protocol runs at most steps. It should be noted that could be exponential in . In this case, we should further assume that is significantly smaller than where is the security parameter for the underlying authentication scheme. In other words, one should not be able to break the underlying authentication scheme within steps.
Non-triviality (Validity): If all honest participants start the protocol with the same initial value, then all honest participants that decide must decide on this value.
3 CBC Casper the Friendly Binary Consensus (FBC)
CBC Casper has binary version and integer version. In this paper, we only consider Casper the Friendly Binary Consensus (FBC). Our discussion can be easily extended to general cases. For the Casper FBC protocol, each participant repeatedly sends and receives messages to/from other participants. Based on the received messages, a participant can infer whether a consensus has been achieved. Assume that there are participants and let be the Byzantine-fault-tolerance threshold. The protocol proceeds from step to step (starting from step ) until a consensus is reached. Specifically the step proceeds as follows:
Let be the collection of valid messages that has received from all participants (including himself) from steps . determines whether a consensus has been achieved. If a consensus has not been achieved yet, sends the message
to all participants where is
’s estimated consensus value based on the received message set.
In the following, we describe how a participant determines whether a consensus has been achieved and how a participant calculates the value from .
For a message , let . For two messages , we write if depends on . That is, there is a sequence of messages such that
For a message and a message set , we say that if or for some . The latest message by a participant in a message set is a message satisfying the following condition:
There does not exist another message sent by participant with .
It should be noted that the “latest message” concept is well defined for a participant if has not equivocated, where a participant equivocates if has sent two messages with the properties that “ and ”.
For a binary value and a message set , the score of a binary estimate for is defined as the number of non-equivocating participants whose latest message voted for . That is,
To estimate consensus value: Now we are ready to define ’s estimated consensus value based on the received message set as follows:
To infer consensus achievement: For a protocol execution, it is required that for all , the number of equivocating participants in is at most . A participant determines that a consensus has been achieved at step with the received message set if there exists such that
4 Liveness of Revised CBC Casper FBC
From CBC Casper protocol description, it is clear that CBC Casper is guaranteed to be correct against equivocating participants. However, the “inference rule for consensus achievement” requires a mathematical proof that is based on infinitely many message sets for . This requires each participant to verify that for each potential set of Byzantine participants, their malicious activities will not overturn the inequality in (4). This problem is at least co-NP hard. Thus even if the system reaches a consensus, the participants may not realize this fact. In order to address this challenge, Ethereum community provides three “safety oracles” (see ) to help participants to determine whether a consensus is obtained. The first “adversary oracle” simulates some protocol execution to see whether the current estimate will change under some Byzantine attacks. As mentioned previously, this kind of problem is co-NP hard and the simulation cannot be exhaustive generally. The second “clique oracle” searches for the biggest clique of participant graph to see whether there exist more than 50% participants who agree on current estimate and all acknowledge the agreement. That is, for each message, the oracle checks to see if, and for how long, participants have seen each other agreeing on the value of that message. This kind of problem is equivalent to the complete bipartite graph problem which is NP-complete. The third “Turan oracle” uses Turan’s Theorem to find the minimum size of a clique that must exist in the participant edge graph. In a summary, currently there is no satisfactory approach for CBC Casper participants to determine whether finality has achieved. Thus no liveness is guaranteed for CBC Casper. Indeed, we can show that it is impossible to achieve liveness in CBC Casper.
4.1 Impossibility of achieving liveness in CBC Casper
In this section, we use a simple example to show that without a protocol revision, no liveness could be achieved in CBC Casper. Assume that there are participants. Among these participants, of them are malicious and never vote. Furthermore, assume that of them hold value and of them hold value . Since the message delivery system is controlled by the adversary, the adversary can let the first participants to receive voted and voted . On the other hand, the adversary can let the next participants to receive voted 1 and voted . That is, at the end of this step, we still have that of them hold value and of them hold value . This process can continue forever and never stop.
In CBC Casper FBC [18, 19], a participant is identified as malicious only if he equivocates. This is not sufficient to guarantee liveness (or even safety) of the protocol. For example, if no participant equivocates and no participant follows the equation (3) for consensus value estimation, then the protocol may never make a decision (that is, the protocol cannot achieve liveness property). However, the protocol execution satisfies the valid protocol execution condition of [18, 19] since there is zero equivocating participant.
4.2 Revising CBC Casper FBC
CBC Casper does not have an in-protocol fault tolerance threshold and does not have any timing assumptions. Thus the protocol works well in complete asynchronous settings. Furthermore, it does not specify when a participant should broadcast his step protocol message to other participants. That is, it does not specify when should stop waiting for more messages to be included . We believe that CBC Casper authors do not specify the time for a participant to send its step protocol messages because they try to avoid any timing assumptions. In fact, there is a simple algebraic approach to specify this without timing assumptions. First, we revise the message set as the collection of messages that receives from all participants (including himself) during step . That is, the message set is a subset of where is defined recursively as follows:
Then we need to revise the latest message definition accordingly:
As we have mentioned in the preceding section, CBC Casper FBC [18, 19] only considers equivocating as malicious activities. This is not sufficient to guarantee protocol liveness against Byzantine faults. In our following revised CBC Casper model, we consider any participant that does not follow the protocol as malicious and exclude their messages:
For a message set , let be the set of identified malicious participants from . Specifically, let
where is the set of equivocating participants within and is the set of participants that does not follow the protocols within . For example, includes participants that do not follow the consensus value estimation process properly or do not wait for enough messages before posting his own protocol messages.
With the definition of , we should also redefine the score function (2) by revising the definition of accordingly:
4.3 Secure BFT protocol in the revised CBC Casper
With the revised CBC Casper, we are ready to introduce the “waiting” concept and specify when a participant should send his step protocol message:
A participant should wait for at least valid messages from other participants before he can broadcast his step message . That is, should wait until to broadcast his step protocol message.
In case that a participant receives valid messages from other participants (that is, he is ready to send step protocol message) before he could post his step message, he should wait until he finishes sending his step message.
After a participant posts his step protocol message, it should discard all messages from steps or early except decision messages that we will describe later.
It is clear that these specifications does not have any restriction on the timings. Thus the protocol works in complete asynchronous networks.
In Ben-Or’s BFT protocol , if consensus is not achieved yet, the participants autonomously toss a coin until more than participant outcomes coincide. For Ben-Or’s maximal Byzantine fault tolerance threshold , it takes exponential steps of coin-flipping to converge. It is noted that, for , Ben-Or’s protocol takes constant rounds to converge. Bracha  improved Ben-Or’s protocol to defeat Byzantine faults. Bracha first designed a reliable broadcast protocol with the following properties (Bracha’s reliable broadcast protocol is briefly reviewed in the Appendix): If an honest participant broadcasts a message, then all honest participants will receive the same message in the end. If a dishonest participants broadcasts a message, then either all honest participants accept the identical message or no honest participant accepts any value from . By using the reliable broadcast primitive and other validation primitives, Byzantine participants are transformed to fail-stop participants in Bracha . In this section, we assume that a reliable broadcast primitive such as the one by Bracha’s is used in our protocol execution. In the following, we adapt Bracha’s BFT protocol to the CBC Casper framework. At the start of the protocol, each participant holds an initial value in his variable . The protocol proceeds from step to step. The step consists of the following sub-steps.
Each participant reliably broadcasts to all participants where is the message set that has received during step . Then waits until it receives valid messages in and computes the estimate using the value estimation function (3).
Each participant reliably broadcasts to all participants and waits until it receives valid messages in . If there is a such that , then let otherwise, let .
Each participant reliably broadcasts to all participants and waits until it receives valid messages in . distinguishes the following three cases:
If for some , then decides on and broadcasts his decision together with justification to all participants.
If for some , then lets and moves to step .
Otherwise, flips a coin and let to be coin-flip outcome. moves to step .
Assume that . The security of the above protocol can be proved be establishing a sequence of lemmas.
If all honest participants hold the same initial value at the start of the protocol, then every participant decides on at the end of step .
Proof. At sub-step 1, each honest participant receives at least value among the received values. Thus all honest participants broadcast at sub-step 2. If a malicious participant broadcasts during sub-step 2, then it cannot be justified since could not receive messages for during sub-step 1. Thus will be included in . That is, each honest participant receives messages for at the end of sub-step 2 and broadcasts during sub-step 3. Based on the same argument, all honest participants decide on at the end of sub-step 3.
If an honest participant decides on a value at the end of step , then all honest participants either decide on at the end of step or at the end of step .
Proof. If an honest participant decides on a value at the end of sub-step 3, then receives valid messages for the value . Since the underlying broadcast protocol is reliable, each honest participant receives at least these valid messages for the value . Thus if a participant does not decide on the value at the end of sub-step 3, it would set . That is, all honest participants will decide during step .
The above two Lemmas show that the protocol is a secure Byzantine Fault Tolerance protocol against Byzantine faults in complete asynchronous networks. The above BFT protocol may take exponentially many steps to converge. However, if a common coin such as the one in Rabin  is used, then the above protocol converges in constant steps. It should be noted that Ethereum 2.0 provides a random beacon which could be used as the common coin for the above BFT protocol. Thus the above BFT protocol could be implemented with constant steps on Ethereum 2.0.
5 Deterministic leaderless BFT protocol in asynchronous networks
BFT consensus protocols could be used differently for various blockchains. For many Proof of Stake (PoS) based blockchains, BFT consensus protocol is used as a finality gadget. That is, there is an underlying block production mechanism. BFT protocol is used to finalize these blocks. For this kind of applications, one may design deterministic BFT protocols in complete asynchronous networks. It is noted that after Fisher, Lynch, and Paterson (FLP) proved that there is no deterministic protocols in complete asynchronous networks, several probabilistic BFT protocols (e.g., Rabin’s BFT and Ben-Or’s BFT) have been designed. Non-deterministic BFT protocols are not practical since they generally require exponentially many steps if autonomous coin-flips are used. Even with a shared common coin implementation, non-deterministic BFT protocols are not yet efficient due to the complexity of common coin implementation. On the other hand, BFT protocols for partially synchronous networks generally require round leaders to coordinate the protocol process. When round leader’s identity is revealed (this is normally true), a malicious adversary could easily launch a Denial of Service attack against the round leader to prevent the protocol from proceeding. Thus it is preferred to design efficient leaderless BFT protocols in partial synchronous or complete asynchronous networks. As we have mentioned, there does not exist a deterministic BFT protocol in complete asynchronous networks and existing non-deterministic leaderless BFT protocols are not efficient. It seems to be an impossible task to design an efficient leaderless BFT protocol. Fortunately for blockchain applications, we can leverage blockchain properties to design efficient deterministic leaderless BFT finality gadget for blockchains. Our result does not contradict with Fisher, Lynch, and Paterson’s (FLP) impossibility results due to the following reasons: in FLP’s scenario with , if at least participants hold the same value at the start of the protocol and all of these participants are honest, then all honest participants should decide on this value at the end of the protocol (some other honest participant may hold a different value at the start of the protocol though). However, for a blockchain scenario with , if participants hold the same value at the start of the protocol and one participant holds a different value at the start of the protocol, we may still prefer that all honest participants decide on ’s value at the end of the protocol if ’s block is the best candidate. In other words, even if the best candidate block is held only by the adversary at the start of the protocol, the protocol may still decide on this best candidate block.
5.1 A toy example of PoS blockchain
We use a toy example for PoS blockchain to illustrate the application scenario. The initial status of the block chain is
where are a list of initial users and are their respective initial amounts of money units. We assume that each user is identified by its public key . That is, for the users , their corresponding public keys are . In practical implementations, a user may be identified by the hash of her public key. That is, we may use in implementations. A valid transaction from a user to a user is in the format of
where the user currently has money units, is an existing or a newly created user, and is the public key of user . The impact of this transaction is that the amount of money units for user is decreased by and the amount of money units for user is increased by .
In an idealized magic ledger system, all transactions are valid and the list of sets of transactions are posted in a tamper-proof box in the sky which is visible to all participants
A Proof of Stake (PoS) blockchain is organized in a series of heights . Similar to the initial status, the system status for height is a list of users and their corresponding money units
In a height , the system status transitions from to via the transaction set
A PoS blockchain is a list of blocks where each consists of the following fields: the block number itself, the time-stamp that the block is generated, the set of transactions for height , the hash of the previous block , the user who generates this block, and a set of signatures certifying that the block is constructed appropriately
The field is a valid list of signatures for the value from qualified verifier committee for height . From this chain, one can deduce the user sets and their corresponding money units of each height.
In a PoS blockchain, the block proposer for the height obtains certain benefits (e.g., may be awarded with certain amount of cryptographic currency or obtain the transaction fees). A commonly employed technique is to use a probabilistic approach to determine the block proposer . For example, for each user who has stakes in the system, one can calculate a random number using a commonly agreed function where could be the random number committed by and could be a shared random beacon for the height of the blockchain. Then user is the proposer for the height of the blockchain if
To avoid potential attacks, the random number is kept secret until the proposer publishes her proposed candidate block . The challenging problem is: how can a participant determines that her value is the smallest without learning the values for other participants ? In practice, the system has a pre-agreed constant for each block height . Each participant with her value proposes a candidate block After all potential proposers for height publish their candidate blocks , an independent verifier committee carries out a BFT protocol to decide the finalized block for height from these candidate blocks. For the convenience of protocol design, we order these candidate blocks using potential proposer’s value . That is, let if one of the following conditions holds
and for a fixed hash function .
It should be noted that a potential proposer should not propose two different candidate blocks. Otherwise, all of candidate blocks proposed by this potential leader is considered as invalid. That is, a candidate block is invalid if there exists such that both blocks and are proposed by a same proposer. Assume that all valid candidate blocks for the height are ordered as
The verifier committee, consisting of participants , needs to select one of these candidate blocks as the finalized block for height . Due to network latency (e.g., network asynchrony) or other challenges, a participant may only receive a subset of these candidate blocks. If a BFT participant identifies a candidate block as invalid, it will remove it from its local list and include the proof (that this block is invalid) in all his future messages. Each participant prefers the “largest” valid block that he is aware of to be finalized (though the finalized block may be different from the largest one).
5.2 Deterministic blockchain BFT protocols for asynchronous networks
As we have mentioned in the beginning of this section, all existing leaderless BFT protocols in asynchronous networks are non-deterministic and use coin-flipping (either a shared common coin or autonomous coins) to reach agreement. By the FLP theorem, it is impossible to design deterministic (without coin-flipping) BFT protocols in asynchronous networks. However, the BFT finality gadget for blockchain has slightly different requirement. Assume that the candidate blocks for height are ordered as: The verifier committee consists of participants where . As a special illustrative case, assume that participants are only aware of the candidate block and the participant is aware of the candidate block . This could happen due to network asynchrony where the candidate block only reached the participant . For the traditional BFT protocol, the verifier committee should finalize the candidate block as the finalized block. However, for blockchain finality gadget, it is acceptable for the verifier committee to finalize the candidate block as the finalized block. Since there is a total order on valid candidate blocks and it is preferred to finalize the largest valid candidate block as the finalized block, one can circumvent FLP’s impossibility result and design efficient deterministic (no coin-flipping) leaderless BFT protocols in complete asynchronous networks.
In the following, we present a leaderless deterministic BFT protocol XP for complete asynchronous networks. In the BFT protocol XP, when a participant cannot make a decision during one step, he sets his local variable to the largest candidate block that he is aware of. This is contrast to the approaches in probabilistic BFT protocols wherein a participant flips a coin when a decision is not made. The protocol XP tolerates Byzantine participants. Our protocol is motivated by the probabilistic BFT protocol in Cachin, Kursawe, and Shoup  (CKS). Specifically, we employ the message “justification” approach in CKS. It should be noted that the message justification approach is similar to Ethereum’s CBC approach where message history is included in each message for “justification” purpose. In our following protocol, we do not assume that there is a reliable broadcast protocol (compare the BFT protocol in Section 4.3 where a reliable broadcast primitive is required). Since broadcast may not be reliable, a malicious participant may send different messages to different participants. Message justification is used to attack these challenges due to unreliable broadcast channel. At the start of the protocol, each participant holds one or zero candidate block in its local variable . Then protocol proceeds from step to step. The step for a participant consists of the following sub-steps:
lock: If , then let . Otherwise, if , select valid commit-votes from step and let
Then sends the following message to all participants.
where justification consists of a list of messages to show that his selection of the value is justified.
commit: collects valid and justified step- messages (7). If there is any candidate block from these lock messages such that , then lets . Furthermore, lets
Then sends the following message to all participants
where justification consists of a list of messages to show that his selection of the value is justified.
check-for-decision: Collect properly justified commit votes (9) of step . If there is any commit vote with , then lets . Furthermore, if these are commit-votes for a block , then decides the block and continues for one more step (up to sub-step). Otherwise, simply proceed.
Assume that . The security of the above protocol can be proved be establishing a sequence of lemmas.
If all honest participants hold the largest block at the start of the protocol, then every participant decides on this value at the end of step .
Proof. This is straightforward.
If an honest participant decides on the value at the end of step , then all honest participants either decide on at the end of step or at the end of step .
Proof. If an honest participant decides on the value at the end of step , then at least honest participants commit-vote for . Thus each participant (including malicious participant) receives at least one commit-vote for at the end of step . This means that a malicious participant cannot create a justification that she has received a commit-vote for another block or has received commit-votes for during step . In other words, if a malicious participant broadcasts a lock message for a block during step , it cannot be justified and will be discarded by honest participants. That is, all honest participants will commit-vote for the block during step and any commit-vote for other blocks by malicious participants cannot be justified. That is, all honest participants will receive justified commit-vote for the block and will decide on block at the end of step .
The value in equation (6) is well defined.
Proof. It is sufficient to show that each participant (including both honest and dishonest participants) can not receive commit-votes for two different blocks and during step . For a contradiction, assume that receives commit-vote for both and during step . Then there are participants submit lock messages for and participants submit lock messages for . This means that at least one honest participant submits lock messages for both and which is impossible.
All honest participant decides in constant steps.
Proof. If no participant decides at step , then there must exist an honest participant that revises its local variable to a new candidate block which is larger than its previous candidate block. Since there are at most candidate blocks, this process continues until no honest participant revises its local variable . Then all honest participants hold the same candidate block and the consensus will be reached.
The above four Lemmas show that the protocol XP is a secure Byzantine Fault Tolerance protocol against Byzantine faults in complete asynchronous networks. Assuming that at least one honest participant holds the largest candidate block, then the protocol XP converges in at most two steps in a complete synchronous network. Thus it is more efficient compared against other non-deterministic BFT protocols (for complete asynchronous networks) and deterministic leader-based BFT protocols (for partial synchronous networks).
-  M. Ali, J. Nelson, and A. Blankstein. Peer review: CBC Casper. available at: https://medium.com/@muneeb/peer-review-cbc-casper-30840a98c89a, December 6, 2018.
-  M. Ben-Or. Another advantage of free choice: Completely asynchronous agreement protocols (extended abstract). In Proc. 2nd ACM PODC, pages 27–30, 1983.
-  G. Bracha. An asynchronous -resilient consensus protocol. In Proc. 3rd ACM PODC, pages 154–162. ACM, 1984.
-  V. Buterin and V. Griffith. Casper the friendly finality gadget. arXiv preprint arXiv:1710.09437v4, 2019.
-  C. Cachin, K. Kursawe, and V. Shoup. Random oracles in constantinople: Practical asynchronous byzantine agreement using cryptography. Journal of Cryptology, 18(3):219–246, 2005.
-  C. Dwork, N. Lynch, and L. Stockmeyer. Consensus in the presence of partial synchrony. JACM, 35(2):288–323, 1988.
-  P. Feldman and S. Micali. An optimal probabilistic protocol for synchronous byzantine agreement. SIAM Journal on Computing, 26(4):873–933, 1997.
-  M.J. Fischer, N. A Lynch, and M.S. Paterson. Impossibility of distributed consensus with one faulty process. JACM, 32(2):374–382, 1985.
-  Y. Gilad, R. Hemo, S. Micali, G. Vlachos, and N. Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proc. the 26th Symposium on Operating Systems Principles, pages 51–68. ACM, 2017.
-  L. Lamport. The part-time parliament. ACM Transactions on Computer Systems (TOCS), 16(2):133–169, 1998.
-  L. Lamport, R. Shostak, and M. Pease. The Byzantine generals problem. ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982.
-  Silvio Micali. Byzantine agreement, made trivial, 2016.
-  D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference, pages 305–319, 2014.
-  M. Pease, R. Shostak, and L. Lamport. Reaching agreement in the presence of faults. JACM, 27(2):228–234, 1980.
-  M.O. Rabin. Randomized byzantine generals. In 24th IEEE FOCS, pages 403–409. IEEE, 1983.
-  Ethereum Research. CBC Casper FAQ. available at: https://github.com/ethereum/cbc-casper/wiki/FAQ, November 27, 2018.
-  Yongge Wang. Byzantine fault tolerance in partially connected asynchronous networks. http://eprint.iacr.org/2019/1460, 2019.
-  V. Zamfir. Casper the friendly ghost: A correct by construction blockchain consensus protocol. Whitepaper: https://github.com/ethereum/research/tree/master/papers, 2017.
-  V. Zamfir, N. Rush, A. Asgaonkar, and G. Piliouras. Introducing the minimal cbc casper family of consensus protocols. DRAFT v1.0: https://github.com/cbc-casper/, 2018.
Appendix A Bracha’s broadcast primitive
Assume . Bracha  designed a broadcast protocol for asynchronous networks with the following properties:
If an honest participant broadcasts a message, then all honest participants accept the message.
If a dishonest participant broadcasts a message, then either all honest participants accept the same message or no honest participant accepts any value from .
Bracha’s broadcast primitive runs as follows:
The transmitter sends the value to all participants.
If a participant receives a value with one of the following messages
messages of the type
message of the type
then sends the message to all participants.
If a participant receives a value with one of the following messages
messages of the type
message of the type
then sends the message to all participants.
If a participant receives messages of the type , then accepts the message from .
Assume that . The intuition for the security of Bracha’s broadcast primitive is as follows. First, if an honest participant sends the value , then all honest participant will receive this message and echo the message . Then all honest participants send the ready message for and all honest participants accept the message .
Secondly, if honest participants and send ready messages for and respectively, then we must have . This is due to the following fact. A participant sends a message only if it receives ready messages or echo messages. That is, there must be an honest participant who received echo messages for . Since an honest participant can only send one message of each type, this means that all honest participants will only sends ready message for the value .
In order for an honest participant to accept a message , it must receive ready messages. Among these messages, at least ready messages are from honest participants. An honest participant can only send one message of each type. Thus if honest participants and accept messages and respectively, then we must have . Furthermore, if a participant accepts a message , we just showed that at least honest participants have sent the ready message for . In other words, all honest participants will receive and send at least ready message for . By the argument from the preceding paragraph, each honest participant sends one ready message for . That is, all honest participants will accept the message .