Consensus Without Trust — How Mutually Distrusting Participants Agree on One Ledger

Reaching a Single Answer Without a Manager

How much money is in my bank account is told by the ledger kept by the bank. There is only one ledger and only one manager guarding it, so if you wonder which record is correct, you can just ask the manager.

When there is no manager, the situation changes. Let us imagine that thousands of computers each hold a copy of the ledger, no one trusts anyone else in particular, and some of them might lie on purpose. These computers must come up with the same answer for what is written in the ledger right now. "What Is a Blockchain" called this task consensus. It is the process by which multiple parties who do not particularly trust each other settle on a single answer for what is written in the ledger right now. A consensus protocol is a procedure that predetermines the rules to follow and the messages participants will exchange to reach that answer.

This problem is much older than blockchains. Distributed databases that replicate data across multiple servers have long kept their copies synchronized using consensus protocols like Paxos, Raft, and Byzantine fault tolerance. Choosing which protocol to use has always been a matter of deciding what to gain and what to give up among performance, consistency, and reliability (DOI: 10.36227/techrxiv.175606742.20986239/v1 — preprint, not peer-reviewed). Bank networks, aircraft control systems, and the cloud services we use every day all run by solving this problem.

Blockchains added one more condition to this old problem. They allowed anyone to participate. A consensus algorithm is a device that protects trust and integrity within a decentralized system without relying on central authority, and its design does not converge on a single correct answer (DOI: 10.63345/sjaibt.v2.i4.102).

This article does not cover prices, investment, or which coin is right; it looks only at the principle of how participants who cannot trust each other agree on a single record. The goal is a foundation strong enough that you will not get lost in the first paragraph when you open a paper in this field.

Two Things Consensus Must Uphold and Faults It Must Endure

There are broadly two things we hope for from a consensus protocol. One is that bad things do not happen, and the other is that good things eventually happen.

Safety is the property that honest participants do not arrive at conflicting conclusions. Preventing the same money from being spent twice—that is, spending the same thing twice as discussed in "What Is a Blockchain"—is ultimately a matter of safety. Liveness is the property that the system does not stop forever and eventually decides on something. A system that decides nothing also produces no contradictory conclusions, so it preserves safety, but it is useless. Therefore, both are required.

There are also two types of ways participants can fail. A crash fault is a failure where a participant simply stops or ceases to respond. A Byzantine fault is a failure where a broken participant does not stop at just halting, but behaves arbitrarily. It may lie, tell different things to different peers, break rules, and collude with other malicious participants. Such erratic behavior can stem from software bugs, operator errors, or malicious attacks (DOI: 10.1145/571637.571640).

Open networks that anyone can join come with one more problem. This is a Sybil attack as defined in "What Is a Blockchain", an attack that inflates headcount by creating fake identities in bulk. If one person puts forward thousands of identities to pretend to be a majority, those fake identities can act like Byzantine faults all at once. Therefore, public networks that anyone can enter without permission must choose the participant to produce the next block in a way that withstands Sybil attacks (DOI: 10.3390/a16010034).

Consensus is the task of maintaining safety and liveness together while enduring Byzantine faults, and in the case of an open network, it must fend off Sybil attacks on top of that. The designs we will look at later all diverge in how they divide and uphold these requirements.

Generals Mixed with Traitors — The Byzantine Generals Problem

The Byzantine Generals Problem is a question framed through the story of generals, asking whether the rest can reach a single decision when some participants can act as traitors at will. Several generals surround a city and must decide whether to attack or retreat by sending messengers back and forth. However, some of the generals are traitors, meaning they might tell one general to attack and another to retreat. If the loyal generals make different decisions, the attack fails.

This problem is a generalization of the two-generals problem, and countless consensus algorithm studies subsequently followed as attempts to answer this problem (DOI: 10.3390/s23052739). Early Byzantine fault-tolerant algorithms did solve the problem, but they required an unnecessarily large number of messages exchanged, making it difficult to increase the number of participants (DOI: 10.55677/craj/03-2025-vol02i07).

Byzantine Fault Tolerance (BFT) is a design that prevents the outcome from wavering even when traitors are mixed in. You do not ultimately need to know who the traitors are. It is only required that the number of traitors does not exceed a predetermined ratio. What that ratio is comes up again later in the BFT family.

A Network Where You Never Know When a Message Will Arrive — The FLP Impossibility

It might seem that as long as there are few enough traitors, we can always reach consensus, but the answer changes depending on the properties of the network.

