Because everyone is storing information about the blockchain, you 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 you have a mechanism by which everyone can come to consensus. To understand the best consensus mechanism for Bitcoin, you will start off by understanding what problems exist with naive consensus strategies and solve them in the next iteration, continuing this process until you finally recreate Bitcoin’s consensus model.
For this consensus buildup, you will consider the same 5 actors from before: 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 you 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 do not 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 you will see, this does not work because of what’s known as the double spend attack.
With centralised systems, you 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 behaviour, we must build mechanisms that handle these situations.
Let’s say, Gloria is purchasing tons of laptops and is willing to pay both Nadir and Rustie 10 bitcoins for our laptops. Gloria promises 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 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 realised, she only tells one person about each transaction: the person receiving the bitcoins.
Rustie only know about his 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 Rustie, Gloria tells Rustie to update his [Rustie's] copy of the ledger, and with her transaction to Nadir, she tells Nadir to update his copy of the ledger.
Both Nadir and Rustie see that the transaction is valid and each believe that we have received the bitcoins.
Of course, both Nadir and Rustie cannot own the same bitcoins. The moment you 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 Rustie tries to convince anyone else that Rustie own these ten bitcoins, they will all think he is crazy because they have seen no evidence of 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 your current model of consensus.
Instead of individuals doing their own validation of transaction, you can set up a voting system.
The problem with your previous version of consensus was that there was not any consensus! Instead of making sold decisions as I did talked 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.
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 Rustie, as indicated with the solid green arrow, and one to Nadir, as indicated with the solid blue arrow. However, I introduce a new component: communication.
The dashed blue and green lines from Nadir and 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, they are protected against Gloria’s attempts at malicious behaviour.
Peers in the network vote “no” on Gloria’s proposal, as they notice multiple transactions trying to spend the same funds.
The transaction does not go through, and is not included in an update to the blockchain. It looks like we have 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, you forgot one fatal truth about Bitcoin: the anonymity.
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 is no value in a vote because anyone with spare time can make as many identities as they want.
You 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 Rustie, and they 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, they 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 Rustie.
Clearly, to solve the problem, you 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, you have to make a vote expensive. you 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?
This is where the innovation of Satoshi Nakamoto comes into play.
They recognised that in order to ensure every real entity has equal voting power, they cannot vote with identities at all. Instead, Satoshi realised 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. Clever! 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.”
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.
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 is because you believe in the unlikeliness of that situation that you are not afraid of anyone breaking into you phones. Although you cannot guarantee that it takes exactly some amount of computation to solve these problems, you 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 Rustie, and these two transactions are sent to the rest of the network. they 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 Rustie recognise that there are two transactions trying to spend the same funds, they can vote against both transactions being included in the blockchain.
Gloria with her single computer is incapable of outvoting us, which is precisely what they want! By tying our voting power to you real world identities through the scarce resource of computing power, you have successfully eliminated Sybil attacks from Bitcoin and solved the double spending problem.
This is what made Bitcoin a revolutionary technology.
Comments