If there is a single takeaway from this article, then it should be that the field of cryptocurrencies is reviving the boring topic of database technology. We have always assumed the need to blindly trust an authority to manage and protect a database. But cryptocurrency has led to a paradigm shift as our community works on the pursuit to build a database that anyone can read, write and protect.

How this is achieved is very interesting and simple. In this article, we consider it through the lens of several computer science topics.

Perspective 1: Data structures and a cryptographic audit trail

Let’s consider a simple scenario. Bob, the honest baby, has a database with:

• Account balances,
• Smart contract code,
• Smart contract state.

It is conceivable that his database represents billions of dollars in assets. If Bob can tamper with the database, he can potentially siphon off millions of dollars.

To protect the assets, Alice the Inspector is periodically hired to audit Bob’s database and check the content is correct. But this raises the question, how can Alice audit the database?

Direct access to the database. The simplest approach is for Bob to provide Alice access to his database. Of course, while she can review the database content, she lacks the historical transaction records required to independently check why the database is indeed in this state.

Copy of historical transactions. If Alice can gain access to the database metadata or a historical list of all transactions, then she may be able to compute an exact copy of the database. She can simply compare her computed copy of the database with Bob’s copy of the database. If they match up, then she can be convinced that all processed transactions were valid.

Feature unlocked: the blockchain.

This is really the only problem a blockchain solves. It is a cryptographic audit trial for recording a list of transactions and making it to convince others about the final ordering of the transactions.

For example, in Bitcoin’s blockchain, a new block of ordered transactions is produced every 10 minute sand the new block is appended to the chain of blocks.

Anyone with a copy of the blockchain can simply re-execute all transactions in order and recompute the same database as everyone else.

If we return back to our audit story, then Bob can simply provide Alice with a blockchain that will allow her to re-compute the database herself.

But how does Alice know this is indeed “the blockchain” and Bob didn’t just make it up on the spot?

Perspective 2: Distributed systems and global consensus

We need a way for Alice the Inspector to check that everyone has agreed this blockchain is indeed the one and only blockchain.

This agreement is the only goal of a consensus protocol:

• Consensus protocol: A set of computers want to reach agreement about a single decision (or data item).

For example, let’s assume we have two conflicting (and pending) transactions:

• Transaction 1a: Alice pays Bob 5 coins.
• Transaction 1b: Alice pays Caroline 5 coins.

It is the job of a consensus protocol to decide which transaction is confirmed and subsequently the other is rejected. All participants in the consensus protocol must reach the same agreement in a timely manner. However, this leads to a fundamental trade-off when designing a consensus protocol:

• Safety: All computers should agree and never forget the decision.
• Liveness: The number of computers that must be online before a final decision can be reached.

Put another way, if at least X computers to agree on a single decision, then at least X computers must be online before a decision can be reached. The X represents our trust assumption for the consensus protocol. For example, many systems rely on an honest majority of computers to reach agreement before it is considered final.

Classical consensus protocols

For the past 30 years, the design of consensus protocols has focused on:

• Closed group. Appointing a fixed number of authorities to participate in the protocol.
• Safety and fork-avoidance. Once a decision is made, it should be impossible to reverse.
• No financial incentive. An authority does not expect financial upside by participating in the consensus protocol.

Generally, this type of protocol is deployed to a set of computers in a warehouse as the backbone of a Web2 service, this focus makes sense. The service provider just wants to guarantee consistency of their database while serving traffic to the public.

Byzantine Nodes

In blockchains, we are only concerned with classical consensus protocols that attempt to solve the Byzantine General’s Problem, where all computers reach agreement on a single decision in the presence of malicious computers. If a computer is faulty or malicious, it is still considered Byzantine as its actions can disturb the consensus protocol’s outcome.

Byzantine node: A node that will act against the interest of all other nodes. Its job is to stall progression or to confuse nodes about the final decision. They are not good cats.

Tom Scott has a nice video about the Byzantine General’s problem. The existence of malicious nodes has led to researchers and developers focusing on safety over liveness. Guaranteeing that a malicious node cannot confuse others about the final decision reached.

To protect against this problem, a consensus protocol must assume N = 3f + 1, where N is the minimum number of participating nodes and f is the maximum number of faulty nodes. In other words, a super majority of appointed authorities must be online and honest to guarantee that all honest nodes will agree upon a single decision.

Nakamoto consensus protocols

As we just discussed, the goal of a classical consensus protocol was safety. If a decision was reached, then it can never be reversed. The fundamental paradigm shift by Satoshi Nakamoto was to prioritise liveness over safety. His design ensures the system remains alive and continues to make progress, even if there is a chance that a decision can be reversed or changed in the short-term future.

By prioritising liveness over safety, it has led to some interesting properties:

