Web3 Surfers
Published in

Web3 Surfers

Crypto Cocktail Party : Blockchain Pt. 1.5

Know just enough about crypto to show off at a cocktail party

This is an intermediate article to tie up some loose ends in our previous analogy, and introduce, briefly, the idea of decentralization. A more detailed article on decentralization will (hopefully) soon follow.

Recap

Here’s where we left off in our last article.

You work at a bank. You have a spreadsheet recording every transaction that ever occurred. Simon buys a $3,000 mocha latte, then hires a hacker to revert that transaction. The hacker’s initial attempt is thwarted by your genius decision to include the hash of each block of data, as well as a reference to the hash of the block directly preceding it.

In short, you now have a series of data cryptographically linked together (i.e. using hashes), such that any attempt to modify a point in the chain would result in the entire chain — from that point onwards — breaking down.

Single Point of Failure

However, Simon’s hacker, as mentioned before, is a dedicated craftsman, and is willing to put in many hours to modify the entire chain. That is, she will go in and change Simon’s $3,000 purchase to simply $5, then rewrite the hash reference of each block afterwards, restoring all the broken links.

This is possible because regardless of how secure we make our spreadsheet, that spreadsheet is still a single point of failure. If that spreadsheet fails, all goes down with it.

Therefore, we can imagine that a dedicated hacker with tremendous computing power and equally astonishing willpower may very well be able to outrun the growing chain of transactions and modify data as she sees fit.

P2P Network

The solution for this is actually quite simple, as far as understanding it goes. We can distribute our spreadsheet across multiple machines (for our purposes, computers). We create a network of computers, called nodes, with each participating node holding on to their version of the spreadsheet.

In more sophisticated lingo, we are using a P2P (peer-to-peer) network as an additional safeguard for our spreadsheet. Computers participating in the network are talking to each other, performing tasks and sending and receiving data. Whereas previously, the data stored on your computer was the single source of truth (and therefore the single point of failure), now, information is distributed across an entire network of computers, which are constantly communicating with each other to synch up and cross-reference local data.

A Network of Computers (Wikipedia)

In other words: you have the spreadsheet, your parents have the spreadsheet, your uncle has the spreadsheet, your 3rd grade homeroom teacher has the spreadsheet. Each of them have the same synched-up version of the spreadsheet, i.e. the data in them are all the same. If a new transaction is added, then that information is propagated across the network, until all participating nodes are up to date.

With this design, let’s see what happens. Simon’s hacker dutifully hacks away at your spreadsheet, spending all her time changing a multitude of hashes. She finally emerges victorious, having relinked every single block of data…

Simon’s hacker counting the number of spreadsheets she needs to hack

…only to realize that there are now tens, thousands, millions of spreadsheets scattered across the globe, all containing the original transactions prior to the hack. Identifying and resolving the hack is now as simple as overwriting your spreadsheet with the majority version.

Whatever the hacker did to modify the data on our computer, she now has to do it many times over, all before some kind of misbehavior is detected and any change made is overwritten. Quite the impossible task, if ever there was one.

Outro: Decentralization

You may not see it yet, but we just got our first taste of decentralization, the panacea of the blockchain industry.

The bank, more specifically, the spreadsheet residing within the bank, used to be the single source of truth. Therefore, the bank was tasked with storing, verifying, and writing all transactional data. This is not surprising, given that these tasks go hand in hand: verification requires the storing of past data, and writing requires verification of the data that is to be written.

However, we have seen that, at the very least, the task of storing that data can be taken away from the central bank, and distributed across multiple arbitrary network participants. We have seen that this is actually beneficial in many ways, not least because a single source of truth can easily become a single source of failure.

But why not go further? Why not distribute the ability to verify and write into the database across that same P2P network? Why not bypass the middleman entirely, returning the concept of a transaction back to its more intuitive roots?

So far, we’ve been going with the hacker analogy, mostly because I did not plan out my analogies in advance. In reality, though, the benefit of making transactions entirely peer-to-peer goes far beyond that of foolproof hedges against tenacious hackers (as real as they are).

In our next article, we will take some time to review the advantages of a decentralized system, before delving into more technical detail involving public-key cryptography and the concept of consensus.

In the meantime, welcome to the world of decentralization.

Kindly clap, comment, and follow me to stay updated!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store