The blockchain, a distributed system, is resistant to breakdowns within the network. If a node or two experience connection loss, the other ones can pick up the slack. This has to be the case, given the statistical likelihood that any networked computer in a multi-server system will malfunction.

That isn’t to say that downtime comes without a cost, though. Something’s got to give, and the CAP theorem shows us the cost. 

But when it comes to the CAP theorem and the blockchain, this theory’s predictions don’t exactly hit the mark.

What is the CAP Theorem?

Firstly, what does C A P stand for? It’s an acronym for Consistency, Availability, and Partition Tolerance. As many sources will tell you, the CAP theorem states that a distributed system can only maintain two of those three characteristics.

In other words, when the network breaks—i.e., there’s no partition tolerance—a distributed system may only upkeep consistency or availability.

But as you’ll see here, this broadly used explanation isn’t wholly accurate. Let’s not get ahead of ourselves, though—we’ll start by breaking down the three elements of the database CAP theorem.

Consistency

Consistency describes a system’s ability to keep data across all nodes the same and up to date. In a consistent network, every node returns the same data upon the same query; this data is as current as possible, and it’s ordered sequentially.

Availability

A network with high availability always responds to client requests, even in the face of malfunctioning nodes. Of course, the nodes that are on the fritz may not respond, but the network remains available overall.

Partition Tolerance

Partition tolerance is a term that outlines a network’s resilience to the breakdown of individual servers. Ideally, a distributed system will keep chugging along even if many of its nodes lose connection and stop communicating.

CAP Vs ACID

CAP (Consistency, Availability, Partition Tolerance) and ACID (Atomicity, Consistency, Isolation, Durability) explain different ideas. Here is a quick delineation between CAP and ACID:

• CAP posits that distributed systems must sacrifice either consistency or availability when partition tolerance is lost


• ACID describes the attributes a transaction needs to be valid despite obstacles like errors or connection losses

Although they both examine behaviors during malfunctions, CAP and ACID clearly aren’t the same thing. Rather, ACID applies to database data, while CAP describes distributed networks.

ACID Consistency

There’s also the matter of consistency in both CAP and ACID. We’ve already gone over the “C” in the former, so let’s look at the “C” in the latter. 

ACID’s idea of consistency states that transactions must follow the constraints, cascades, or other rules of the database (e.g., a field being a number or a reference to another field). 

So ACID’s consistency isn’t about data being identical and updated across replicate nodes; it’s about data obeying rules during transactions. Meanwhile, CAP’s consistency comes closer to the concept of linearizability.

Traditional Distributed Solutions to the CAP Theorem

The implication of CAP is that there has to be a tradeoff between availability and consistency. Based on that idea, solutions have traditionally gone in one of two ways.

Availability and Partition Tolerance (AP)

AP systems conserve availability at the cost of consistency. So, the network will prioritize giving the user a response, even if that response is based on out-of-date data. This is tolerable in solutions that don’t need to feed users with the freshest data—so something like a social media page.

Consistency and Partition Tolerance (CP)

Networks operating on the CP model provide consistent data but aren’t always available. In case of connection loss, the system will show an error report and block users from accessing until the issue is fixed. Applications that deal with highly sensitive data, e.g., banking apps, can make good use of CP.

What About CA?

A consistent yet available distributed network could work given enough backup measures to protect against connection loss. However, by some interpretations of the definition, the CAP theorem requires the network to have partition tolerance. As such, it can't be CA without violating the premise, if you will.

CAP Theorem and the Blockchain: Finding the Weak Links in CAP

So how does the blockchain fit into the CAP paradigm?

Well, if we consider Bitcoin, it’s clearly tolerant to partitions, and it’s reliably available since you can trade BTC at any time. However, Bitcoin isn’t really consistent: transactions tend to take time to complete, and they can sometimes fail.

But this doesn’t paint an accurate picture of the blockchain—and this is where we start seeing the holes in the common understanding of the CAP theorem.

The problem with CAP has always been its oversimplification in “common parlance.” 

For one, “choosing two out of three” is a woefully common mindset when it comes to CAP. The truth is that neither availability nor consistency goes completely out the window. One of them reduces in potency, but they aren’t wholly discounted.

Moreover, CAP has fairly specific definitions for its terms. This has seemingly been lost to the public, which often uses its own understanding of the words in the acronym. Being used so haphazardly, CAP inevitably loses value.

In a nebulous, “colloquial” sense, CAP is a fine heuristic to help make broader design decisions. However, it lacks the nuance to describe the situation with distributed networks truly.

Blockchain and the Consistency Question

Many would tell you the blockchain loses consistency, using similar reasoning to the one a few paragraphs ago. But in practice, it does maintain consistency in partition scenarios. Consistency (as CAP defines it) is a part of the blockchain’s main selling points—immutability and all that—so you’d expect it to be consistent.

The important distinction is that blockchains like Bitcoin are eventually consistent. On-chain transactions are placed in a pool, awaiting to be committed to the ledger. This may take time, but the record eventually becomes consistent across nodes. The likelihood of a transaction rolling back goes down the more time passes and more blocks are added.

In the blockchain’s case, latency is the vital factor that CAP fails to consider. That’s why we would recommend viewing the blockchain through a PACELC (Partition Tolerance, Availability, Consistency; Else: Latency, Consistency) lens.

Conclusion

In the realm of decentralized communication and secure data management, Inery stands as a disruptor, challenging established norms encapsulated in the CAP theorem. Unlike the conventional belief that one must sacrifice either Consistency, Availability, or Partition Tolerance, Inery navigates these waters with finesse. As we delve into the nuances of blockchain intricacies, Inery offers a compelling narrative, a departure from the norm.

This is not just a conclusion; it's an invitation to join Inery in reshaping the dialogue on secure, efficient, and resilient communication. The exploration continues, and Inery leads the way, seamlessly blending technology and vision to redefine the landscape. Embrace the possibilities, elevate expectations, and embark on a journey with Inery into the unfolding era of decentralized excellence.