Introduction

Bitcoin, Ethereum, NFTs, Cryptocurrency, FTX. You've almost certainly heard of at least one of these before. From get rich quick schemes to funny looking art to billion dollar companies going bankrupt, these buzzwords rocketed into the limelight only to earn a reputation of scamming and fraud. What's really behind all of this? Should you turn away from anything even remotely related to these based on its reputation or is it worth a second look?

This article aims to explain the single technology underlying all of these: blockchain. It will cover why it was invented, how it works, variations of it you should be aware of, and thoughts on its future. Ultimately, we are seeking the truth about blockchain and we will use the Bitcoin protocol as a starting point in doing so.

Why Blockchain?

A Problem

Imagine you're at a bike store and you're about to buy a new bike for $1,000. You check your phone to make sure you have enough money in your bank account to buy the bike, but it turns out you're $500 short! Then you remember that your friend owes you $500. So, you call your friend and ask them to send $500 to your bank. Your friend agrees, and the money is sent over.

How did this transaction work? Your friend contacted the bank and requested the transfer. Then, the bank entered the transaction into their (probably digital) transaction database, giving you the money.

Using this process, you and your friend are placing trust in the bank. Why is this a problem? The bank acts as a single point of failure:

1. The bank could record a transfer of $1,000
2. The software the bank uses to store the transaction in the database could be hacked
3. The database could become corrupted

In summary, the problem is that trusting a single entity to serve as the middleman can have harsh consequences.

A Solution

So, can we do better? In short, the answer is yes, but we'll need to break the problem down into simpler pieces in order to arrive at a solution.

First, we must answer the following fundamental question: what did the bank accomplish for us during the transaction? In other words, we need to analyze the actions the bank took and the results in order to determine if there may be another way to achieve the same results without relying on any centralized institutions.

Simply put, the bank recorded our transaction in its ledger. We informed the bank that we would like to make a transaction, and its software system, potentially aided by employees, created a new entree in its database to reflect our request. As discussed earlier, there are many important problems associated with this method of tracking transactions over time. Additionally, at this basic level, it seems like a fairly straightforward task to accomplish: just record new transactions somewhere as they occur.

So, what if instead of relying on the bank to provide us with this service, the users collectively decided to terminate their ties with the bank and maintain their own shared ledger of transactions within the group? This doesn't seem like rocket science and it seems to solve the problem of a single point of failure associated with transaction logging.

However, as H.L. Mencken put it, "for every complex problem, there's a solution that is simple, neat, and wrong". While this method seems easy, taking this arguably naive approach brings many potentially unexpected challenges with it, some of which are addressed using a piece of technology known as the blockchain.

How it Works

Introduction

Suppose a group of people decide that they are going to stop using the bank as a middleman and maintain a ledger of transactions themselves.

In this scenario, we'll imagine that each person has their own ledger which they use to mark transactions. Now, whenever one member of the group wants to transfer funds to another, they will announce this action to the group. Then, each person in the group will add the transaction to their own ledger.

Eventually, everyone will run out of of space on their ledger page to record transactions so they will need to begin a new one. But first, a critical question:

What should everyone do with their current, filled page?

The simplest solution is to have everyone file their page away in their own folder and continue on a new page for new transactions. However, this is clearly a horrible strategy: what if someone (or multiple people) sent fraudulent transactions to others?

For example, what if Bob tells Jim that he sent Jim $100, but doesn't tell anyone else? In this scenario, Jim thinks he has $100 and Bob has $100 less than before, but everyone else in the group thinks nothing happened.

Now, how can we prevent such schemes from occurring?

Cryptography

To prevent such schemes, we can use a powerful tool of math and computer science: cryptography.

Specifically, what if we used a function that maps an arbitrary sized input to a fixed size binary string such that it is easy to compute the output given the input but computationally infeasible to determine which input produced the given output. Additionally, any change to the input, no matter how slight, must produce an unpredictable change in the output so that no patterns can be discovered easily. Such a function is called a cryptographic hash function.

Now, let's specify a goal, denoted the hashing goal, as follows:

Find a number that which, when appended to the end of the ledger page, produces an output from the cryptographic function that starts with X number of 0's. For example, we could set X = 30.

[4]

Now, we return to our original question: what to do with the completed ledger page? Imagine that we "stamped" each page with something that the entire group agrees on that is based on the contents of the letter itself. Then, any change to the contents of the ledger would be blatantly obvious to everyone in the group. If we "stamped" every such ledger page, it would become effectively impossible to rewrite transaction history in favor of anyone. Perhaps we can use a cryptographic hash function to create such "stamps".

Proof of Work

Recall that completing our goal of finding a number for our hash function takes time and electricity. In other words, it requires work. Now, consider the idea of using the number found via this work as the "stamp" on our ledger page. Now, it is effectively impossible for someone to change a transaction on the ledger and and seal it with the "stamp", as the stamp would have changed since the contents of the page changed.

This is great! It appears to solve the problem of fraudulent transactions via the following protocol:

1. Whenever someone makes a transaction, they broadcast it to the entire group
2. When the ledger page gets filled, whoever performs the work first and finds the stamp for the page broadcasts it to the rest of the group
3. When everyone receives the stamp, they confirm is is a valid stamp (i.e. achieves the goal mentioned before) and if so, files away the page with the stamp