An asynchronous network is a network where no upper bound is guaranteed for when a message will arrive. In contrast, the synchronous model assumes that messages between honest participants always arrive within a predetermined time Δ (DOI: 10.1287/stsy.2022.0031). Between them lies the partially synchronous model. This is a model that assumes messages may be delayed for a while, but eventually start arriving within an upper bound.

The FLP impossibility is a proof that in an asynchronous network, even if just a single participant (process) fails, the possibility remains that any consensus protocol will fail to ever reach a decision. Published in the Journal of the ACM in 1985, this proof notes that conversely, in a synchronous system, solutions are known even for the famous Byzantine Generals Problem (DOI: 10.1145/3149.214121). This impossibility holds just the same even if the failure is merely a crashing stop (arXiv:1502.02538 — preprint, not peer-reviewed). The name comes from the initials of the three authors, Fischer, Lynch, and Paterson (arXiv:cs/0209014 — preprint, not peer-reviewed).

The wall arises from the condition of asynchrony. If there is no upper bound on when messages will arrive, it is fundamentally impossible to tell whether a non-responsive participant has stopped or is merely slow. If you keep waiting for a stopped participant, a decision is never reached, and if you make a decision while excluding a slow participant, you may end up contradicting a message that arrives late.

Four Ways Around the Wall

What FLP blocks is consensus that possesses all three conditions at once. Here, deterministic means that no randomness is used, so the same choice is always made in the same situation. When even a single participant can break down, consensus that is deterministic, runs asynchronously, and always terminates is impossible, but letting go of any one of the three conditions opens a path. Research over the 20 years following the publication broadened the base model to bypass this result, and there were four methods. They are using randomness, adding timing assumptions, attaching failure detectors, or using synchronization primitives stronger than the base model (arXiv:cs/0209014 — preprint, not peer-reviewed).

A failure detector is a device that provides information on which participant has stopped. Even if that information is sometimes wrong, if the detector is sufficiently powerful, consensus that withstands crashes can be solved (arXiv:1502.02538 — preprint, not peer-reviewed).

Timing assumptions are a method of pinning down that messages arrive within a maximum $\Delta$. There is a cost to this assumption. The safety guarantees of protocols following the longest chain worsen as $\Delta$ grows larger, while the delays of real-world networks occasionally become much greater than usual. Guarantees tailored to the worst-case delay can therefore be overly pessimistic. Models treating delay as a probability distribution derived better security guarantees than existing ones in networks where delays occasionally become very large (DOI: 10.1287/stsy.2022.0031).

On the side of randomness, it is assumed that instead of an adversary choosing the arrival order of messages, delivery follows a random order. Then, probabilistic guarantees that are impossible in the standard asynchronous model as well as the partially synchronous model become achievable (arXiv:2502.09116 — preprint, not peer-reviewed).

Theory and practice diverge here. Consensus protocols for asynchronous networks are generally complex and inefficient, so real-world systems often rely on synchronous protocols. The preprint making this diagnosis proposes a mechanism that makes the upper layer behave as if it is on a synchronous network, and argues that asynchronous consensus dealing only with participants that crash can be simpler and more robust than the Paxos family (arXiv:1907.07010 — preprint, not peer-reviewed). A stronger model in theory does not always win in practice.

Proof of Work: Betting Computation to Buy Voting Rights

Now we look at three branches that solve this problem in an open network. Each branch ties up voting rights in a different place and gives up something different.

As seen in "What Is a Blockchain", Proof of Work is a method where attaching the next block to the chain requires first solving a puzzle to match the seal. Nakamoto consensus is the consensus method used by Bitcoin, which uses Proof of Work as a voting instrument to let honest miners each continue the longest chain they know. The design is simple, but it yields meaningful security guarantees under the assumption that honest participants hold the majority of the computing power at any given point. This property holds even if the computing power of the entire network fluctuates wildly over time (arXiv:2505.14891 — peer-review pending preprint).

The reason Proof of Work stops Sybil attacks also lies in the primer. Identities can be created for free, but computation cannot be generated for free. A systematic literature review that filtered out 21,799 records concludes that systems resilient to Sybil attacks commonly followed the principles of Proof of Work or Proof of Stake, and that fundamental ways to withstand Sybil attacks in permissionless environments are few. Methods relying on reputation systems or real-world identities had limited resilience. The same review also notes that for systems with small attack surfaces, many new methods with weaker protection would suffice (DOI: 10.3390/a16010034).