• Open group. Any computer, who is willing to commit resources, can participate in the protocol.
• Fork-tolerant and eventual consistency. The set of recent decisions can be reversed, but the final set of decisions will eventually be confirmed as final.
• Financial incentive. It should be profitable for computers to partake in the consensus protocol (and spend resources doing so).

The fact that any computer, who is willing to spend the resources to do so, can participate in the consensus protocol is at the heart of censorship-resistance.

For example, the Chinese government recently shut down Bitcoin mining operations which represented over 50% of decision-making power. Even with this backdrop, the Bitcoin network continued to make progress as a simple majority of computers outside of China continued to honestly follow the consensus protocol.

Why did Bitcoin continue to thrive? We need to consider the safety and liveness guarantees provided by Nakamoto consensus:

• 99% of computers can be offline, but the consensus protocol progresses (liveness). Decisions will always be reached as long as 51% of computers, whom are online and participating, follow the consensus protocol.
• 51% of all computers to confirm decisions (safety). A decision will eventually be confirmed as final as long as 51% of computers who participate in the consensus protocol (online and offline) will eventually accept it.

Because the Chinese government only shut down the Bitcoin mining operations and did not run it with malicious software, then the machines were considered offline. Thus, the online computers could simply continue making decisions and progress.

OK, but, what does this actually give us? Nakamoto consensus is a mechanism to allow any computer to identify the one and true blockchain. If a computer can get a copy of this blockchain, then it can compute the same database as everyone else. It allows us to effectively replicate a single database across the globe.

Perspective 3: Applications and trust engineering

Conceptually, we can consider a cryptocurrency network as a public bulletin board. It guarantees eventual consistency of data to computers globally. In other words, anyone can read and pay to have write access to the database.

What can we build?

• Bitcoin. A peer-to-peer electronic cash system.
• Ethereum. A platform to instantiate and execute programs (i.e., smart contracts)

Over the years, we have witnessed the rise of several applications including payments, store of value, auctions, e-voting, token issuance, trading assets and gambling.

But this begs the question, why do developers decide to build applications on top of a cryptocurrency as opposed to an SQL database?

“The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.” - Satoshi Nakamoto (2009)

The reason can be found in the announcement of the Bitcoin software by Satoshi Nakamoto. Crypto does not compete on speed or financial cost. Instead, it competes on trust:

Trust engineering is the discipline of defining the components of a protocol that require human trust to function and replacing it with an executable program.

Human trust is friction and slows the progression of an application. Not only is it a single point of failure and the source of all rug-pulls, but it requires the application to implement safe-guards, audits and regulation to convince others that the application is being run correctly (and to protect other applications from its output). Worse of all, issues are often only detected long after the fact.

Our goal with trust engineering is to minimise human trust and ultimately impact of its friction. By replacing human trust with an executable program that is publicly publicly verifiable, then entire classes of mistakes can be ruled out as anyone can verify the program was run correctly and its output is correct. Clearly, this streamlines the execution of an application as machines replace humans as auditors.

It has allowed the wider community to build:

• Auctions without auctioneers,
• E-voting without tallying authorities,
• Gambling without casinos,
• Trading without brokers,
• Art speculation without auction houses.

This is indeed the true innovation underpinning crypto and Web3.

Perspective 4: Largest bug bounties in the world

Smart contracts are often less than a few hundred lines of code, but have custody over billions of dollars worth of assets (and tokens). Missing a single line of code can result the theft of millions of dollars being stolen by a pseudonymous thief. In fact, it is arguable that a new multi-million dollar heist occurs approximately every 2 weeks.

Why are there so many heists? In my view, implementing a smart contract is like programming Satan’s computer. The smart contract is immutable once it is deployed and it must survive in what is arguably the most adversarial environment imaginable. If the smart contract can survive in the wild, then we can eventually consider it fit for purpose.

An attacker can read the code, pay to execute the code, and front-run (to interfere with) the execution of other parties.

What if I don’t work on smart contracts directly? There are still plenty of attack surfaces even if you are not working with the smart contracts directly.

The classic example is the cryptocurrency exchange. If an attacker can get access to the cryptographic credentials that custodies all the funds held by an exchange, then they can easily swoop the funds away. This risk remains real today as Coinbase purportedly custodies around 11% of all crypto assets which is a truly valuable honey pot.

Swooping the funds away is not an uncommon event. The largest heist in history was MtGox (2014). This thief escaped with around 850k bitcoins which represented ~14% of all bitcoins in circulation at the time. Kim Nilsson has a fantastic breakdown of the heist which remains my favourite talk. By March 2015, up to 33% of all Bitcoin exchanges had been hacked too.

How lucrative are the bug bounties? In the past year, the largest bounty was issued by the Polygon project. They paid $2m to a white hat hacker for disclosing a critical vulnerability. There isn’t much to say here except that crypto has mega bug bounties where finding a single bug can pay more than an entire life-time of employment.

I hope you are now excited about the world of cryptocurrencies.