Wait, Why Do We Need Consensus Again?

For centuries, the Earth was the center of the universe. The sun, stars, and planets all revolved around us. Courageous thinkers shattered this geocentric model by unveiling the heliocentric reality that revolutionized astronomy.

Like the world of astronomy, the blockchain world has its own long-held misconception: that consensus is necessary to build decentralized payments. Bitcoin and Ethereum have lied to us.

Decentralized currencies require a solution to decentralized consensus.
‍
—Ethereum Whitepaper, 2014

‍Consensus is actually the enemy. By removing consensus, we can finalize transactions as quickly as doing a Google search.

Consensus and the Conundrums

Meet evil Eve. She saved up Bitcoin to buy her first Tesla. Both Bob and Charlie run separate Tesla dealerships.

Is it sufficient for Eve to sign a message stating she is transferring money to Bob without recording it on-chain? Bob receives Eve’s signed payment but does not feel comfortable handing her the car keys yet. How can Bob be sure that Eve has not signed a conflicting transaction that pays Charlie, double spending the same money?

‍

‍

This is where blockchains come in. They solve the double-spending problem using consensus. Consensus takes transactions as input and outputs them in some global order that everyone agrees on.

‍

Back to Eve. Call $\text{tx}_1$ her payment to Bob and $\text{tx}_2$ her payment to Charlie. Bob sees $\text{tx}_1$ first, and $\text{tx}_2$ after; Charlie sees $\text{tx}_2$ first, and $\text{tx}_1$ after. Through consensus, granted to them by the blockchain, Charlie and Bob agree on the same transaction order, say that $\text{tx}_1$ happened first and $\text{tx}_2$ second. They only consider the first of the two transactions valid.

Let's look inside this giant black box called consensus. In a network with just a single party, achieving consensus is trivial: The party simply outputs transactions in the order she received them. But in a network with two or more parties, discrepancies in network conditions will result in transactions being received in a different order. On top of that, malicious parties can intentionally present conflicting views or introduce network delays. So, how do we agree on a global order?

We could use a centralized bank to order all transactions. Since we don’t want to rely on any trusted intermediary, we instead select a group of parties known as validators, and assume that more than two-thirds of them are honest.

Validators reach consensus through multiple rounds of communication, playing "he-said-she-said". Every once in a while, a leader is randomly selected to propose a global order by placing pending transactions into a block they sign. The rest of the validators vote on the leader’s block. A block with signatures from two-thirds of the validators is considered notarized. A malicious leader may selectively censor transactions, or even fail to create a block altogether, forcing the process to start over. Repeating this iterative process multiple times allows everyone to eventually converge on the same order. Consensus is slow.

In contrast, web apps need a single round trip—the client sends an HTTP request, the server returns an HTTP response.

‍

Do We Need Total Ordering?

Let's pause and reconsider: Does every transaction need to be part of a global order?

Suppose two payment transactions are made: Alice pays Bob, and Charlie pays Dave. Since these two payments are independent, they can be executed in any order. They commute: It doesn’t matter whether they are executed one way or another; the resulting state remains the same.

‍

‍

What happens when Eve tries to double-spend? We saw how consensus can solve this—but can we do without the latency overhead?

Here’s how. Similar to consensus, we begin with a set of validators, more than two-thirds of whom are honest. Instead of having validators agree on a global order, they vouch for valid transactions they receive—based on their local view—by signing them. Bob and Charlie will now only accept Eve’s car payment if more than two-thirds of the validators have vouched for it.

Eve tries to send two conflicting transactions to the validators. First, she has the dishonest validators sign both transactions. Then, she splits honest validators into two groups of one-third each, sending one transaction to each group. But Eve cannot gather sufficient signatures for both transactions to perform a double-spending attack.

More formally, suppose we have a distributed network with $n$ validators, out of which less than one-third of them are malicious. The protocol is simple:

Honest user: broadcasts a new transaction to all validators and considers the transaction finalized after receiving signatures from more than two-thirds, referred to as a certificate.

Honest validator: maintains a local list of unspent coins and only signs the first valid transaction that tries to spend a given coin.

Receiving a certificate for two transactions that spend the same coin requires more than one-third of the validators equivocating. With some extra machinery, this construction also works in the account-based model.

This consensusless protocol requires no communication between validators and only a single network round trip! Such constructions are actually well-studied in the blockchain literature. The base primitive enabling such constructions is referred to as consistent broadcast in the distributed systems literature.

Is there a catch? When Eve tries to double-spend, consensus will globally order her transactions, and only the first of the two will be accepted. In protocols like the one described above, there is no guarantee that either of Eve’s transactions will ever finalize. Eve’s account might even be bricked forever, since we don’t have to provide any guarantees to adversaries.

So, Why Do We Need Consensus Again?

We don't.

Beyond payments, "bag" or common subset protocols (e.g., on-chain auctions, voting, limit orders), append-only feeds (decentralized socials, notarization), and protocols that can be expressed as a conflict-free replicated data type (social graphs, reputation systems, games) can operate without global ordering. Many order-dependent DeFi protocols that are live today can be augmented to work without global ordering.

pod removes consensus from the equation to enable decentralized systems that are as fast as a Google search and as secure as Bitcoin.

Fasten your seatbelts, and hop on your pod. We’re about to embark on a journey around the sun.

Acknowledgements

We thank Noah Citron, Guy Wuollet, Bernardo David, and Wei Dai for their valuable feedback.

References

1. pod Research Paper — To be submitted to FC25
2. Certificate Transparency (RFC 6962): https://datatracker.ietf.org/doc/html/rfc6962
3. ABC: Asynchronous Blockchain Without Consensus: https://arxiv.org/pdf/1909.10926
4. The Consensus Number of a Cryptocurrency: https://arxiv.org/pdf/1906.05574‍
5. Sui Lutris: A Blockchain Combining Broadcast and Consensus: https://arxiv.org/pdf/2310.18042
6. FastPay: High-Performance Byzantine Fault Tolerant Settlement: https://arxiv.org/pdf/2003.11506
7. Timeliness: On-Chain Timestamps Are Accurate: https://eprint.iacr.org/2023/1648.pdf
8. Groundhog: Linearly-Scalable Smart Contracting via Commutative Transaction Semantics: https://arxiv.org/pdf/2404.03201
9. Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities: https://arxiv.org/pdf/1809.09044
10. Introduction to Reliable and Secure Distributed Programming: https://www.distributedprogramming.net/