The costs are also well known. They are energy consumption, scalability bottlenecks, and the concentration of power into mining pools (DOI: 10.63345/sjaibt.v2.i4.102). One might wonder if we could bet other resources instead of computation, but changing the resource also changes the security properties. Proof of Space, which proves that storage space has been secured, has been proposed as a sustainable alternative. However, no method is known for building a secure longest-chain protocol with Proof of Space under dynamic availability—meaning the participating resources increase or decrease at any time. One preprint proves that no such protocol exists without additional assumptions, and sets a numerical lower bound on the fork length needed for double-spending (arXiv:2505.14891 — peer-review pending preprint).

Buying Voting Rights by Staking

Proof-of-stake is, as discussed in "The Right to Write a Line in the Ledger", a method of reaching consensus by proving one's share in the ledger instead of doing calculations. In this method, the protocol decides who is assigned which role based on the distribution of stakes recorded in the ledger itself, thereby preventing Sybil attacks. Simply creating fake identities does not increase the total amount of stake, so attackers cannot gain more turns. The issue of voting power concentrating when a single entity sets up multiple pools is followed up in "Is Blockchain Really Decentralized — From Mining Pools to MEV, Where Power Reassembles". However, the stake distribution used by a protocol cannot be completely up to date. When examining major proof-of-stake proposals whose security has been proven, there was a time lag of several days between the distribution used by the protocol and the current distribution (arXiv:2001.04187 — preprint, not peer-reviewed). This means voting rights are distributed based on the ledger from several days ago.

In the economic model followed in "The Right to Write a Line in the Ledger", if rewards are kept sufficiently modest, there exists an equilibrium that reaches consensus as quickly as possible, while equilibria where the chain persistently remains split are ruled out. Unlike proof-of-work, proof-of-stake requires validators—participants who produce and confirm the next block—to be stakeholders who hold a stake at the same time (DOI: 10.1093/rfs/hhaa075). If they break the chain, the share they have staked is ruined along with it.

Slashing is a penalty mechanism that confiscates the staked funds of a validator who breaks the rules. There is a framework that evaluates the security of proof-of-stake by dividing it into the costs incurred by an attacker and the profits gained by the attacker, and the study establishing that framework proposed an insurance mechanism that distributes the confiscated funds. The goal is strong cryptoeconomic security where honestly transacting people never lose money (arXiv:2401.05797 — preprint, not peer-reviewed).

The actual outcomes of the transition have also been measured. Ethereum switched to proof-of-stake in September 2022, and studies analyzing the period before and after show that energy consumption dropped by 99.98% and the time between consecutive blocks became a steady 12 seconds (DOI: 10.3390/commodities2020006). The earlier comparative study notes that while proof-of-stake greatly reduces energy consumption, it raises concerns that wealth and validators may concentrate on one side (DOI: 10.63345/sjaibt.v2.i4.102).

Proof-of-stake also has its own inherent weaknesses. It is exposed to long-range safety attacks that cannot be punished by slashing—namely, attacks trying to rewrite the ledger using a branch that split off from a very distant point in the past. Its power to maintain liveness is weak, and it is difficult to establish initial security when token prices are low. One preprint argues that these weaknesses are inherent to all proof-of-stake chains lacking an external source of trust, and proposes a protocol to solve this by leaving an intermediate checkpoint on an external chain—what "The Right to Write a Line in the Ledger" calls a marker stating "up to this point, there is no reverting" (arXiv:2207.08392 — preprint, not peer-reviewed).

The BFT Family, Settled on the Spot Through Quorum Voting

The third branch stems directly from classical distributed systems. Here, a node—a computer holding a copy of the ledger and exchanging messages with other participants—is called a replica. A quorum is the pre-agreed number of participants sufficient to finalize a decision, and the BFT family finalizes a decision on the spot once enough affirmative votes to meet the quorum are gathered.

The representative algorithm PBFT, formalized in 2002, is safe even in asynchronous environments like the internet. Thanks to mechanisms that revive failed replicas ahead of time, it reports that as long as failed replicas account for less than 1/3 of the total within a brief vulnerable window, the system can tolerate any number of failures while it runs (DOI: 10.1145/571637.571640). In partially synchronous systems, tolerating $f$ failed replicas typically requires $3f + 1$ nodes (arXiv:2205.08938 — preprint, not peer-reviewed).

