Preface
The last two year has been incredibly exciting to us. We launched a new security company, started offering audits and consulting services, and even smashed a few audit competitions.
Amid all the opportunities—and the chaos—of growing a business, we never lost sight of our roots as security researchers. We’ve consistently carved out time to chase down truly foundational vulnerabilities and explore new research directions.
This blog series showcases one of those research threads. This first post serves as a primer, giving readers the background needed to understand the bugs we’ve uncovered. Give us 15 minutes, and you’ll walk away with answers to these questions:
- What really is a blockchain?
- How does its foundational component—consensus—actually work?
- Why is it safe, and under what assumptions?
What is a Blockchain?
As more and more projects race to build their own blockchains, each claiming more "features" than the last, it is easy to lose sight of what a blockchain fundamentally is. At its core, a blockchain is simply a distributed database, where a set of validators collaborate to behave like a single logical computer.
These validators must operate in a potentially hostile environment: messages may be delayed, network partitions may occur, and a subset of validators might be compromised or deviate arbitrarily from the protocol. Yet, despite these challenges, all honest validators must agree on a shared state of the database (safety) and continue processing transactions (liveness). These two properties—safety and liveness—form the backbone of any blockchain consensus system.
Despite being so fundamental, consensus receives surprisingly little attention in security research outside of academia. We suspect this is partly due to the steep learning curve and the substantial prerequisite knowledge required to understand these protocols. Additionally, from a practical perspective, other areas of blockchain security, such as smart contracts, are often seen as having a higher return on investment for bounty hunters.
At Anatomist Security, we embrace challenges others shy away from. In this blog series, we'll walk through how we broke several state-of-the-art consensus algorithms used by well known blockchains. Hopefully this will serve both as a cautionary tale for developers considering building their own, and as a primer for security researchers looking to enter the world of consensus.
Concepts
What is Consensus?
What exactly are the two requirements, safety and liveness, mentioned earlier?
Safety
Safety ensures that nothing bad happens. More formally, it means:
- Agreement: If any honest validator accepts (or in blockchain terms, finalizes) a block, all honest validators must eventually accept the same block.
- Total Order: All validators must agree on the exact order in which blocks are processed.
Together, these properties guarantee consistency: if every validator applies the same deterministic operations to the same ordered set of inputs, they will all reach the same final state in their local copy of the database.
Liveness
Safety can be achieved simply by ignoring all inputs and doing absolutely nothing. Of course, that's not useful at all. This is where liveness comes in, requiring that something good must eventually happen. In formal terms, this means:
- As long as users continue submitting new requests, validators must process and deliver them within a bounded time. This "time" is typically measured in terms of the total amount of messages delivered by honest nodes, and "bounded" often means there’s a polynomial upper limit relative to the number of validators.
Combining safety and liveness gives us what consensus aims for: a system that is both consistent and available to serve new requests. Exactly what a distributed database, or a blockchain, needs.
In most blockchain designs, safety is prioritized over liveness. When facing a crisis, it’s generally better for a blockchain to halt entirely and await human intervention rather than risk illegal behavior such as double-spending. Of course, some oddballs defy this conventional wisdom (looking at you... Ethereum), but that’s a story for another day.
Network Assumptions
When dealing with distributed systems, it's also important to understand the communication / network model used. There are 4 types of network models:
Synchronous Network
A Synchronous Network implies messages between honest validators will be received within a known delay
Asynchronous Network
At the other extreme, Asynchronous Networks guarantee only that messages between honest validators will eventually be delivered. No assumptions are made about how long delivery might take, only that no messages will be dropped. This model reflects real-world networks more accurately but comes at a cost: consensus protocols in this model typically suffer from higher latency.
Partially Synchronous Network
Partially Synchronous Network is a compromise between the previous two models. The networks starts off asynchronous, but after some unknown global stabilization time (
This is the most common assumption of consensus algorithms used in production blockchains. It is also the setup we'll be working with in this blogpost.
Partitioned Network
The last setup is Partitioned Networks, where messages between validators may be dropped completely. It has been proven that satisfying both safety and liveness is impossible when the network is partitioned. This makes sense: if communication between honest validators is completely cut off, there is no way for them to know what input each other delivers. Hence, the only way to maintain safety is to not deliver anything, thereby sacrificing liveness. Therefore, no consensus algorithms are designed for partitioned networks.
Byzantine Fault Tolerant Algorithms
Byzantine Fault Tolerant (BFT) algorithms are a class of algorithms that are designed to achieve consensus in the presence of arbitrarily behaving validators. This line of research started with the famous The Byzantine Generals Problem paper, which shown that consensus is only possible when
The most common ways to classify modern BFT algorithms are by:
- Network setup (Asynchronous vs. Partially Synchronous)
- Structure (Chain-Based vs. DAG-Based)
Together, these categories form the landscape in which modern blockchain consensus protocols are designed and evaluated.
Quorum Intersection
Different consensus algorithms rely on different lemmas to prove their safety and liveness. However, there is one theorem, quorum intersection, that underlies almost all security proofs.
Formally, quorum intersection can be defined as:
Under the BFT assumptions, any two supermajority set (
) of voting powers must intersect on at least one unit of voting power controlled by an honest validator
This theorem can be proven by contradiction:
-
In a standard BFT assumption, only
of the total voting power can be byzantine. With the total voting power , at most is byzantine -
For two supermajority sets to exist, each must have support from at least
voting power. Even assuming all Byzantine validators contribute to both sets, each supermajority set must still include at least of honest voting power -
For the two supermajority set to not intersect, the honest voting power in the two supermajority set must have nothing in common. The minimum total amount of honest voting power required would be make this possible is
-
However, expanding the formula shows the amount of voting power required from honest validators (
) is greater than the total voting power among honest validators ( ): -
This results in a contradiction, and proves that any two supermajority set of voting powers must intersect on at least one unit of honest voting power.
Stay Tuned
And that's it! You now understand what a blockchain really is, how consensus works, and why it’s safe.
Now that these core ideas are out of the way, you’re ready to explore the fascinating world of consensus algorithms. Stick around—our next posts will break down the real consensus vulnerabilities we uncovered. If you found this valuable, follow us on X. We’ve got plenty more interesting content coming.