Blockchain Alternatives

Published in

The Startup

8 min readApr 10, 2018

The Right Tool for the Job

This post is co-authored with Alistair Pott. The views expressed are our own and do not necessarily represent the views of our employer.

Introduction

In What Are Blockchains Actually Good For?, we explored the benefits of blockchains and proposed a simple framework for evaluating suggested use cases:

Does the system require tracking a global state?
Is decentralization being used for censorship resistance or system adoption, and does it make a meaningful difference on those fronts?
Is the minimum necessary level of decentralization being implemented?

This piece explores the third question further: when we need to protect against the risks of centralized systems, what are the tools available to us, and which ones should we use?

The risks of centralization

We go into the benefits of decentralization in more detail in the previous piece. For our current purposes, we’ll simplify and use the term “cheating” to mean all types of bad behavior associated with centralization, whether that’s censorship or other improper behavior on the part of the system administrator. Examples include:

Censoring or banning users of the system
Charging unreasonably high fees for use of the system (rent seeking)
Changing the rules of the system (e.g. start charging a fee)
Lying or otherwise intentionally tampering with data
Making mistakes, being hacked, or going out of business

Any highly centralized system faces such risks, and reducing those risks makes the system more robust and attractive to potential participants. This is a highly worthwhile goal. The question is, how do we do it?

Decentralizing the system (or key parts of it) is one obvious risk mitigation strategy, but it’s generally expensive in terms of system complexity and efficiency. At the extreme end of decentralization, blockchains provide maximum protection against centralization risks but also incur significant complexity, inefficiency, and economic waste. While the current excitement around blockchains leads many to believe that mitigation of centralization risks simply means “decentralize as much as possible” and therefore “use a blockchain,” in fact there are many alternative tools available. Often these tools will get the job done much more efficiently.

We categorize these tools into three buckets: preventing cheating, catching cheating, and recovering from cheating. We look at each of these in turn, then attempt to synthesize them into a framework for evaluating which ones to use.

Preventing cheating

We start with tools to prevent cheating in the first place. Note that tools considered later, which can catch cheating and help recover from cheating, also have the added benefit of reducing the incentives to cheat in the first place.

Penalties

Simple mechanisms to penalize cheaters can help dissuade cheating. For example we could require a deposit from each participant that is forfeited if they are found to cheat.

Another approach is having participants make highly public commitments not to cheat. For example, a platform administrator could publicly promise never to charge a fee, which would make doing so later very painful.

Neutral third party

To some degree we can prevent cheating by having a neutral third party administer the system. For example, companies that don’t entirely trust each other often hire an independent company, which has no stake in the system, as the system administrator. Of course, the centralization risk associated with the neutral third party must also be managed, but this is often relatively low.

Catching cheating

In many systems, it is sufficient to know when cheating occurs, since (a) a badly behaved party can be ignored and/or sanctioned, and (b) identifying cheating can allow for recovery. Also, the cheater often stands to lose enough from such an incident that visibility of cheating itself is a sufficient disincentive to cheat. Thus, catching cheating helps to prevent it in the first place. In order to catch cheating, we depend on qualities like verifiability, transparency, and auditing.

Digital signatures

Asymmetric (aka public key) cryptography allows us to create digital signatures that prove the integrity and sender of a digital message, making it impossible to tamper with or disown the message later. This is an extremely valuable tool that we believe is underappreciated by system designers.

For example, we could require a signed digital receipt upon storing some information in the system. If the information somehow disappeared later, we could pull out the receipt as proof that the system administrator received the information and was not behaving properly.

Similarly, we can require a message be signed by a trusted party before we act on it, which allows us to catch any attempted cheating before it does damage.

Verifiable data structures

A Merkle (aka hash) tree is a binary tree where the leaves represent the data set and each internal node is a hash built from its children. The whole data set can be represented by a single hash, and we can efficiently prove that a specific piece of data is in the tree and that nothing has been removed.

This allows us to build transparent, provably append-only data structures. These verifiable data structures can be used to make a centralized database fully transparent and auditable, so any cheating can be quickly caught. For example, Certificate Transparency uses Merkle trees to ensure that certificates are properly stored and never deleted or tampered with. If any cheating happens, it will be visible to all participants in the network.