The number one-third comes from the requirement that quorums must overlap with each other. If two different decisions each receive affirmative votes from a quorum, the two quorums must overlap at some participants. At least one honest participant must remain in that overlapping spot; since they would never vote in favor of both decisions, contradictory finalization is prevented. If a quorum is set larger than two-thirds of the total, the two quorums overlap at more than one-third of the participants, and if traitors are fewer than one-third, an honest participant is guaranteed to remain in that overlap. Yet quorums cannot be made arbitrarily large. Because liveness must be preserved so that a quorum can still be gathered even if traitors refuse to vote, a quorum must be small enough to be filled using only the non-traitors. The upper limit of one-third for the traitors tolerated by designs that finalize via quorum in partially or asynchronously synchronous networks is because a quorum must still gather even if traitors drop out, and an honest participant must remain in the overlapping area of two quorums.

The advantage of this branch is that a finalized block is finalized on the spot, and the price is communication volume. Early algorithms saw the number of messages grow as the square of the number of nodes, making it difficult to scale participants. Among structures designed to alleviate this, asynchronous protocols trade away low latency to gain robustness (DOI: 10.55677/craj/03-2025-vol02i07). PBFT works well in private and consortium blockchains, but comparative studies diagnose that it lacks scalability in large public networks (DOI: 10.63345/sjaibt.v2.i4.102).

Subsequent designs pushed against this wall from multiple directions. An approach that divides up the replication of commands while centralizing only the sequencing reported that in a deployment of 300 replicas scattered across multiple regions, throughput was about 3 times better and latency was about 50% better than before (DOI: 10.14778/3538598.3538599). There are also speculative approaches that skip the expensive three-phase finalization procedure and respond first (DOI: 10.1145/1323293.1294267). Asynchronous BFT built on a structure (DAG) where blocks point to each other like a mesh rather than in a single line reports processing over 100,000 transactions per second with sub-second latency across a wide-area network (arXiv:2410.08670 — preprint, not peer-reviewed).

What the Three Branches Stake and Give Up

The three branches staked different things on the same problem.

Because the BFT family counts quorums by headcount, it is difficult to use as-is in open networks where anyone can spin up identities. Thanks to high throughput and finality, BFT has become core to modern permissioned blockchains with fixed participants (arXiv:2205.08938 — preprint not peer-reviewed), and many Proof-of-Stake payment systems rely for security on quorum voting by validators who have staked their holdings (arXiv:2503.16783 — preprint not peer-reviewed). To robustly resist Sybil attacks in a permissionless open network, voting power must be tied to something scarce, and what is given up is determined by what that scarce thing is.

"It Is Finalized" Means Different Things Across Lineages — Finality

The most commonly misunderstood concept in this field is finality. Finality is the state where a recorded transaction can be considered unalterable, and it is what the phrase "this transaction is finalized" points to. "What Is a Blockchain" calls this same state determinism, describing it in a proof-of-work ledger as a probability traded off against waiting time, with that probability resting on the condition that more than half of the computing power is not gathered in one hand. The meaning of the phrase "it is finalized" differs by lineage.

In Nakamoto consensus, the deeper a block is buried within the chain, the greater the confidence in that block. In BFT state machine replication, a block that has been committed is a secure block with a fixed resilience threshold (arXiv:2101.03715 — preprint before peer review). State machine replication is a method where all replicas execute the same commands in the same order to maintain the same state, and committing is the act of finalizing and recording a block with the approval of a quorum. A fixed resilience threshold means that as long as traitors do not exceed a set ratio, say one-third, that block will not be overturned.

This difference creates a wide divergence in practice. In probabilistic finality, the probability of being overturned simply decreases and never hits an exact zero, whereas in deterministic finality, finality is complete the moment a quorum is gathered, as long as traitors do not exceed the set ratio. The Nakamoto lineage is the former, and the BFT lineage is the latter. Categorizing consensus into deterministic consensus and probabilistic consensus is also a standard way of organizing the field (DOI: 10.54097/hset.v47i.8224).

The space between these two forms is not walled off. The preprint summarizing this contrast layered Nakamoto-style growing guarantees onto partially synchronous BFT state machine replication. During periods when the network runs smoothly and traitors are few, the guarantee grows larger, and committed blocks that have accumulated guarantees during that period can withstand traitors exceeding 1/3 and up to a maximum of 2/3 even after that period passes (arXiv:2101.03715 — preprint before peer review).

