Many thanks to Barnabé, Luca, Dankrad, and Francesco for spinning out some thoughts, and especially Luca for pointing me toward an important paper and Dankrad for his help with HoneyBadger.
I. THE THINKING BEHIND THIS PROJECT & A DISCUSSION OF “LEADERLESS”
A. Leader-Led versus Leaderless Consensus Protocols
B. Considerations for Being “Leaderless”
II. FINDINGS — MILESTONES
A. Milestone I
B. Algorithmic Commonalities
1. Example (1): Signature-Free Asynchronous Binary Byzantine Consensus with t < n/3, O(n²) Messages, and O(1) Expected Time
2. Example (2): The Honey Badger of BFTs
B. Principles / Building Blocks for Leaderless Consensus Protocols
1. Reliable Broadcast
2. Binary Byzantine Agreement
3. Common Coin as the Tie-Breaker
4. “Forced” Inclusion of “Mini-blocks” or Mini Transaction Sets (Multi/Unanimous proposals)
D. Attributes Analysis
E. Milestone II — Implementations and Practical Considerations
III. WHAT’S NEXT
A. Motivations for Ethereum
IV. LITERATURE
I. THE THINKING BEHIND THIS PROJECT & A DISCUSSION OF “LEADERLESS”
When I first started on this journey of discovery — or more precisely, a re-discovery — of the first principles behind decentralised network consensus protocols, there were two types of motivation. The first kind came in the form of a naïve line of questioning on how best to approach blockchain architecture and design. This would be, for example, how we make the system ever more democratic and accessible to as many people, running as low a hardware requirement, as possible; a kind of thinking representative of the ideological reasons many of us entered the blockchain industry in the first place. There has always been this genuine belief that blockchain would bring openness, transparency, and privacy all at the same time revolutionising the tech industry; that blockchain itself was a fusion of these qualities, melded together to form a new paradigm in tech that would continue to further such values through its own development. The second kind of motivation stemmed out of pure curiosity about whether or not leader-led consensus protocols had become the industry standard because of some network effect that originated its popularity; or was it simple truth that leaderless consensus mechanisms could not meaningfully compete performance-wise.
Aside from these personal interests, in 2024 we have also seen a rise in public interest by blockchain researchers in leaderless algorithms as well. Paradigm released a leaderless auction proposal, Sreeram from Eigenlayer co-wrote a paper for BigDipper which featured a kind of multi-proposer schema, and Max Resnick ex-SMG gave thought to BRAID — a potential multi-chain (a sort of multi-proposer) architecture for Ethereum.
A study on leaderless consensus protocols now is more relevant than ever; but before discussing proposed responses to these prompts, let’s clarify what is meant by a “truly leaderless consensus protocol”.
A. Leader-Led versus Leaderless Consensus Protocols
Although leader-led and leaderless consensus protocols exist on the same spectrum at their respective opposite ends, it is much easier to define leader-led than leaderless. A leader-led algorithm refers to a protocol where a central organiser shepherds protocol progress, such as coordinating the rounds of communication or being a round’s decision-maker. In most classic leader-led consensus protocols, a leader typically means some sort of assigned, elected, or otherwise pre-selected single process (e.g. node participant, replica) that collects messages from other processes or makes a proposal for the whole protocol (usually only for one round and this does not prevent it from being leader again).
Leader-led BFTs are efficient in the following two ways: (1) the leader acts as a centralised coordinator in collecting protocol messages (all-to-one) versus the worst-case scenario (all-to-all) thus significantly reducing communication complexity; (2) a single process making a valid proposal is more efficient than multiple processes offering many proposals since it removes rounds where processes must communicate the different proposals and find a way to select then agree on the “best” one.
The biggest vulnerabilities leader-led protocols have are susceptibility to bribery and targeted DDOS attacks (since the leader is obviously known publicly to the network). Leaderless algorithms are more robust than leader-led algorithms because (1) they are designed to work under asynchrony; which implies (2) they are not as vulnerable or exposed to a single process that can affect the entire network since they can tolerate non-responsive participants. At the same time, asynchronous leaderless protocols struggle with latency and throughput when the protocol exceeds hundreds of processes.
Defining or explaining leaderless is more difficult given that leaderless is more conceptually vague; in a way it’s more about what it is NOT rather than what it is. Some have defined leaderless protocols as one in which stopping any one process would not impede the progress of the overall protocol. We might also use a looser way to think about leaderless, in that the rounds are not dominated by any single process and the more this is true, the more leaderless it is. It might also be seen as the more collaborative the consensus-building is, the more leaderless it is. Here are a three examples of leaderless consensus protocols and where they might lie on this end of the spectrum (from least to most “leaderless”):
Democratic BFT (DBFT): DBFT allows all processes to make and receive binary proposals with the help of a “weak” coordinator; ironically this is the least democratic out of these three examples;
Mir: a multi-proposer protocol in which more than one leader makes proposals in parallel to each other (without conflict); this is the middle of the way;
HoneyBadger BFT: processes continuously receive transactions and within each epoch proffer a subset of these sets of transactions for inclusion in the final block proposal; all transaction sets must be included for the final proposal to the valid; this is a highly collaborative form of consensus block-building and is the closest out of these three to the pure “democracy” end of the leaderless spectrum.
We might pause here and contemplate whether collaborative block-building then is the “most democratic of them all”? If we think about what democratic means in the context of blockchain, we might mean that the maximum number of participants each have at least an equal amount of say in which proposal gets selected. This might apply to both the proposals put forth / considered and of course which is selected for appending. In a leader-led design, this might be layered on via mechanisms such as pseudorandom leader selection, consensus participant vote delegation, or weighted voting (e.g. the more economic stake, the more chances to become a block proposer and decide the next block). This can be juxtaposed against leaderless consensus protocols, which by nature are aligned with maxims such as “democracy for all” as the designs might strive for as equal a say as possible amongst all individual processes, with as little compromise as possible on performance metrics such as communication complexity and latency, etc.
As a side conversation, a question that comes up sufficiently frequently is whether or not the Nakamoto consensus protocol Bitcoin runs is considered leaderless. Without saving the punch line — the answer is I think not. Philosophically the question can be viewed from two major perspectives. (1) Nakamoto consensus shares some of the same properties of leaderless but its result is not leaderless-like; by this I mean that it achieves what we might call “opportunity-based democracy” which we define here as: every process has the equal opportunity to “win” the block and have a say (ignoring the ever increasing cost of hardware requirements), but it’s important to consider that; (2) there is only one “winner” for each round and that winner “dictates” the entire block of transactions. Essentially each process has the opportunity to have a say but in the end only one process has a say. Additionally, the reality is that given the rig requirement / investment at this stage of the game, even if participants join via mining pools, it would seem that in all practicality the protocol is no longer genuinely democratic since it prices most people / new entrants out. Worthy to note here is that Ethereum today is also engaged in an on-going ethics debate around the prioritisation of solo or low-economic stake stakers, which harkens back to the principle of democracy v efficiency and “progress”. This debate is however beyond the scope of this report.
Now we further juxtapose the two categories of consensus protocols — leaderless and leader-led — under another fundamental question: is there is an existential cap on how efficient a leaderless protocol could be, in particular compared to leader-led ones? The question is, even if leaderless BFT consensus algorithms are more desirable according to ethos, can they also be designed in a way that is practically and at a minimum as efficient if not more so than leader-led ones (whether based on implementation practicability or theoretically)?
Historically speaking, this avenue of research has been poorly / little explored. For the most part, the main reason leader-led consensus protocols became popular is because they are easier to design and work well for almost all blockchain protocols in production today. In this current paradigm, users and protocol designers have automatically become committed to the kind of democracy that we experience with Nakamoto consensus — where we concentrate efforts toward the democratic process of becoming a leader at the cost of a truly more democratic and collaborative block-building process where all participants decide a block.
B. Considerations for Being “Leaderless”
So why is it important for us as an industry to be rethinking consensus protocols, and specifically more in the direction of leaderless consensus protocols (or at a minimum moving away from lead-led ones), right now? Besides the fact that a truly leaderless consensus protocol would promote the idealistic properties blockchains have always meant to serve ethos-wise; it is possible that they might be an exciting game-changer for a protocol like Ethereum to mitigate or completely remediate (specifically making some problems irrelevant or non-problems) that rebalances existing trade-offs the L1 is experiencing. Within the context of Ethereum in particular we can find desirable and beneficial opportunities and properties with a leaderless consensus layer that minimises issues around timing games and makes other topics such as proposer-builder separation disappear thus ending “the proposer monopoly.” Furthermore, a leaderless consensus protocol provides censorship and MEV resistance by default given the inclusive collaborative nature and requirements for leaderless block-building.
We end this discussion with a note on the broader, deeper thought about consensus that lies somewhere between ideological arguments and efficiency arguments. We need to pointedly recognise here that consensus is critically important to the industry on this dual-combined (ideological and efficiency) front because blockchain is consensus. If consensus decides what the “truth” of the chain is and which chain is legitimate or canonical, then we want to make sure these decisions are made as honestly and accurately as possible and for the (greater) good of the community. How consensus decisions are made then should and must be fair, equitable, and made in good faith. It’s not the purpose of this report to get into the philosophical thought process and attempt to justify how blockchains should be governed, but we do set forth for now that there might be alternative way of approaching consensus programming and leaderless consensus algorithms could just be for the best.
And so with this short visit into why it’s important for us to explore and even embrace leaderless consensus protocols, let’s review a few of the more interesting findings on existing research and its related principles. These findings will help us establish the building blocks for first answering the question of whether or not a leaderless consensus protocol can be performative enough, and secondly, give us the build blocks to start thinking about an Ethereum-compatible design.
III. FINDINGS — MILESTONES
A. Milestone I: Complete review of relevant BFT literature (including relevant asynchronous BFT literature). Review any interesting computing concepts that might tie into and be helpful for leaderless protocols.
This section addresses Milestone I. For this archival deep-dive exercise I reviewed over 40 publications on consensus protocols (please refer to the Appendix at the end of this report for a list of the most relevant readings). The leaderless consensus algorithm papers were read chronologically in order to gain a sense of how the theoretical thinking behind them might have collectively built upon each other. Indeed, thematic overlaps in thought process and obvious similarities amongst the algorithms were observed, especially when it came to the specific building blocks leveraged.
B. Algorithmic Commonalities
The more promising leaderless consensus algorithms have clear commonalities and were amongst the earlier of leaderless consensus research. In fact, the components used in the 2015 paper titled “Signature-Free Asynchronous Binary Byzantine Consensus with t < n/3, O(n²) Messages, and O(1) Expected Time” presented foundational building blocks which most subsequent leader consensus research used. To prep for an analysis of these components, we break down in plain English the construction of two seminal leaderless protocols that exemplify their usage.
1. Example (1): Signature-Free Asynchronous Binary Byzantine Consensus with t < n/3, O(n²) Messages, and O(1) Expected Time
This consensus protocol uses Binary Byzantine Agreement. Each process proposes a binary value (0 or 1). The distributed algorithm comes to consensus on a single binary value, such that:
1. All honest processes output the same value;
2. The agreed value has been proposed by at least one honest process.
The protocol constructs its “Binary Byzantine Agreement” protocol as follows: each process starts by setting its estimate to the locally proposed value; then the algorithm runs repeated instances of DSBV (explained below) until a single value emerges, replacing the local estimate with the random value from the common coin whenever a process encounters an undecided or default value.
In order to achieve this, the paper builds a suite of gradually stronger distributed algorithms:
Binary Value (BV) broadcast: every process broadcasts its proposed value.
If a process receives a certain message from at least t+1 other processes, it broadcasts this message to all processes;
If a process receives a certain message from at least 2t+1 other processes, it adds the value of the message to the outputs.
Intuition: Byzantine-only messages are filtered since only messages that have been received by 2t+1 (which is the minimum proportion of processes required to guarantee that the number of honest processes outweigh malicious ones) are output by BV.
However, it is not yet a consensus algorithm because it can output both values, and also does not have a termination point.
Synchronized/Strong Binary Value (SBV) broadcast: This algorithm extends BV by providing an output and terminating. However, it is not strong enough to provide full binary consensus, as it can output a single value or a set of both values at the same time; however, the condition is that all the processes that output a single value on termination output the same value. The implementation uses two consecutive invocations of BV broadcast.
Double Synchronised Binary Value (DSBV) broadcast: This is a further iteration of SBV. When a process outputs both values, it is replaced by a default value; however, it can still output two values (in this case one of the binary values plus the default), but never the two binary values. It is implemented by two consecutive invocations of SBV.
In the case certain processes cannot decide, a weak common coin can be drawn. A common coin is a random oracle which is observable by all participants but unpredictable by an adversary (this requires that the common coin value cannot be available until at least one honest process has requested it). Most papers reference Rabin’s “Randomized Byzantine Generals” as the Common Coin framework.
2. Example (2): The Honey Badger of BFTs
HoneyBadger uses CKPS01 multicast which is a reduction from ACS (defined later) to Reliable Broadcast and Asynchronous Binary Byzantine Agreement (ABA). HoneyBadger starts by noticing that the Asynchronous Common Subset (ACS) primitive introduced in CKPS01 allows building a leaderless transaction processing system (i.e., a blockchain) by letting processes propose transactions to include in blocks. However, the implementation in CKPS01 is too inefficient and HoneyBadger proceeds by implementing a new ACS primitive by combining Reliable Broadcast with Asynchronous Binary Byzantine Agreement (ABA) into a more efficient ACS system.
Each process uses Atomic Broadcast from ACS to propose B/N (B out of the total number of processes in the Network) transactions from its queue. Processes propose randomly selected transactions from the first B (FIFO) in each queue. Intuition: this promotes the incorporation of mostly distinct transactions. These subsets of transactions are encrypted and only decrypted once the ACS is complete. Intuition: by decrypting only once ACS is complete and using the prescribed threshold encryption scheme (TPKE); the set is determined before an adversary can learn the contents of any proposal which is when at least one honest process has revealed its decryption share.
N processes use Binary Byzantine Agreement to agree on the vector of the proposed values confirmed to be included in the final set. Intuition: processes might observe the broadcasts completing in a different order from each other so they abstain from proposing the negative (i.e. 0) until they are certain the final vector will have at least N-f positive (1) bits.
C. Principles / Building Blocks for Leaderless Consensus Protocols
1. Reliable Broadcast
The original Reliable Broadcast concept is known to be originated by Gabriel Bracha and Sam Toueg in “Asynchronous Consensus and Broadcast Protocols”. Reliable Broadcast must at least satisfy the necessary conditions of validity, agreement, and totality per the below:
Validity: If a correct process outputs a set v, then |v| >= N-f and v contains the inputs of at least N — 2f correct processes;
Agreement: If a correct process outputs v, then every process outputs v;
Totality: If N-f correct processes receive an input, then all correct processes produce an output.
2. Binary Byzantine Agreement*
*Binary Byzantine Agreement can be modified to accommodate multi-values.
The algorithm must be able to solve for consensus within systems where processes can fail in a Byzantine — or malicious — manner (as in, due to a Byzantine actor). In order to successfully solve for this, the following conditions must be met:
Validity: A decided value was proposed by a correct process (no value proposed only by faulty processes can be decided);
Agreement: No two correct processes decide different values;
Decision: Each correct process decides.
On this note, a similar primitive that is also sometimes used within leaderless consensus protocols is Asynchronous Verifiable Information Dispersal (AVID-FP). This concept is presented in a 2004 paper “Asynchronous Verifiable Information Dispersal” by Christian Cachin and Stefano Tessaro. This scheme combines a reliable broadcast protocol with erasure coding to achieve verifiability for information dispersal networks in an asynchronous environment that is optimally Byzantine-resistant.
3. Common Coin as the Tie-Breaker
In the case of ambiguous protocol outcomes where an agreement cannot be reached, an oracle that introduces randomness is used. Common coins can be weak or strong and its purpose is to resolve ambiguity / stalemates at the end of a main procedure.
4. “Forced” Inclusion of “Mini-blocks” or Mini Transaction Sets (Multi/Unanimous proposals)
Certain leaderless consensus protocols such as HoneyBadger, BigDipper, and Mir enforce effective leaderless consensus by containing a protocol requirement that all leaders (either all processes or a certain subset of processes) propose at least a part of the round’s transaction sets. These transactions are then required to be included in the final block proposal.
D. Attributes Analysis
Below are common attributes / assumptions we see frequently amongst leaderless consensus protocol designs.
Optimally resilient: requiring n >= 3f+1 to tolerate f Byzantine or faulty processes.
All-to-all communication complexity.
Operates within an asynchronous or eventually synchronous (i.e, partially synchronous) network environment.
Deterministic; worthy to note — no deterministic asynchronous consensus protocol can tolerate even a single non-Byzantine failure; in a non-deterministic environment, the protocol cannot tolerate more than N/3 dishonest processes.
Signature-free: many leaderless consensus algorithms are signature-free which is made possible by direct point-to-point communication channels amongst all processes in an all-to-all manner. Processes must be allowed some amount of privacy in process-to-process communications in order to proceed to consensus safely (in the context of Byzantine actors).
Threshold encryption: helps to ensure that the contents of a proposal are kept private from Byzantine actors (for example those who are trying to reorder or censor transactions) before consensus has been reached.
An important and interesting question to explore at this juncture is whether or not any of these these attributes are inevitable properties of a leaderless consensus protocol. The answer is that none of these attributes are hard and fast rules or logically must follow — in the sense it is not according to theoretical impossibility a leaderless consensus protocol cannot exist unless it subscribes to any of these attributes. Given this freedom, we are able to move forward without such constraints in the design for an Ethereum-compatible leaderless consensus protocol.
E. Milestone II — Implementations and Practical Considerations
Answer two questions: (1) Is a leaderless BFT protocol theoretically always less performant (efficient and practical) than a leader-led protocol, and (2) if yes, by how much (can we quantify this?)?
We did not run any of the algorithms studied as part of this project, but did review performance metrics observed by experiments run by the papers’ authors. These metrics can only be meaningful when considered in the context of a benchmark and of course for this project it makes sense to take Ethereum L1’s state today as the benchmark; however Ethereum’s consensus algorithm and overall design is highly complex and loaded with details that make it difficult to compare with simplified, more abstract protocols such as HoneyBadger.
As is, these other protocols are not in a usable state for Ethereum and so, the reasonable conclusion to make for now is that the reality of measuring a leaderless consensus protocol design for Etheruem would require a mature one with the relevant low-level details that would likely impact performance and practicality.
These papers do provide a proof of concept that there are generally performant leaderless consensus protocol designs which gives us strong motivation to move forward. This is especially interesting in the case of HoneyBadger which carried out an experiment on geographically distributed (5 continents) WAN with 104 processes at 1.5k confirmed transactions per second throughput.
IV. WHAT’S NEXT
So, do these findings tell us that leaderless protocols are awesome? Should we embrace them more? Are they more performant? Can we successfully design a leaderless consensus protocol that is Ethereum-compatible? Will it really resolve and/or dissolve a few of the chronic issues Ethereum is experiencing today?
To answer these questions, let’s take a quick overview of the issues we believe a leaderless consensus protocol could potentially solve which are as follows.
A. Motivations for Ethereum
Timing Games
Block producers are incentivised to submit block proposals as late as possible within each slot since the closer to the “deadline” they submit their proposal, the higher the block rewards; the reason for this phenomenon is that the opportunity for price deviation and thus asset pricing arbitrage (on trades) has the highest probability the longer the duration of time from the previous price movement (i.e. last block).
Censorship Resistance
Prevent block producers from omitting certain transactions from the block proposal. Weak — omission from own block. Strong — prevent others from including certain blocks.
MEV
MEV (Maximal Extractable Value) refers to profit that is “extractable” or obtainable from blockchain activity made possible by the chain’s inherent engineering design / architecture. MEV specifically refers to gains in excess of block rewards, fees, and tips. MEV is fundamentally possible on Ethereum based on two primary principles: (1) It’s possible to predict with legitimate levels of confidence what an anticipated outcome or effect of a confirmed block would be because of public mempools and the linear nature of block building. (2) This then makes it reasonable for rational MEV searchers to manipulate the ordering of or in/exclusion of certain transactions in one block or even in-between blocks or across chains in order to capture an arbitrage opportunity. Arbitrage is used loosely here in the sense that there is information / market / pricing asymmetry that would be profitable to action on.
Proposer-Builder Separation
There has been interest in separating the proposer and builder role in order to reduce reliance on extra-protocol services such as MEV-Boost which have become centralised services and requires Ethereum’s (and its users’) reliance and trust in them. Although the builder is not always the proposer, separation of these two roles is not an enforced.
Proposer Monopoly
As discussed at the beginning of this report, some consider and believe that having one primary block proposer for each slot is not very democratic in nature or practice.
In a leaderless consensus protocol, there are a few tools and mechanisms that can be incorporated to mitigate the impact of the above issues. For example, of course the “proposer monopoly” issue would not exist under a leaderless consensus protocol. Consensus and execution roles would collapse together on block-building activities which would remove the need for Proposer-Builder Separation which today might be described as a patchwork solution rather than root-cause solution for Ethereum’s concern about extra-protocol services. Harder innate problems such as censorship resistance, MEV, and timing games could be mitigated by a design that enforces transaction randomisation through collaborative block-building whilst taking into account execution failures and economic incentives.
Further to Ethereum-led reasons to consider a leaderless consensus protocol, standard leaderless consensus protocol attributes are naturally aligned with Ethereum’s current stage of development. For example the forced mini-blocks inclusion concept is in line with Ethereum’s proposal for inclusion lists, which in principle through the forced inclusion of certain transactions is a non-intended byproduct of serving as a non-malicious check against participating processes when it comes to censorship resistance.
The end goal of this particular pure research project is to create a relatively complete skeleton of a leaderless protocol that would work for core Ethereum. In regards to Milestone III and IV, we find at the end of the first two milestones there is good potential for the creation of a leaderless BFT protocol can be just as performant along with high standards of robustness.
IV. LITERATURE
Borran, F. (2009). A leader-free Byzantine consensus algorithm.
Lamport, L. (2011). Leaderless Byzantine Paxos.
Mostéfaoui, A., Moumen, H., & Raynal, M. (2015). Signature-free asynchronous binary Byzantine consensus with t < n/3, O(n²) messages, and O(1) expected time.
Miller, A., Xia, Y., Croman, K., Shi, E., & Song, D. (2016). The Honey Badger of BFT protocols.
Duan, S., Reiter, M. K., & Zhang, H. (2018). BEAT: Asynchronous BFT made practical.
Crain, T., Gramoli, V., Larrea, M., & Raynal, M. (2018). DBFT: Efficient leaderless Byzantine consensus and SMR.
Gągol, A., et al. (2019). Aleph: Efficient atomic broadcast in asynchronous networks.
“Team Rocket.” (2020). Avalanche: Scalable and probabilistic leaderless BFT consensus through metastability.
Antoniadis, P., et al. (2021/2022). Leaderless consensus.
Stathakopoulou, C., et al. (2021). Mir-BFT: High-throughput robust BFT for decentralized networks.
Spiegelman, A., et al. (2022). Bullshark: DAG BFT protocols made practical.
Flamini, A., et al. (2022). Cob: Leaderless Byzantine agreement for arbitrary value sets.
Danezis, G., et al. (2022). Narwhal and Tusk: A DAG-based mempool and efficient BFT consensus.
Müller, S., et al. (2022). Tangle 2.0: A DAG-based probabilistic consensus protocol.
Xue, J., et al. (2023). BigDipper: Scalable Byzantine fault tolerance via mini-block aggregation.
Niu, J., et al. (2023). EBFT: Efficient Byzantine fault tolerance with randomized proposals.
Morais, R., et al. (2023). Nero: Deterministic leaderless BFT for DAG systems.
Gelashvili, R., et al. (2024). Jolteon and Ditto: Network-adaptive efficient consensus with asynchronous fallback.
Castro, M., & Liskov, B. (1999). Practical Byzantine fault tolerance.
Lamport, L. (2006). Fast Paxos.
Moraru, I., Andersen, D. G., & Kaminsky, M. (2013). EPaxos: Egalitarian consensus.
Zhang, I., et al. (2015). Building consistent transactions with inconsistent replication.
Buchman, E., Kwon, J., & Milosevic, Z. (2018). The latest gossip on BFT consensus.
Bonniot, L., et al. (2019). PnyxDB: Byzantine fault-tolerant database with eventual consistency.
Guo, S., et al. (2020). Dumbo: Faster asynchronous BFT protocols.
Qin, T. (2020). Leaderless Byzantine fault tolerance.
Niu, J., et al. (2020). Leaderless Byzantine fault-tolerant consensus.
Tollman, S., et al. (2021). EPaxos revisited.
Du, H., et al. (2021). Leader confirmation replication for millisecond consensus in private chains.
Wang, X., et al. (2022). A hierarchical Byzantine fault tolerance protocol based on node reputation.
Lu, H., et al. (2023). Aurora: High-throughput leaderless consensus.
Lu, H., et al. (2023). Arena: Multi-leader synchronous Byzantine fault tolerance.
Dwork, C., Lynch, N., & Stockmeyer, L. (1988). Consensus in the presence of partial synchrony.
Abraham, I., et al. (2018). Validated asynchronous Byzantine agreement with optimal resilience and efficiency.
Kleppmann, M. (2020). Byzantine eventual consistency and the limits of peer-to-peer databases.
Wang, G. (2021). SoK: Understanding BFT consensus in the age of blockchains.
Stathakopoulou, C., et al. (2022). State machine replication scalability made simple.
Zhang, Q., et al. (2023). Reaching consensus in the Byzantine empire: A comprehensive review of BFT algorithms.