Now, if someone attempted to make a fraudulent transaction, once someone broadcasts a stamp, the one who received the fraudulent transaction would be unable to verify their ledger with the stamp and would know that something is wrong!

More Problems

There are still two looming problems:

1. How can we ensure nobody dominates the "stamp" finding process, thus enabling them to spread fraudulent transactions continuously?
2. How can we ensure nobody tampers with previous ledgers?

Let's address the first problem.

Recall that the stamp finding process requires work. Since we know this means it requires time and electricity, we can break this down further in that the stamp finding process requires the following resources:

1. Computational power (i.e. computer hardware)
2. The energy required to run (1), so electricity

Observe that in our scenario, the compute power is distributed among all the members of the group. Therefore, in order to continuously win the stamp finding race, one member's compute resources must repeatedly find such a stamp faster than all of the other member's resources combined.

Clearly, with a large enough network of members, the resources of one member is incredibly unlikely to continuously outcompete everyone else's combined resources, and therefore will be unable to continuously broadcast false transactions and back them up with stamps.

Now let's address the second problem.

We previously described that altering any transaction on a ledger requires recomputing a stamp so that the page will still solve the hashing problem. However, given enough time, clearly it is possible for a member to perform such a computation, thus changing the transactions in a page.

How can we solve this problem (henceforth denoted the tamperable problem)?

Solving the Tamperable Problem

An idea: order the pages in such a way as to make them all more tamper resistant.

Take a page which we have filled and computed the stamp of. Now, take this hash output and prepend it to the next page. Now, when computing the stamp of this next page, the hash of the previous page will be taken into account. Therefore, any changes in one of the pages will ripple down the ordering and invalidate the following page stamps (since the contents of each page will have changed).

[4]

It follows that in order to tamper with any of the pages in our ordering, the tamperer will need to recompute the pages all the way to the current page.

There is one addition to our high level protocol which, combined with our solution to the tamperable problem, will complete our solutions to problems we have discussed: each member of the group accepts the longest ordering of pages with stamps that they know of as the true list of pages.

Now, if one member wants to tamper with a previous transaction, they have to recompute the hash of all the pages in the ordering AND be faster than the collective resources of everyone else to create the longest chain, a task which is effectively impossible.

Why Do Work?

An observation: performing work to compute the next stamp seems to be without incentive; why would an individual member attempt to find the next stamp if they could just wait for someone else to do it?

A final addition to our protocol: finding the stamp for a page automatically adds a transaction at the top of the page giving the finder some amount of money. Note that this transaction will not be used in the hash computation for the page, as it was already found.

In the context of Bitcoin, putting in work to find stamps is known as Bitcoin mining.

Alternatives: Proof of Stake

Thus far, we have covered the blockchain model in the context of Bitcoin, which operates with a Proof of Work (PoW) mechanism. Now we will briefly cover an alternative to this mechanism: Proof of Stake (PoS).

A Problem: Energy

Recall that mining Bitcoin requires putting in work via computer hardware and electricity. In total, how much electricity does this entire process require?

In short, a tremendous amount.

So, in conclusion, we may have solved the single point of failure problem, but in doing so, we consumed a massive amount of energy. Arguably, the amount of energy consumed outweighs the benefits of removing the middleman, one of the primary arguments against the use of Bitcoin.

A Solution: A Brief Intro to Stakes

We want to drastically reduce the total energy consumed in this process while maintaining the integrity of the ordering. An idea:

Don't have everyone compete to find the next stamp because it causes a massive amount of energy consumption. Rather, require everyone that wishes to profit from the system to put forward a deposit of currency, called a "stake". Now, an algorithm that considers the stakes of the members and randomness will select a block proposer and a group of validators. Next, the block proposer will manually review all the current transactions and determine if it believes they are all valid. If so, it will compute the hash of the page and broadcast the page and the hash to the rest of the network, at which point the validators will confirm or deny the validity of the page and hash themselves.

If everyone is in agreement, the page will be accepted as truth and the proposer and validators will be rewarded with currency. In this way, we eliminate the need for massive energy consumption while maintaining integrity of the system.

Note that this is just a brief introduction to the staking mechanism and one should be aware that many variations exist.

Final Remarks

Throughout this article, we have discussed pages and orderings of a ledger. Now, if one considers the pages to be blocks and the ordering as a "chain" of such blocks, it is clear that the blockchain mechanism handles chains of blocks.

While blockchain may have earned a poor reputation following its misuse, it is nonetheless an interesting technology whose full potentially has likely not been realized. It is definitely important to exercise caution when dealing with new technology, but that does not mean that full avoidance is the best course of action. Rather, careful consideration of the benefits and drawbacks should be undertaken before a conclusion is reached.

Please not that the author does not endorse cryptocurrencies or its related components. Rather, the aim here is to fully understand the technology underlying such systems appreciate its complexity and potential for future applications.

References/Sources

[1] https://static.vecteezy.com/system/resources/previews/008/822/064/non_2x/3d-design-bitcoin-cryptocurrency-white-background-free-png.png [2] https://cryptologos.cc/logos/ethereum-eth-logo.png [3] https://cdn-icons-png.flaticon.com/512/2091/2091665.png [4] https://www.youtube.com/watch?v=bBC-nXj3Ng4 [5] https://cdn.statcdn.com/Infographic/images/normal/18632.jpeg

Ideas from: [A] https://www.youtube.com/watch?v=M3EFi_POhps [B] https://www.youtube.com/@3blue1brown