Real-world systems sometimes mix the two. As Ethereum transitioned to proof-of-stake, it moved closer to BFT while also retaining the Nakamoto style, resulting in a complex structure where the chain can grow by branching like a tree while participants strive to finalize blocks. A preprint analyzing this categorized attacks that threaten liveness and found new attacks in the fixed protocol even after the Ethereum community patched some of them. The conclusion was that safety holds, but liveness is guaranteed only probabilistically (arXiv:2210.16070 — preprint before peer review).

Research to accelerate finality also continues. A 2026 preprint reports finding conditions in DAG-based BFT where results can be considered safe even before official commitment, allowing transactions to be finalized in advance and reducing latency by up to 65% compared to the latest asynchronous BFT protocols (arXiv:2604.03974 — preprint before peer review).

Four Common Misunderstandings

Misunderstanding 1 — "A few confirmations mean absolute safety." The number of confirmations is how many blocks have been added behind the block containing your transaction. In the probabilistic finality family, the number of confirmations is a knob that lowers the probability of a rollback, and there is no threshold past which it suddenly becomes completely safe. A 2026 preprint accurately calculates with a single formula the probability that a double-spending attack succeeds at a given confirmation depth, showing that the required confirmation depth depends on the attacker's stake share and the protocol's configuration values (DOI: 10.20944/preprints202604.0694.v1 — preprint, not peer-reviewed). The authors state that this result is limited to the interpretation model they built and does not yet cover cases where forks are resolved late or the actual fork-choice and finality rules of Ouroboros Praos.

This concern can also be calculated from the configuration values of actively running protocols. A reorganization is the process of swapping out a few already-attached blocks for a different branch to erase the transactions inside them. According to a 2020 preprint, on the Tezos proof-of-stake protocol at the time, an attacker holding 40% of the stake could execute a 20-block malicious reorganization roughly once a day, and once the stake exceeded 40%, the success probability grew faster than linearly (arXiv:2009.05413 — preprint, not peer-reviewed). That attacker could even know in advance when an attack opportunity would arrive. The same study showed that fixing the protocol configuration values could cut this opportunity down to 1 100th. Instead, configurations that prevent deep reorganizations clashed with configurations that prevent selfish mining—short reorganizations that turn a profit even without double spending.

Misunderstanding 2 — "Proof of stake is just proof of work without the energy use." While the drop in energy is true (99.98% as seen earlier), the two methods differ fundamentally in the assumptions their security relies on. If rewards are sufficiently restrained, proof of stake rules out equilibria where the chain remains split by requiring validators to be stakeholders (DOI: 10.1093/rfs/hhaa075), and it defends against Sybil attacks using the distribution of stakes inside the ledger (arXiv:2001.04187 — preprint, not peer-reviewed). Proof of work defends against them using physical costs outside the ledger. The punishment methods differ as well. Proof of work has no mechanism equivalent to slashing.

Which side is safer depends on the model and configuration values. An economic model comparing the equilibrium security of both methods generally derived the conditions under which proof of work is safer and those under which proof of stake is safer. And plugging in real-world values, it reports that, all else being equal, proof of stake is safer, with that advantage being especially pronounced in large chains (DOI: 10.1093/rfs/hhaf013). Because this conclusion holds under a specific model and configuration values, it must be read alongside inherent weaknesses of proof of stake such as long-range attacks, which we saw earlier (arXiv:2207.08392 — preprint, not peer-reviewed).

Misunderstanding 3 — "Decentralization naturally brings safety." There is a preprint that ran five modern blockchains in a controlled environment, deliberately introduced faults, and measured fault tolerance (arXiv:2409.13142 — preprint, not peer-reviewed). Except for one, the rest wobbled significantly even when only a small fraction of the network failed, and some failed to recover from a brief fault in a single location. The mere fact that something is scattered does not guarantee fault tolerance.

The problem is not just in the implementation. A 2019 preprint pointed out that none of the Byzantine consensus solutions used by blockchains at the time were formally verified, arguing that their correctness was at best proved "by hand," and listed six vulnerabilities, two of which were new counterexamples (arXiv:1909.07453 — preprint, not peer-reviewed). The same study actually formally verified two BFT components of a blockchain using a model checker, a tool that machine-checks all possible cases. Formal verification is a method of writing down the properties that must be kept—in the words of "What Is a Smart Contract?"—using the language of mathematics, and proving that those properties are maintained. The authors conclude that formal verification of consensus protocols has now become relatively straightforward yet essential.

