What Properties Do Blockchains Fundamentally Unlock? Blockchain as a PCP Machine: Protocol Adherence, Censorship Resistance, and Persistence

Let's cut the jargon and get into the specifics. What do blockchains fundamentally do differently?

Special thanks to Leo and Rhys for feedback and review.

Blockchains are sometimes presented as mystical creations, but the main significant thing about them is simple: they are digital substrates which unlock unprecedented levels of protocol adherence, censorship resistance, and persistence (PCP) guarantees for the software that they run. For some applications, these properties can prove very valuable. Here they are spelled out:

1. Protocol adherence: The guarantee that a software system is following a given protocol.

2. Censorship resistance: The guarantee that users can properly interact with a software system.

3. Persistence: The guarantee that a software system will continue running far into the future.

Those main seem intriguing, but what contributes to a digital substrates ability to guarantee them? The contributions mainly comes from two characteristics:

1. Trustlessness: The minimization of trust required from the human operators of a digital substrate for a given PCP property to be upheld.

2. Resiliency: The maximization of resiliency of a digital substrate to defend a given PCP property against attack from a third party.

With those terms out of the way, we can dig into an analysis of the two main digital substrates for running software: servers, and blockchains. Let’s take a look at each of them in turn to better understand how they compare in their PCP guarantees.

Servers

At a high level, a server is a single computer running software that people can interact with over the internet. Servers are what the internet is built on today. That being said, they don’t offer the strongest PCP guarantees:

1. Trustlessness: it’s necessary to trust that the operator of a server will uphold protocol adherence, censorship resistance, and persistence. At any moment the operator of a server could modify its behavior to breach its protocol, censor certain users, or terminate.

2. Resiliency: a software deployment is only as resilient as the operator of the server. At any moment they could get coerced by a third party into modifying the server’s behavior to breach the protocol, censor certain users, or terminate. Alternatively, it only takes a single hack to take control of the server, and a single explosive to destroy it.

Now that we’ve seen what servers are capable of, let’s see how blockchains compare.

Blockchains

At a high level, a blockchain is a network of servers that redundantly execute the same software and reach consensus on its status through a system of checks and balances. Part of its power lies in its inclusivity - anyone can contribute to the network by running a node without needing to ask anyone for permission. The idea of blockchain is to be the digital substrate which best maximizes PCP guarantees:¹

1. Trustlessness: Let’s break down this analysis into each of protocol adherence, censorship resistance, and persistence.

   1. Protocol adherence: every user has the ability to verify whether or not a blockchain is following a given protocol, so there’s no need to trust the operators of the blockchain to uphold protocol adherence.²

   2. Censorship resistance: as long as at least a few percent of the servers which make up a blockchain don’t try to censor a given transaction, it will not be censored. Coupling this with the fact that anyone can contribute to the operation of a blockchain by permissionlessly running a node, we find that blockchains are highly censorship resistant without needing to trust that any individual blockchain operator will uphold censorship resistance.

   3. Persistence: anybody can contribute to the operation of a blockchain, so there’s no need to trust that any individual blockchain operator will uphold persistence.

2. Resiliency: following from the trustlessness properties, there is no centralized point of failure that a third party can coerce, hack, or destroy to induce a blockchain to break from protocol adherence, censorship resistance, or persistence. Instead, the third party will need to coerce the users themselves to not interact with a given blockchain. This is much more difficult.

So What? When Does It Make Sense To Use a Blockchain?

Deciding between running software on a server or a blockchain comes down to a cost benefit analysis. The main advantage of using blockchain is its PCP guarantees, while its limitations include slower performance and weaker privacy capabilities (although these limitations are being eroded over time)³. In which applications are PCP guarantees actually valuable?

For the vast majority of applications, using a server is the better option. PCP guarantees are mainly important in cases where a significant conflict of interest appears between the operators of software and its users (trustlessness solves this), or when there are concerns of a third party interfering with software (resiliency solves this).

Today, conflicts of interests are typically solved via government regulation. In fintech apps for example, rather than trusting software operators to uphold PCP, you rely on a government to ensure that the software operators adequately follow PCP.

As far as concerns of a third party interfering with software goes, today, applications solve this by relying on a government to defend servers and punish those who try to interfere.

So what’s left? What types of applications does it make sense to deploy on a blockchain? We’ll answer this question in a future post. Subscribe for updates!

1. I don’t elaborate much on the specific implementation here. The goal of blockchain is to maximize PCP guarantees; the actual approach taken for getting there is not important as long as it achieves this goal. Vitalik’s Endgame article is a great resource for walking through a few drastically different approaches to achieving this end.

2. A common misconception is that a 51% attack could result in a blockchain failing to satisfy protocol adherence, but in fact this is not the case. Users continue to enforce protocol adherence in the event of a 51% attack. See this great article by Dankrad Feist for more.

3. Today, blockchains are very slow and are highly limited in their ability to run applications which rely on privacy. These are limitations of the current approach to implementing blockchains, but do not necessarily apply to all possible approaches to implementing blockchains. See footnote #1 for more.