Blockchains Are Overrated

We have learned a fair bit about blockchains thus far. Moreover, we know by now that when we say blockchain, we actually mean a network of nodes that are all interconnected, and are utilizing various systems together to achieve what can ultimately be abstracted away as a (world) computer with Resilience. What were those properties again?

• Reliable
• Verifiable
• Accessible
• Auditable

This chapter will then revise these 4 properties and argues why blockchain systems can achieve them, based on the new information that we have learned thus far. Finally, we will see what role the data-structure known as a blockchain plays in this, which is unsurprisingly not very significant, ergo the name of this chapter.

How Blockchains Are Resilient

Reliable And Verifiable

• Blockchain systems ultimately have an $STF$. It declares what they are. In other words, what we should expect them to do. If the $STF$ says this is a DEX, then it is. If the $STF$ says it is a ponzi token, then it is a ponzi token. What blockchains achieve, is correct execution of that said $STF$.
• This is achieved through the rules of the Consensus Algorithm, incentivizing correct execution of $STF$ and slashing those who do otherwise. So we have this TEE-like, magic global computer, that will always execute its $STF$ no matter what , and it will do so correctly
• This correct execution of the $STF$ can be verified by anyone monitoring the network.
• This gives us the reliability and verifiability that we named as the first two properties of Science-based Trust.

Accessible

• Then, the above is of not much value of only a small group of (elite) poeple have access to it. Ideally, interacting with a blockchain system is accessible to anyone who has access to internet and consumer hardware.
• This is why we argued in the previous chapter that a blockchain that is served to the entire world via one gigantic RPC server in the control of one company is NOT ACCESSIBLE, and therefore NOT RESILIENT. Or at least, not fully.

Auditable History

• Suppose a blockchain has been launched a decade ago, similar to Ethereum around the time of writing.
• I can, using nothing more than a good internet, a large hard drive, and a few days of time, re-execute the entire history of Ethereum, and ensure that Ethereum has indeed been executing its $STF$ correctly in the last decade.
• While doing this, I can also know exactly in what order the previous transactions of Ethereum have mutated its state to reach the current state.

Now, with that out of the way, let’s see what role a blockchain exactly plays in this.

Blockchain’s Role

The starting scenario to understand the exact role of a blockchain is as follows: Imagine we have a known correct order of 5 transactions ($[t{x}_1,t{x}_2,t{x}_3]$, and $[t{x}_4,t{x}_5]$). Without any special means, how can a new participant append a $t{x}_6$, while preserving the order of all the previous transactions? Blockchain is an efficient means to solving this very problem.

A blockchain proposes to:

• Bundle all transactions that are being added, in the right order, into a single block of transactions
• Chain this new block to the previous one by putting a parent_hash field in its header.
• If all blocks do this, then the content of all blocks are made immutable because

Consider the following diagram, in which $bloc{k}_{n-2}$ is know with its 3 transactions, and $bloc{k}_{n-1}$ with 2. $bloc{k}_n$ is the new one that is meant to be added.

flowchart LR
    subgraph "Block N-2"
	    subgraph Body
		    direction LR
		    Tx1
		    Tx2
		    Tx3
		end 
	    subgraph Header
		    CurrentHash["current_hash: abc"]
		    ParentHash["parent_hash: xyz"]
	    end 
    end
    
    subgraph "Block N-1"
	    subgraph BodyN["Body"]
		    direction LR
		    Tx4
		    Tx5
		end 
	    subgraph HeaderN["Header"]
		    CurrentHashN["current_hash: def"]
		    ParentHashN["parent_hash: abc"]
	    end 
    end
    
    subgraph "Block N"
	    subgraph BodyNN["Body"]
		    direction LR
		    Tx6
		end 
	    subgraph HeaderNN["Header"]
		    CurrentHashNN["current_hash: hij"]
		    ParentHashNN["parent_hash: def"]
	    end 
    end
    Header --> HeaderN --> HeaderNN

• Now let’s walk backwards; $bloc{k}_n$ is referencing parent_hash: def in its header, so a digest of it is present in its current_hash: hij.
• This means any tampering in $bloc{k}_{n-1}$ will cause its hash to no longer be equal to def, breaking the chain of hashes.
• No notice that $bloc{k}_{n-1}$ is doing the exact same thing!
• This extends this immutability chain not just to the previous block, but all the way to genesis.
• In short, the hij in the above diagram, the hash of the latest block, is essentially a Commitment Hash to all of the previous blocks in a very efficient way, ensuring that any tampering in any of the previous blocks would be detected by breaking the chain of hashes.

So, what the blockchain data structure achieves here is twofold:

1. Assuming we have a large array of such blocks chained together, no previous block can be tampered with, or else the chain of valid hashes will break. This means no previous transaction can be added, removed, or modified 2. Any new block is committing to a specified parent, growing the blockchain only in one canonical chain.
2. The hash of the header of the latest block’s header is a Commitment Hash of all the previous blocks as well. This allows the blockchain to grow, without the need to always (re)hash all of the previous transactions/blocks.

Overrated?

So, let’s compare what part of How Blockchains Are Resilience Resilient is in the domain of Blockchain’s Role.

• Blockchain is NOT the technology that delivers verifiable/reliable execution, arguably the most magical property of blockchain systems. This is mainly achieved by the incentive mechanisms in the Consensus Algorithm¹.
• Blockchain is NOT The technology that makes the system accessible. This is achieved by leveraging light nodes, State Proofs, avoiding large RPC providers becoming the defacto user gateway, and keeping the hardware requirements of participating in the network within a reasonable limit, among other considerations. Contrary,
• Blockchain is part of the reason in blockchains we know what is the correct ordering of past events
• Consequently, Blockchain is part of reason we can audit the past events of the blockchain, by helping us know that this past events are correct.

Summary

A blockchain, as a data-structure, is an append-only list of transactions, with an easy way to ensure the history is not tampered with, mainly through chaining blocks of data together via the header’s parent hash mechanism explained above.

Summary: Means To an End

The true learning here is that blockchains are a means to an end. The goal is to create Resilience global computers and State Machines, capable of doing computation with properties of Science-based Trust, not being at the mercy of an Authority to uphold their promise of “not being evil”, but rather bering able to verify it.

Blockchain, as a data-structure contributes to this goal by giving us a system that allows the history to be audited in an efficient way.

Footnotes

1. or as we will learn much later, via Scaling Out - SNARKs. ↩