Consensus (Stage 4)
Now we know how to send transactions to one another with unique identities using the UTXO model, and how to store these transactions using a blockchain to maintain a global record.
At this point, we’re only missing one final piece to bring all these different components together.
How do we make updates to the blockchain? How do we decide which transactions, or blocks of transactions, are valid? With no central entity deciding on the next update, we have to find a way to make this decision in a decentralized way.
In Bitcoin, users on the network must come to consensus, or agreement, on the next valid update.
Because everyone is storing information about the blockchain, we need consensus to make sure that everyone agrees on the history of transactions.
Not only do all users need to agree on the update, but they also need to agree on a valid update to make sure that no corrupted information is accepted by the network.
If there was no way for different parties to come to agreement on this, then there will forever be this schism between them.
Without agreement, we cannot have a functioning distributed database.
We have to all stay on the same page to make sure that we all believe in the same reality of Bitcoin.
Thus, it is imperative that we have a mechanism by which everyone can come to consensus.
To understand the best consensus mechanism for Bitcoin, we will start off by understanding what problems exist with naive consensus strategies and solve them in the next iteration, continuing this process until we finally recreate Bitcoin’s consensus model.
For this consensus buildup, we will consider the same 5 actors from before: me (Rustie), Gloria, Derrick, Nadir, and Nick.
In the most basic consensus mechanism, updates take the following form: One node proposes a transaction to the network, sending a message about the transaction directly to every other node All other nodes save the transaction into their history if it’s valid and disregard it otherwise We have an example for you here.
Gloria wants to make a transaction to Nadir, so she sends that message to all four other entities.
This is represented by the arrows pointing from Gloria to every other entity, blue to represent that she is making a transaction to Nadir, the blue circle.
The implication of this system is that nodes don’t engage in conversation with one another, and the only nodes that see a transaction with one hundred (100) percent certainty are the sender and recipient.
As we will see, this does not work because of what’s known as the double spend attack.
[Double spend] With centralized systems, we trust banks to check for the validity of all transactions.
Recall that one condition of a transaction being valid is that proposed funds for the transaction are not promised elsewhere in a previous transaction.
Because we do not have a bank to check if there is any malicious behavior, we must build mechanisms that handle these situations.
Let’s say that Gloria is purchasing tons of laptops and is willing to pay both Nadir and myself (Rustie) 10 bitcoins for our laptops.
Gloria promises me (Rustie) 10 BTC in one transaction, and promises 10 BTC to Nadir at the same time.
This is represented by the green arrow from herself to me (Rustie), the green circle, and by the separate blue arrow from herself to Nadir, the blue circle.
However, she only has 10 BTC in total.
Her invalid transaction evades detection because, as you may have realized, she only tells one person about each transaction: the person receiving the bitcoins.
I (Rustie) only know about my (Rustie’s) incoming bitcoins, and Nadir only knows about his.
Derrick and Nick, the other entities in the network, know nothing about either transaction.
This is what’s known as a double spend attack.
Gloria is spending only 10 bitcoins to get 20 bitcoins worth of goods.
In this naive version of consensus, this is legal: with her transaction to me, Gloria tells me to update my copy of the ledger, and with her transaction to Nadir, she tells Nadir to update his copy of the ledger.
Both Nadir and I see that the transaction is valid and each believe that we have received the bitcoins.
Of course, both Nadir and I (Rustie) can’t own the same bitcoins.
The moment we try to redeem these tokens with the network, the issue becomes transparent.
It’s going to look to Derrick and Nick that these transactions never happened.
If I try to convince anyone else that I (Rustie) own these ten bitcoins, they’ll all think I’m crazy because they’ve seen no evidence of me (Rustie) ever having received these bitcoins.
The same applies to Nadir.
In this scheme where entities only see the transactions that directly involve them as sender or recipient, it is impossible to come to consensus on a history of transactions because of dishonest actors.
Thus, it is impossible to prevent these double spend attacks with our current model of consensus.
[Peer Validation] Instead of individuals doing their own validation of transaction, we can set up a voting system.
The problem with our previous version of consensus was that there wasn’t any consensus! Instead of making siloed decisions as we did before, let’s implement a system of proposers and voters.
One person at a time makes a proposal about an update, and everyone else votes on whether or not to accept the proposal.
The person who wants to make a transaction sends the transaction to everyone in the entire network, not just the recipient of bitcoins.
Everyone on the network then casts votes based on whether the transaction they saw was valid or not.
Only after receiving a certain number of votes, say a majority, does the transaction get saved.
Like before, there are blue lines from Gloria to the rest of the network to indicate that she is making a transaction to Nadir.
Unlike before, there are dashed blue lines from each node to everyone else (excluding Gloria) as an indication of communication about two things: the received transaction and a vote for or against its validity.
[Rejecting the Double Spend] Let’s observe what happens when Gloria tries to double spend under these circumstances.
Now, when Gloria attempts to double spend, she will be rejected by observing peers.
She again sends only two messages: One of a transaction to me (Rustie), as indicated with the solid green arrow, and one to Nadir, as indicated with the solid blue arrow.
However, we introduce a new component: communication.
The dashed blue and green lines from Nadir and myself (Rustie) respectively represent the relay of those message to the rest of the network.
By looking to the rest of the network for input, considering everyone else the third party, we are protected against Gloria’s attempts at malicious behavior.
Peers in the network vote “no” on Gloria’s proposal, as they notice multiple transactions trying to spend the same funds.
The transaction doesn’t go through, and is not included in an update to the blockchain.
It looks like we’ve solved all our problems: we have a voting system that ensures that no one can double spend the same funds, and each peer stores the whole history of transactions so that they can verify for themselves that the funds exist.
It looks as if we are victorious! However, we forgot one fatal truth about Bitcoin: the anonymity.
[Stranger among us] Recall that Bitcoin is an accessible, anonymous network with no central registry.
Banks keep track of everyone’s identities and accounts, but no such infrastructure is available in Bitcoin to prevent anyone from producing multiple identities.
In Bitcoin, anyone can join, and anyone can participate.
Because of the ease with which Bitcoin addresses can be generated, nothing is stopping Gloria from generating more identities and posing as Derrick and Nick.
It’s inexpensive to create multiple identities, requiring only the generation of a random number, as seen in the identity section.
Because of this low cost, Gloria can easily hold multiple Bitcoin identities to cast more votes than she should be allowed.
Gloria, a real-world minority, could easily propose and vote for her own malicious transactions by creating sufficient identities and occupying a network majority.
In other words, this current version of consensus is susceptible to a Sybil attack, where a user creates multiple identities for some malicious purpose.
With such a little cost to vote, votes become meaningless.
There’s no value in a vote because anyone with spare time can make as many identities as they want.
We see that this is a problem when Gloria attempts the Double Spend attack because, with these extra identities under her control, she succeeds.
She sends the transactions to Nadir and me (Rustie), and we send these transactions to the rest of the network, and they all vote that both transactions are valid.
Because the majority votes on both transactions being valid, we now have a lack of consensus about what the truth is.
Gloria has broken Bitcoin all because it was easy for her to pose as multiple people and cast multiple votes, overwhelming Nadir and myself (Rustie).
Clearly, to solve the problem, we cannot assume that each online identity deserves the same voting power, as some people have multiple identities.
To ensure that every real person only has one vote, we have to make a vote expensive.
We have to make it such that anyone trying to vote has the same amount of voting power as anyone else, regardless of how many Bitcoin identities they have.
But how? Is it even possible to solve this problem? [Pay to Play] This is where the innovation of Satoshi Nakamoto comes into play.
They recognized that in order to ensure every real entity has equal voting power, they cannot vote with identities at all.
Instead, Satoshi realized that, to preserve freedom and anonymity while solving the issue of endless identities, each vote must be cast with resources.
Scarce, valuable, tangible assets.
The particular resource that Satoshi identified was one available to all users of Bitcoin: computing power! Online entities can be generated easily, but you can’t copy-paste a computer.
By tethering voting power to scarce computing power, Satoshi ensured that all users have scarce voting power.
In his whitepaper, he envisioned a “1-CPU-1-vote” network, rather than the traditional “1-identity-1-vote” system.
It is this new concept of voting with resources instead of with identities that earned the title “Nakamoto Consensus.” The particular consensus algorithm that Satoshi Nakamoto came up with is known as “Proof-of-Work.”
[Proof of Work] Let’s break down the word “Proof-of-Work.” We know “proof” to mean “evidence,” and “work” to mean “spent resources.” In other words, “Proof-of-Work” is the method by which users provide evidence of spending resources.
It is the method by which computing power is translated into voting power.
It is the method by which users vote in Bitcoin.
It is this method of voting that made Bitcoin the first successful cryptocurrency and inspired voting mechanisms for practically every other cryptocurrency to follow.
[Proof-of-Work Works] Here’s how Proof-of-Work works: whenever someone wants to make a proposal to the rest of the Bitcoin network, they first have to solve a computationally difficult problem.
In other words, their computer is tasked with a problem that can only be solved by doing a significant amount of work.
This problem is uniquely generated based on the information within the proposed block and cannot be predicted beforehand.
There’s no way to predict the solution to the problem.
Instead, it’s similar to brute forcing a password: all you can do is trial and error.
Your computer will try a bunch of inputs until it finds a solution to the problem, at which point it will submit the successful input along with the proposed block to the rest of the network.
The unpredictability of the form of correct inputs ensures that there’s no way to “game the system,” keeping any user from cheating.
By having every user solve a brute force problem, you have a reasonable expectation that they’ve done a lot of work to solve it.
You might ask, “What if a user gets lucky and finds the solution to this brute force problem on the first try?” Well, this is possible, but not probable.
For example, it’s possible for me to guess the PIN on your phone in one try — but it’s because we believe in the unlikeliness of that situation that we aren’t afraid of anyone breaking into our phones.
Although we can’t guarantee that it takes exactly some amount of computation to solve these problems, we have reasonable expectations based on how long on average it takes to solve these problems.
Let’s see Proof-of-Work in action.
Again, Gloria tries to double spend on Nadir and me (Rustie), and these two transactions are sent to the rest of the network.
We all vote on the transactions, but Gloria no longer has a voting advantage even though she still has control of two extra Bitcoin identities.
Her voting power is bound by her computer, just as everyone else’s is.
Even though there are five digital identities, there are only three real-world identities.
Under Proof-of-Work, no matter how many digital identities are formed, there will only ever be three voting entities.
Because Nadir and I (Rustie) recognize that there are two transactions trying to spend the same funds, we can vote against both transactions being included in the blockchain.
Gloria with her single computer is incapable of outvoting us, which is precisely what we want! By tying our voting power to our real world identities through the scarce resource of computing power, we have successfully eliminated Sybil attacks from Bitcoin and solved the double spending problem.
This is what made Bitcoin a revolutionary technology.