The security models of deployed BFT protocols also differ slightly from those accepted in academia. If an adversary can completely control the delivery order of network messages, neither Ethereum 2.0 nor Polkadot's BFT protocol achieves liveness even in a synchronous network (DOI: 10.1145/3538227). However, the authors add that it remains unclear whether an actual adversary can exert such control over delivery order at internet scale. A gap always remains between proofs on paper, deployed implementations, and real networks.

Misunderstanding 4 — "A perfect design exists somewhere." There is a study that formalized the so-called blockchain trilemma—the idea that decentralization, security, and scalability cannot be simultaneously maximized—by defining the three properties formally and then arguing the case through proof by contradiction and computational complexity analysis (DOI: 10.3390/app15010019). Because such formalizations depend heavily on how the three properties are defined, they are themselves a subject of debate. Even so, it is better to drop the expectation that a design possessing everything will be found somewhere. Consensus design is less about finding a single correct answer and more about choosing what to give up.

Find the Model First at the Beginning of a Paper

The foundation this article has built boils down to three sentences. The difficulty of consensus comes from participants who lie (Byzantine faults) and messages that may arrive at any time (asynchronous). Because open networks add Sybil attacks to this, voting power must be tied to something scarce, whether computation or stake. The meaning of the word "finalized" differs by lineage, and confusing probabilistic finality with deterministic finality misaligns all subsequent judgments.

We leave further reading categorized by branch.

• The overall landscape: A review summarizing recent milestones in consensus algorithms through the trade-offs of energy efficiency, decentralization, and security (DOI: 10.1186/s42400-023-00163-y), and a study classifying their lineage into an evolutionary phylogenetic tree (DOI: 10.3390/s23052739).
• The BFT lineage: A survey categorizing improvement methods from classical to modern (DOI: 10.3390/electronics12183801), and an analysis pointing out the gap between deployed protocols and academic models (DOI: 10.1145/3538227).
• Scalability: A study analyzing sharding—which divides the ledger into multiple pieces (shards) for separate processing—on top of proof-of-stake. Under the conditions of 4,000 nodes, 10 shards, and a 33% traitor tolerance ratio per shard, it calculated approximately 4,000 years until failure (DOI: 10.3390/s23052819).
• A more realistic model: A 2025 preprint that adds profit-driven rational participants to honest and Byzantine participants. It proved that under partial synchrony, if rational and Byzantine participants combined exceed 1/3 of the total, quorum-based protocols cannot achieve state machine replication. Then, assuming an upper bound $\Delta$ on message delay, it showed that by simply changing the finality rule, any quorum-based state machine replication can be made to withstand 1/3 Byzantine and 1/3 rational participants. Actual measurements of Ethereum and Cosmos showed that the 5/6 participation threshold required for this design is met in over 99% of blocks (arXiv:2503.16783 — preprint, not peer-reviewed).

"Is Blockchain Really Decentralized — From Mining Pools to MEV, Where Power Reassembles" follows how voting power actually concentrates in a few places, and how mining pools and stake pools alter that distribution.

The most useful habit when reading in this field is to find the model first at the beginning of a paper. Is the network synchronous, partially synchronous, or asynchronous? Is the failure a crash or Byzantine? Is participation open or permissioned? Is finality probabilistic or deterministic? Once you check these four answers, what the theorems and experiments that follow are claiming becomes clear. Before comparing performance numbers, you must compare models to read what those numbers actually say.

Source Papers

