**BACKGROUND**

Earlier this year I received a grant from the Ethereum Foundation to perform research on leaderless consensus protocols. The best outcome would include an architecture of a new, usable leaderless BFT protocol framework for Ethereum Layer 1.

My current progress is the completion of an archival deep-dive on leaderless consensus protocols to-date.

This blogpost is for anyone interested in consensus mechanisms and/or would be curious to read light discourse on leaderless v leader-led consensus protocols.

This is the first part of a series of thoughts and findings for my project.

**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 adversely 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 discussion.

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.