II. Ordering

Blockchain In Plain English

Intro

This is not yet another post, written by a tech geek, to another tech geek. The knowledge gap between the blockchain space and the community is getting wider day by day. The aim of this series is to explain how Blockchains work in the simplest manner, so that an average person can easily understand it.

There will be 4 posts:

  1. Explaining what is a blockchain (and what it is not).
  2. Solving the ordering problem (double-spending) in a blockchain. <- you are here!
  3. What does Proof of Work (PoW) solve, and why is it necessary?
  4. Proof of Work in a nutshell (forks, immutability, longest chain, etc.).

Small recap: Sal has tried to double-spend his money, because he is too lazy to make his own coffee. Because of Sal’s laziness, now we have to work more on our protocol. Thanks, Sal!

Double-Spending???

Remember why double-spending is not an issue in centralized solutions. Because all the transactions are processed by a single entity (person, bank, or whatever). Although it may sound dumb, let’s see what will happen if you try to double-spend your money on your debit-card. In our scenario, you have 10 dollars in your account. You want 2 items from different online vendors (say Ebay and Amazon), both cost 10 dollars. So you have written some hacker code that will try to buy these 2 items simultaneously.

  1. Your super-ultra-awesome hacker code created 2 transaction requests simultaneously, one for Ebay, one for Amazon.
  2. Both of these transactions are relayed to your bank from Ebay and Amazon.
  3. Your bank received 2 transactions simultaneously. They don’t know which is first. And saw that you don’t have enough money for both of them. Depending on their policy:
    • they allowed one of your transactions, declined the other one (doesn’t matter which).
    • they denied both of your transactions (they will most probably do this).

We do kind of want to replicate this logic. The tricky part is, replicating this without making our protocol centralized is hard.

For example, we could have assigned Joe as our leader, and everybody could send their transactions to Joe. After Joe processed transactions, he could broadcast these transactions to everyone else. Nobody will update their Word Documents on their own. They will only add the transactions that are coming from Joe, to their Word documents. This would solve the double-spending problem. But, why don’t we use centralized solutions then? Now, we are not different at all. Joe may be corrupted, someone can bribe Joe, Joe may accidentally do something wrong, etc.

Double-Spending: What We Cannot Do

Here are some other things we CANNOT do:

  1. Make everyone send his transaction to a trusted 3rd party first (like a notary), then, this 3rd party can broadcast the transaction to everyone. So Sal can’t cheat by sending simultaneous transactions.
    • why we cannot do this?
    • then we would simply use centralized systems like before. If we are to trust a 3rd party (an authority), what is the point?
  2. Somehow forbid Sal to send simultaneous transactions
    • why we cannot do this?
    • this is really important. We cannot force people to do anything in blockchain. Because the enforcer of these rules will be the authority in this case. Then, who will inspect the authority? Another authority? Remember, we are trying to eliminate the need for authority. This is yet another unorthodox concept, but everybody is free to cheat in blockchain systems. The point is, to develop such a resilient system that, we can detect and tolerate the byzantine actors (malicious actors).
  3. Make everybody talk to everybody before recording the transaction into their ledgers, so that they will be aware of the double-spending issues. For example: if Joe and Brian were to communicate about Sal’s transaction, they would have discovered that Sal is trying to double-spend.
    • why we cannot do this?
    • We are in a distributed setting here, talking about worldwide communication. Some people will be offline, and there will be various connection issues (packets will be lost, there will be unexpected delays). To use that strategy, sending the transaction is not enough, we should also get a confirmation from the other party that they received our message. Even with that, it is not enough. If everybody waits for everybody, this will cripple the protocol so much that, it will be REALLY SLOW (nearly impossible) to operate on this blockchain.
  4. We can follow legacy consensus (voting) -if you don’t know what are they, don’t worry, you will be fine- algorithms.
    • Why we cannot do this?
    • If we follow the legacy consensus mechanisms, we would require at least %66 of the system to be honest (Proof of Work requires 51%), and on top of that, each voting will take a tremendous amount of time. And again, our blockchain will be really slow. I don’t want to dive into legacy consensus algorithms here.

I believe, now you understand how big is this double-spending problem, if we do not want to make compromises with decentralization.

Quis custodiet ipsos custodes? (Who watches the watchers?)

Roman poet Juvenal

Okay, What Can We Do?

Recall that, we have this double-spending problem, because everybody is updating their Word Document on their own. This is too chaotic! And selecting a leader was solving the double-spending problem. What if we select a leader for very short periods? And everybody in the system will be a leader sooner or later, so effectively, the users will become the authority. It will be a system that governs itself. Sounds promising, but you should have questions. Don’t worry, I will answer all of them.

Solving The Double-Spending Problem

Let us recall our 5 friends. They were using Word as their distributed ledger. But each page in Word can have some limited amount of transactions (say 50 for now).

What happens if the page gets full? Easy! They press enter, and a new page is created automatically!

Now, we don’t want our 5 friends to create new pages on their own. Say that current page of the Word document is full, and they are hearing new transactions. They can note these new transactions somewhere else (like notepad), but we don’t want them to include these new transactions in their Word documents immediately by creating a new page.

If we somehow manage to assign a random person for each page’s creation, and fill the contents of it, then the ordering problem will be solved. A very easy solution would be the round-robin approach (they take turns in the new page creation). For example, alphabetical order: Brian, James, Joe, John, Sal. They will create new pages in this order, endlessly.