• "Distributed Database Systems and Consensus Protocols…" (2025) — DOI: 10.36227/techrxiv.175606742.20986239/v1 — Trade-offs in performance, consistency, and reliability between Paxos, Raft, BFT, and distributed databases. Preprint prior to peer review (TechRxiv).
• "Consensus Algorithms Beyond Proof of Work: A Comparative Study" (2025) — DOI: 10.63345/sjaibt.v2.i4.102 — Consensus as a mechanism ensuring trust and integrity without a central authority. Problems with PoW regarding energy, scalability, and mining pool centralization, while PBFT lacks scalability in large public networks.
• "Practical byzantine fault tolerance and proactive recovery," ACM Transactions on Computer Systems (2002) — DOI: 10.1145/571637.571640 — Causes of Byzantine faults (bugs, operator errors, malicious attacks). Tolerates failures of fewer than 1/3 of the replicas within a vulnerability window.
• "Sybil in the Haystack: A Comprehensive Review of Blockchain Consensus Mechanisms…," Algorithms (2023) — DOI: 10.3390/a16010034 — Definition of Sybil attacks and a systematic literature review (21,799 papers → 483 papers). Strong Sybil resistance is found only in PoW/PoS principles.
• "A Taxonomic Hierarchy of Blockchain Consensus Algorithms," Sensors (2023) — DOI: 10.3390/s23052739 — A taxonomic classification of consensus algorithms starting from the Byzantine Generals Problem (a generalization of the Two Generals' Problem).
• "Byzantine Fault Tolerance in Distributed Systems: A Literature Review" (2025) — DOI: 10.55677/craj/03-2025-vol02i07 — Excessive communication overhead in early BFT, secondary message complexity in PBFT, and trade-offs in asynchronous protocols.
• "Impossibility of distributed consensus with one faulty process," Journal of the ACM (1985) — DOI: 10.1145/3149.214121 — The possibility that even a single faulty process can prevent any consensus protocol from terminating in an asynchronous system (FLP). Solutions are known for the synchronous case.
• "Randomized protocols for asynchronous consensus" (2002) — arXiv:cs/0209014 — Four extension models circumventing FLP (randomness, timing assumptions, failure detectors, strong synchronization) and the history of randomized protocols. Preprint prior to peer review.
• "Consensus using Asynchronous Failure Detectors" (2015) — arXiv:1502.02538 — The precise mechanism by which a sufficiently powerful failure detector bypasses FLP. Preprint prior to peer review.
• "Threshold Logical Clocks for Asynchronous Distributed Coordination…" (2019) — arXiv:1907.07010 — Asynchronous consensus protocols are largely complex and inefficient, making practical applications rely on synchronous protocols. Preprint prior to peer review.
• "The Longest-Chain Protocol Under Random Delays," Stochastic Systems (2023) — DOI: 10.1287/stsy.2022.0031 — The problem where guarantees of the synchronous model degrade according to the maximum delay $\Delta$, and an alternative model treating delay as a probability distribution.
• "Byzantine Consensus in the Random Asynchronous Model" (2025) — arXiv:2502.09116 — Relaxing adversarial scheduling to random scheduling allows probabilistic guarantees that are impossible in standard asynchronous and partially synchronous models. Preprint prior to peer review.
• "On the (in)security of Proofs-of-Space based Longest-Chain Blockchains" (2025) — arXiv:2505.14891 — Nakamoto consensus uses PoW as a voting mechanism (assuming honest majority hash power). Proves that space-proof-based longest chains cannot be secure without additional assumptions. Preprint prior to peer review.
• "Stake Shift in Major Cryptocurrencies: An Empirical Study" (2020) — arXiv:2001.04187 — PoS prevents Sybil attacks by allocating roles based on the stake distribution recorded in the ledger. Empirical study of that distribution's lag (stake distribution lag). Preprint prior to peer review.
• "Blockchain without Waste: Proof-of-Stake," The Review of Financial Studies (2020) — DOI: 10.1093/rfs/hhaa075 — The first formal economic model of PoS. A restrained reward schedule yields a prompt consensus equilibrium and rules out persistent branching equilibria (due to the requirement that validators = stakeholders).
• "STAKESURE: Proof of Stake Mechanisms with Strong Cryptoeconomic Safety" (2024) — arXiv:2401.05797 — A framework separating attack costs from attack profits, along with a slashed-funds allocation insurance mechanism. Preprint prior to peer review.
• "An Event Study of the Ethereum Transition to Proof-of-Stake," Commodities (2023) — DOI: 10.3390/commodities2020006 — 99.98% reduction in energy consumption after the transition to PoS, with block intervals fixed at 12 seconds.
• "Bitcoin-Enhanced Proof-of-Stake Security: Possibilities and Impossibilities" (2022) — arXiv:2207.08392 — Long-range safety attacks, low liveness resilience, and bootstrapping difficulties are inherent to all PoS chains lacking an external trust root. Preprint prior to peer review.
• "SplitBFT: Improving BFT Safety Using Trusted Compartments" (2022) — arXiv:2205.08938 — Typically requires $3f+1$ nodes to tolerate $f$ faults under partial synchrony. Preprint prior to peer review.
• "Byzantine Fault-Tolerant Consensus Algorithms: A Survey," Electronics (2023) — DOI: 10.3390/electronics12183801 — A survey classifying BFT consensus algorithms from classical to state-of-the-art by their improvement methods.
• "Scalable byzantine fault tolerance via partial decentralization," Proceedings of the VLDB Endowment (2022) — DOI: 10.14778/3538598.3538599 — Decentralizing command replication while centralizing order determination. Achieves roughly 3x throughput and ~50% better latency across 300 regionally distributed replicas.
• "Zyzzyva," ACM SIGOPS Operating Systems Review (2007) — DOI: 10.1145/1323293.1294267 — Optimistic responses and speculative BFT without a 3-phase commit.
• "Mahi-Mahi: Low-Latency Asynchronous BFT DAG-Based Consensus" (2024) — arXiv:2410.08670 — Asynchronous BFT on an uncertified DAG achieving sub-second WAN latency and over 100,000 transactions per second. Preprint prior to peer review.
• "Strengthened Fault Tolerance in Byzantine Fault Tolerant Replication" (2021) — arXiv:2101.03715 — While Nakamoto consensus builds certainty the deeper a block is buried, BFT SMR has a fixed resistance threshold for committed blocks (core to finality contrasts). Preprint prior to peer review.
• "A Brief Study on Byzantine Fault Tolerance, Consensus, and Blockchain" (2023) — DOI: 10.54097/hset.v47i.8224 — The standard taxonomy dividing consensus into deterministic and probabilistic consensus; PBFT and HotStuff.
• "Ethereum Proof-of-Stake under Scrutiny" (2022) — arXiv:2210.16070 — A structure mixing BFT and Nakamoto styles. Safety holds, but liveness is guaranteed only probabilistically. Preprint prior to peer review.
• "Lemonshark: Asynchronous DAG-BFT With Early Finality" (2026) — arXiv:2604.03974 — Finding conditions under which safety is sufficiently guaranteed before official commitment, allowing early finality and up to a 65% reduction in latency. Preprint prior to peer review.
• "The Evaluation of a Double-Spend Attack Probability for Ouroboros-Like Proof-of-Stake Consensus" (2026) — DOI: 10.20944/preprints202604.0694.v1 — Closed-form expression for the double-spend success probability at finite confirmation depths. The required confirmation depth depends on the adversary's stake ratio. Preprint prior to peer review.
• "Defending Against Malicious Reorgs in Tezos Proof-of-Stake" (2020) — arXiv:2009.05413 — A 40% stakeholder can execute a 20-block reorganization roughly once a day, growing superlinearly above 40%, with attack opportunities knowable in advance. Preprint prior to peer review.
• "Proof-of-Work versus Proof-of-Stake: A Comparative Economic Analysis," The Review of Financial Studies (2025) — DOI: 10.1093/rfs/hhaf013 — Comparative equilibrium security model. Inserting actual parameters shows PoS is safer, with its advantage becoming prominent in large-scale chains.
• "Stabl: Blockchain Fault Tolerance" (2024) — arXiv:2409.13142 — Injecting faults into five modern blockchains. Except for one, they are heavily impacted by partial network failures, and some fail to recover from temporary faults. Preprint prior to peer review.
• "Formal Verification of Blockchain Byzantine Fault Tolerance" (2019) — arXiv:1909.07453 — Blockchain consensus is at best proven 'by hand'. Presents six vulnerabilities (including two new counterexamples) verified via model checker. Preprint prior to peer review.
• "Byzantine Fault Tolerance For Distributed Ledgers Revisited," Distributed Ledger Technologies: Research and Practice (2022) — DOI: 10.1145/3538227 — The gap between deployed BFT protocols and academic security models. Liveness fails even in synchronous networks in front of an adversary controlling delivery order.
• "The Blockchain Trilemma: A Formal Proof of the Inherent Trade-Offs…," Applied Sciences (2024) — DOI: 10.3390/app15010019 — Formalizing the three properties and arguing the contradiction of maximizing them simultaneously using proof by contradiction and computational complexity analysis.
• "Evolution of blockchain consensus algorithms," Cybersecurity (2023) — DOI: 10.1186/s42400-023-00163-y — A review of consensus algorithms from the perspective of energy efficiency, decentralization, and security trade-offs.
• "Sharding-Based Proof-of-Stake Blockchain Protocols…," Sensors (2023) — DOI: 10.3390/s23052819 — Components of sharding-based PoS and probabilistic security models. Roughly 4,000 years to failure with 4,000 nodes, 10 shards, and a 33% shard resistance threshold.
• "CoBRA: A Universal Strategyproof Confirmation Protocol…" (2025) — arXiv:2503.16783 — Mixed model of honest, Byzantine, and rational participants. If rational + Byzantine exceed 1/3 under partial synchrony, SMR is impossible. Preprint prior to peer review.