What Is This All About? introduced the idea of Trust and Authority. We described how Bitcoin creates a trustworthy digital bank, and how Ethereum is creating a trustworthy global computer that can perform general computations. Yet, we closed the chapter by acknowledging that there are limitations to this model. In this chapter, we will learn what those limitations are. But first, let’s establish a mental model for how an Authority works.
State and Mutation
Most authorities can be abstracted as two functions: they hold value-bearing and (often contentious) state (information), and they perform mutations (updates) upon that state based on a well-known set of rules.
flowchart Authority subgraph Mutations Rules end State Authority --> State Authority --> Mutations
In the example of Bitcoin, the state of the authority is the list of all accounts and their BTC balances, and the mutations are transfers of BTC between two accounts1. The rules state that no one can spend more BTC than they own.
Digital and Real-World
Another property of authorities is whether the state and its mutations are in the real world or the digital world.
flowchart Auth[Authority] --> RW[Real World] Auth --> Digital[Digital World]
Banking (excluding cash) and many similar financial services in the modern day are examples of authorities that are purely digital. The state is a database holding everyone’s balance, which is merely a set of numbers in a computer. Updating one’s balance is as simple as updating one of these numbers.
Conversely, the land registry is a real-world form of authority. Such an authority needs to be able to know if a land exists, who owns it, and crucially, enforce the ownership of it through some law enforcement means, if need be.
Oracle Problem
The often overlooked reality is: blockchains are obviously digital systems. For a digital system, inspection of and updating the real world is (nearly) impossible to do independently. This difficulty, specifically when it comes to reading information from the real world, is referred to as the Oracle Problem.
flowchart DS[Digital System] --"write ❌"--> RW[Real World] --"read ❌"--> DS
As an example, a digital authority like Bitcoin has no practical way to independently understand if a piece of land exists, and to whom it belongs. Moreover, Bitcoin cannot meaningfully enforce that “Alice should from now on own this land that formerly belonged to Bob”. Sure, it can create a digital piece of data that says so, but so long as it is not enforced in the real world, it is meaningless.
Contrary, Bitcoin has full independent authority, with both read and write permission, over its own digital token BTC. To transfer BTC tokens from Alice to Bob, Bitcoin is operating over its sphere of authority.
This is why real-world authorities are backed by some form of law enforcement unit, such as the police and military, as noted in What Is This All About?. No blockchain-based system yet has a real-world law enforcement body behind it2
The Weakest Link
This is NOT to say that no blockchain-based system should attempt to tackle any real-world use-case. But we should acknowledge that there is a high chance of creating a system with a single point of failure here.
Very often, such systems combine a blockchain and its science-based trust with a human-based authority that conveys the existence of real-world information to and from the blockchain, and this human-based authority is exactly the single point of failure. This design might suffer from the Weakest Link issue.
Trustlessness Can Be a Spectrum
Another, more open-minded way to look at the Weakest Link issue is that systems that have this weakest link (for example, tokenization of real-world assets on a blockchain) are not inheriting the full properties of a Trustless blockchain-based system, but are rather selecting a subset of it. And that is fine, as long as we are aware of it.
In the case of tokenization of real-world assets on a blockchain platform like Ethereum, the system can simply not provide the verifiability that a decentralized exchange between ETH and BTC has. This is because of the oracle that needs to be trusted to bridge these real-world assets to the blockchain. But it still benefits from the partial verifiability, accessibility, and auditability that a Trustless system provides.
Opinion
What I often dislike is that this weakness is not acknowledged in all the hype-driven marketing material of such projects. I would run away from teams, founders, and companies that are operating on a system that has Oracles as a weakest link, but fail to articulate it.
Summary
Any Authority’s role is to establish Trust. Blockchains are systems that yield science-based trust, which is paradoxically called Trustless, because it is free of human-based trust. An authority typically needs to hold some (contentious) state and perform mutations on top of it based on a clear set of rules. This state is either in the real world or the digital world.
Digital state is a great fit for blockchains, since it can be easily read and mutated by the same system. Real-world matters are more difficult, due to the Oracle Problem, but it can be done. At the end of the day, the Trustlessness of Ethereum managing the transfer of the ETH token (a purely digital contentious state that it can fully read and write) is fundamentally different from an Ethereum Smart Contract managing tokenized real-world assets.
While we can strive to solve the Oracle Problem in a Trustless manner, turning a blind eye to it is defying the whole purpose of why the Web3 industry exists, and why it managed to attract so many early adopters.
Footnotes
-
With some simplification, Bitcoin actually doesn’t use an account model but rather a UTXO system. ↩
-
The Network State book proposes steps through which digital authorities can evolve into gaining legitimacy in the real world, which is very much related to the enforcement issues mentioned above. ↩