Blockchain Reimagined

Blockchain-based Authorities

6 min read

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.

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 balance, and the mutations are transfers of BTC between two accounts1.

Digital and Real World

Another property of authorities is whether the state that they hold, and the mutations that are done upon it, 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 mean, 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 system, such as a Blockchain, has no practical way to independently understand if a piece of land exists, and to whom it belongs. Moreover, a digital system cannot meaningfully enforce that “Alice should from now on own this land that formerly belonged to Bob”. Sure, the system can create a digital piece of data that says so, but so long as it is not enforced in the real word, it is meaningless.

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.

Contrary, blockchains can effortlessly harvest their full Resilience on use-cases whose state is purely digital. This property demonstrates why Decentralized Finance (DeFi for short) is such a successful use-case for blockchains. Assuming a free and open internet3, DeFi requires no further foundation to operate upon.

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 to create 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:

Weakest Link

The strength of any chain is only as strong as its weakest link.

While a useful term in the industries that work with an actual chain, the analogy can be expanded to composite (digital) systems with interdependent constituents as well.

graph LR
	classDef smallNode font-size:10px
	C0[Strong Link] --> C1[Weak Link] --> C2[Strong Link]
	
	C1:::smallNode

The argument then is that the overall Resilience of a composite Authority is only as good as its weakest component.

Originally appearing in “Essays on the Intellectual Powers of Man”.

Link to original

Resilience 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-state on a blockchain, are not inheriting the full properties of a Resilience blockchain-based system, but are rather selecting a subset of it. And, that is fine, as long as we are aware of it.

For example, a tokenization of real-world-assets on a blockchain platform like Ethereum might not provide the reliability and verifiability in full, because of the oracle that needs be trusted to bridge these real-world-assets to the blockchain, But it still benefits from the accessibility and auditability that a Resilience 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. It clearly shows they don’t get it.

Summary

Any Authority’s role is to establish Trust. Blockchains are systems that yield Resilience science-based trust. An authority typically needs to hold some (contentious) state and perform mutations on top of it. 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 mutated by the same system. Real world matters are more difficult, due to the Oracle Problem, but it can be done. End of the day, the Resilience 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 Resilience manner, turning a blind eye to it will likely cause more damage than harm in the long run, as it is a single point of failure for a system.

Next

In the next chapter, Execution, Ordering, History and State Machines, we build on top of the 3 properties of blockchains that we know about:

  • State
  • Mutations + rules of mutations and present a more concrete mental model (💻) for blockchains.

Footnotes

  1. With some simplification, Bitcoin actually doesn’t use an account model but rather a UTXO system. ↩

  2. 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 issue mentioned above. ↩

  3. How accurate is this assumption of the internet being “free and open”? See here. ↩

Graph View

Backlinks