Sequels are often a poor shadow of the original genius. But not in this case! Strap yourself in for the gripping part II of this introduction to decentralization. In part one we covered where the centralized world has come from historically. In this post, we continue the explanation of the seismic shift that has occured in the technology of trust, leading to decentralization.
But first, you need to understand encryption.
When talking about encryption and cryptography, two familiar characters enter the scene with habitual certainty: Alice and Bob. And sometimes one other character (evil Eve / malicious Mal).
There are two main things you can do with Asymmetric Key Cryptography (loosely, that’s where you have a public key and a private key).
The first thing that Alice and Bob can do with Asymmetric Key Cryptography is of course: Encrypting. Which means that Alice can write a sensitive message, encrypt it, and send it to Bob, without anyone but Bob being able to read it.
This is achieved by the following steps: First Alice writes her sensitive message e.g. (“Please send the goods to 123 Road Street.”), and then encrypts it with Bob’s public key, which everyone knows and has access to. Now, only Bob’s private key can decrypt the encrypted message. If Eve views the encrypted message in between, she won’t be able to decrypt it, because she doesn’t have Bob’s private key. Only Bob has his private key. When Bob receives the encrypted message, he uses his private key to decrypt the message and is able to read the sensitive contents. Wonderful.
But now, we have a new problem. Since Bob’s public key is public (everyone knows it), then, in our example, you may ask: Well, couldn’t Eve just throw away Alice’s entire encrypted message, and replace it with her own evil message (“Hello this is really definitely Alice. Send the goods to 456 Other Street.”) which she encrypts with Bob’s public key? When Eve sends the evil replaced message to Bob, Bob would still be able to decrypt it and he would be none the wiser that it had really come from Eve, not Alice. That would be bad!
Introducing the second thing that you can do with Asymmetric Key Cryptography: Signing. Signing is the solution to the problem of authenticity. So, Alice wants to send a message to Bob, and she wants Bob to be certain that it really came only from her. They take the following steps: First, Alice writes her message and sends it to Bob unencrypted, she also encrypts the same message with her private key, and sends that encrypted message too. Note that only Alice’s public key can decrypt the message that was encrypted with her private key. Since everyone (including Bob) knows Alice’s public key, Bob is able to decrypt the message and if it works and the two messages match perfectly, then Bob knows that it really did come from Alice, and was not tampered with.
Combining these two methods together gives a powerful result. Alice and Bob can communicate with certainty that 1) what they say to each other won’t be read by Eve and 2) the messages they receive can only be from each other, and not Eve impersonating them. These are referred to as confidentiality and authenticity respectively.
Back to the problem of trusting the bank with your sheep.
Instead of holding gold to represent value, instead, in a decentralised world we hold bitcoin. I do this by holding onto two encryption keys, one key is secret only to me, and one key is public, that I can hand out to everyone.
Anyone who has my public key can use it to check that I really have the bitcoin. “According to whom?”, you might ask. Is there a central website or vault that they can go to, to check? No, there is not, they do not need to trust any one person. In fact, they don’t even need to trust me. They can check with thousands of blockchain servers around the world, independently run by strangers, none of them centralized in one place, or under the control of one group or government. All of those servers have cryptographically confirmed that “Yes in fact, he does have that bitcoin”. Since I could probably convince a few of them to lie and say that I have the bitcoin when I really don’t, you need to make sure a large majority of all the decentralized servers agree. This “consensus” problem is one of the core aspects that makes blockchain new and interesting.
I use my private key to send some of that bitcoin to you. Again, do you have to trust me? No sir! You don’t have to trust any one person. I use my private key to sign a message out to all the bitcoin servers on the internet, telling everyone that some of my bitcoin is now yours. Since I’m the only one with my private key, all of the servers know that it’s really mine, and no trust is needed. Without needing to trust that I’ve sent the funds, now you can just ask all of those servers, and when they all agree, then you know that the bitcoin has really been sent to you. And no bank or government is involved at all!
Be aware that this explanation is a nutshell only, it skips over the details of how bitcoin actually works, but gives you the general idea.
Now that you know roughly how the blockchain works, and that you no longer have to trust any individual bank, company, vault, government, or sheep, you can go ahead and use Bitcoin and other blockchain based technologies with confidence.
Stay tuned for more things you can do with blockchain, including voting, trading, loans, and distributed decentralized computing!