Merkle tree-based systems can be far more efficient than fully decentralized systems like blockchains. For example, Trillian is an open source Merkle tree system that can process on the order of thousands of transactions per second per instance (compared to single digit transactions per second for the entire Bitcoin network).

Validators

We can increase the chance of catching cheating by enabling validating participants who are constantly watching for cheating and able to sound the alarm. The more independent validators the system has, the more likely we are to catch cheating.

Recovering from cheating

Well-designed systems can also mitigate the risk of cheating with mechanisms to recover from it effectively when it does occur. Tools in this category reduce the damage to the system. They also make cheating less likely in the first place, because prospective cheaters knows that cheating is (relatively) ineffective.

Fault tolerance

Adding redundancy to the system (e.g. multiple participants operate the database) and using a consensus algorithm to ensure cohesion can provide resilience against cheating.

It is not necessary to require unlimited redundancy — just enough such that cheating requires the compromise of several independent participants. It is also not necessary that fault tolerance is automatic. In cases where cheating is rare, even a heavyweight mechanism for recovery, such as manual reconciliation, may be sufficient.

Unauthenticated participants

An extreme form of fault tolerance opens the system up to unauthenticated participants. This can potentially increase the number and independence of participants to a point where it is infeasible for participants to collaborate to cheat effectively.

This level of decentralization is newly possible thanks to blockchains, which introduce economic incentives for participants to behave properly through proof-of-work or other consensus mechanisms. It comes with significant additional costs and complexity, but in exchange makes cheating extremely difficult. For example, you can theoretically mount a 51% attack on Bitcoin, but to do so you would need to muster a tremendous amount of computing power (about 13 exahashes per second currently).

Expel cheaters

The ability to expel cheaters from a system is both a disincentive to cheating and allows for the system to insulate itself from further bad behavior. Setting up mechanisms for expulsion generally requires both fault tolerance and some governance mechanism to trigger expulsion.

Open source data/code

Open sourcing the software and data on which the system operates makes it easy for participants to fork and leave the cheat behind. This is a valuable approach when there are no mechanisms for expelling the cheating party. The threat of such an outcome is often enough to align incentives and prevent cheating in the first place. It should be noted that if only parts of the system are open sourced and vital components of the system remain closed, then this approach offers very little practical protection.

How much decentralization is enough?

To overly simplify, we can broadly consider three levels of decentralization: centralized, partially decentralized, and fully decentralized systems. Moving from one level to the next provides additional protections by allowing us to use more of the tools discussed above, but comes with added cost and complexity. By considering which tools are actually needed to mitigate centralization risks, we can choose the best system design for our needs.

Centralized system

The simplest, most efficient architecture is a centralized database. This obviously implies centralization risks, but there are tools available to us for mitigating those risks:

Digital signatures can make it impossible to forge data or lie about events later
Verifiable data structures can make data transparent and immutable
Adding validators can increase the chance of catching cheating
Open sourcing software and data can enable participants to leave the system at need
Penalties such escrowed funds or public commitments can increase cheating disincentives
Neutral third parties with strong governance rules can be trusted system administrators

Partially decentralized system

If the tools available to a centralized architecture are insufficient, decentralizing the system among several known participants can offer additional protections, at the cost of increased complexity:

Fault tolerance via consensus mechanisms provides resilience to cheating participants
Expelling cheaters improves system reliability over time

Fully decentralized system

Finally, if the above protections are still insufficient, we may consider fully decentralizing the system: opening it up to an unbounded number of unauthenticated participants. While this comes with significant additional costs and complexity, it may be worth it in cases where any level of centralization risk is unacceptable.

Allowing unauthenticated participants can make cheating infeasibly expensive

Conclusion

There are many techniques for mitigating system centralization risks, even in systems with a single administrator. We believe that many of these techniques are underappreciated, leading many to mistakenly assume that blockchains are the appropriate solution for any level of centralization risk.

While decentralization does offer some additional protections, it comes at the cost of increased complexity and inefficiency. Blockchains, which enable a previously unattainable level of decentralization, offer further protections, but with significantly greater associated costs.

We recommend system designers take a hard look at what combination of the tools discussed here will sufficiently mitigate centralization risks — and then select the simplest, most efficient (and, therefore, generally the least decentralized) system that can support those tools.