The updated protocol is as the following:

  1. They rip off their real money, and record everyone’s initial account in their own Word document. The amount of money you rip off, will be your initial account in this case.
  2. They broadcast their transactions.
  3. The next page creator, gathers 50 transactions, orders them as he wants, and shares the new page with everyone.
  4. Everybody else inspects this new page, check whether the page creator followed the rules. If everything is alright, they include this new page to their Word. Else, they simply ignore it. So it doesn’t matter if the page creator cheats, that page will just be ignored.
  5. Step 3 continues forever.

Now, if anybody but Sal is the next page creator, Sal can’t double-spend. Because one of his transactions will be declined by the page creator as an invalid transaction. The question is: Can Sal double-spend by putting 2 conflicting transactions in the same page if he is the page creator?

As I said, anyone can do anything in blockchain. Sal can try to double-spend. Nothing or nobody is preventing him from that. But Sal will not gain anything from it, since everybody else in the team will say “Hey Sal, you are cheating mate! You have 7 dollars but you are trying to spend 14 dollars in here. I’m not accepting this page” (reminder: in decentralized system, everyone knows how much money there is in each account). The others will simply decline that whole page, and let the next person create the next page. That’s the beauty of blockchain, you get to do whatever you want, and others get to do whatever they want. If the majority is honest, the protocol will run just fine :)

What If Sal Tries To Double-Spend By Creating Different Pages?

Dude, slow down! You are too smart. We will cover that in the 4th article. Sigh…

I’ll only explain how this attack works for now. Say, Sal is the page creator for this round. He collects the necessary amount of transactions to create a page. But he creates 2 different pages, namely A and B.

A:

B:

Notice that only the last transaction is different between A and B. And Sal sends the page A to Brian and James, B to John and Joe. What will happen now?

Do not worry, we will also fix this in the future. Keep in your mind that this is a great question. You will find the detailed answer in the 4th article of this series. I advise to not jump directly into there. Everything I will explain, will be a building block. It might not make sense if you hurry.

Just to satisfy your curiosity, I can provide a simple answer. In this attack scenario, there will be basically 2 different ledgers (one with page A, one with page B). If we can find a deterministic criteria for the majority to select one of them, they can discard the other ledger, and all transactions will be consistent with each other. Say, in every page, the majority will broadcast their version of the ledger, and if there are more than 1 version, they will select one of them depending on an objective criteria. This criteria can be alphabetical order on the contents of the block (very bad criteria by the way, just saying).

This is not how blockchains work! It was just a dummy example to demonstrate that this problem can be solved.

The Page Creator Cannot Create Transactions Out of Thin Air

Joe, being a complete retard using computers, accidentally pressed ctrl+v three times instead of once. And now the transaction that Brian pays Joe 10 dollars is recorded, but 3 times…

Unfortunately, Brian does have enough money to cover these transactions, and they will not fail. Okay, this was an honest mistake, but what if it was a malicious action? What if Joe tried to create a fake transaction of:

Our protocol should not allow any of this non-sense.

This problem can easily be solved with Digital Signatures. In summary (in case you did not read the link I gave, but you should), everyone has a password, that they can use for creating transactions for their money. Joe cannot create the transaction Brian -10000, Joe +10000, since the money is coming from Brian in here. The only person that can craft this transaction is Brian. However, the copy-paste problem still persists. Joe can copy-paste a valid transaction that Brian made: Brian -10, Joe +10 many times.

So, the naive Digital Signature scheme solves the problem of:

but not:

We can solve the second one with little additional effort: by adding some counter to each transaction. For example, now, Brian would create this transaction: 1. Brian -10, Joe +10. If he wants to replicate this transaction, and send 30 dollars to Joe with 3 separate transactions, then the transactions should be like this:

Now, assuming Brian did not intend to send 30 dollars, but 10 dollars to Joe. And Joe did the copy-paste accident.

These are clearly the same transactions, not separate ones.

By utilizing Digital Signatures, and adding a little trick, now our transactions are bullet-proof. Nobody can craft/duplicate transactions on behalf of someone else.

What If Someone Tries To Create A Page, Although He Is Not The Page Creator For That Slot?

The others will simply discard that fake/invalid page. And his ledger will be incompatible with the majority.

Wow, we made it?

No xD

What will happen when someone joins, or leaves the network?

…

Yeah, that will mess up the system. Since we are taking turns, the page creator for that turn should not leave the protocol whenever he wants. We also cannot allow anyone to join as soon as they want. All of this, because we are taking turns for becoming the page creators. So, it seems taking turns is actually not a good idea, huh? Good.

Also, there is another really weak point of this system as I mentioned: Denial of Service attacks. Because of the round-robin fashion, we know in advance, who will try to create which page. If we want to censor some transactions, we can attack the page creator at that slot, and he will be unable to create the page (it is quite easy to perform Denial of Service attacks, especially to an ordinary computer).

I mean, if you are okay with having a few trusted centralized authorities (whitelist of users) that will be the page creators, and if they are resilient to Denial of Service attacks, this protocol is probably do the trick. But we are aiming for true decentralization here, in a trustless setting (meaning that: we should not have to trust anybody).

In summary, what we have proposed is not a good solution because of these 2 reasons:

Proof of Work: a pioneer for the blockchain technology

Although what we have done has some flaws at the moment, we are actually close to a real solution. Proof of Work solves all the aforementioned problems, with one cost: electricity usage (we will also solve this via Proof of Storage and Proof of Stake, but let’s take one step at a time).

We will inspect how PoW works in the next article. See you there!

Next Article

III. Proof of Work