[EP -3 ] The Magic Behind Blockchain: ⇛ Build Up 1 ⇚
Previously on Episode 2 of “The Magic Behind Blockchain”…
we analyzed a homegrown blockchain consensus solution (the cake-and-bread blockchain) in order to understand:
- A basic algorithm of achieving consensus and the importance of cryptographic reduction at the consensus layer
- Basic security and efficiency analysis (pros and cons) [participant selection vs value correctness]
- The line that divides cryptography and crypto-economics
In today’s episode, things take a turn in the real world. There are 4 key foundational pillars we need to build up in order to understand real-world blockchain applications and to have a complete understanding of the episodes to come. These pillars are:
- The Byzantine Generals’ Problem,
- CAP Theorem,
- Blockchain Trilemma, and
- Consensus Categorisations
WORDS ARE INEFFICIENT
At the end of the first 5 episodes (including Episodes 4 and 5 in the next weeks) of this series, there is a particular mental image I want you to have. Like a mind map. I thought for a while about how to communicate this. Eventually, I came to the conclusion that words alone will be an inefficient means of conveying this mental picture so I drew it out.
At the top of the image above, you can find the first important topics we covered in Episode 1. Mainly answering the question: “Why should you care about Blockchain?” Topics such as the importance of decisions, group decisions, the difference between a Distributed Decision Technology and the so-called Blockchain, Game Theory & Mechanism Design, and crypto-economics were briefly covered.
On the left hand of the image are the Blockchain objectives. These are the key success metrics of blockchains. Together they (Speed, Decentralization, and Security) are usually known as the Blockchain Trilemma. “Durability” is a special case we will look at in the next episode. They apply to all layers of the blockchain architecture. The Trilemma is a very important aspect to consider when designing or reviewing a Blockchain solution.
The middle part of the image shows the general blockchain architecture also described in Episode 1.
To understand different Blockchain configurations, we used the Cake & Bread Blockchain (from Episode 2) to paint one perspective of the security and efficiency problems that arise in consensus. The Byzantine Generals’ problem is another perspective. Together these 2 perspectives act like a magnifying glass to understand all Consensus mechanisms (a.ka. Consensus Categorisations).
These 2 perspectives will also aid your understanding of the importance of the CAP Theorem at the Content Layer. Eventually, we want to get to Byzantine Fault Tolerance (BFT) which is a really interesting category of Consensus.
The picture may serve as a framework for understanding any blockchain. We will be building more and more on this framework (mind map / mental image as we progress). Eventually, you will be able to represent any blockchain by inputing different parameters in the various sections of the image to arrive at the configuration you want, while keeping in mind the trade-offs.
LET’S BEGIN!
If you ask enough people to explain Blockchain to you, chances are, eventually you would come across a foundational problem that acts as the basis of most blockchains. If you saw Episode 1 and guessed that the foundational problem is collective decisions/consensus, you are right. However, the cake-and-bread algorithm in Episode 2 showed just one perspective of this consensus problem.
Therefore, it is only fitting that today we take a look at the classical perspective of this consensus problem. This is the one taught in most books and lecture halls.
BYZANTINE GENERALS’ PROBLEM
So the story goes as follows:
It is the middle ages (roughly between May, 330 AD, and May 1453). A great and ancient empire/city stands at the heart of the eastern flank of the Roman Empire. Its name .. Byzantium.
A battalion of enemy Generals have surrounded the city in dispersed groups, and they need to decide on a common strategy (and a set of tactics) to successfully attack/take the city. However, they face a critical problem:
- Since the Generals are in dispersed groups, they need to communicate a common plan of winning the war via messengers to the other Generals. For simplicity, let’s say the message is simply “attack” or “retreat”.
- If all Generals get the same message and adopt the same strategy (attack or retreat); They win. They take the city (Byzantium) and all the spoils of war.
- However, if there are any lukewarm/unreliable Generals or messengers (traitors); and some Generals attack while others retreat, they will all suffer a brutal defeat at the gates of Byzantium. Simply because they will lack the numerical strength to execute any strategy or tactics successfully. In simple terms, whatever plan they choose (attack or retreat), they will simply be outnumbered.
- There is no other way out. They must decide on a common strategy.
This is the Byzantine Generals’ Problem.
Can you think about any solution (set of steps) to help these Generals come to an agreement?
Can you spot the similarities between this problem and the “Bread & Cake Sharing Consensus Problem” from Episode 2?
- The 3 siblings (I and my other two siblings) are the Generals.
- Byzantium is the cake.
- The problem is that we can’t agree on a common strategy to share the cake. Similarly, the problem with the Byzantine Generals is that they can’t agree on a common strategy to wage war on Byzantium.
The key difference between the Byzantine Generals’ problem and the Bread and Cake algorithm is that there is the need for the Generals to use unsecured communication channels. While in the Bread and Cake algorithm we didn’t have any communication issues because there was physical proximity amongst the siblings.
WHY IS THIS STORY RELEVANT?
As it turns out, immediately after we create a peer-to-peer decentralised network, there is a literal 1-to-1 mapping between the Byzantine Generals’ problem and the problems we will face in our newly created network.
For those who want to get their hands a little dirty,
Let’s take a practical example: If we wanted to join the Ethereum Blockchain network, all we would have to do is:
- Head over to https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients and download an Ethereum client. I love the Go version of “Geth”. A software client, in this case, is just a tool that helps you to interact with the Ethereum network.
You can also just install via terminal. I do it like this on macOS.brew tap ethereum/ethereum// May be better to use “light” here
brew install ethereum
geth --syncmode "full" - The software should automatically synchronize with the Ethereum network and go through a Synchronization phase. Thus, downloading literally every transaction that has ever been agreed on since the existence of Ethereum.
- Optionally most people run some IP obfuscation technique like TOR / proxychains or VPN to mask their node location. A node is just a computer in a network.
You should see something like this:
Note that the steps above will run a full node (which means becoming a full source of truth for all Ethereum transaction. This is trustless. However that’s about 750GB+ worth of data. You will also be uploading / downloading a ton of data every month. So there are costs to consider. Please run this responsibly. Most people run a light node which is just enough to verify transactions without having to hold all data. It mostly downloads the transaction block headers not the full block data. It syncs much faster as well: in minutes rather than hours / days. How can you verify a larger data set with only a smaller data set? The answer is Merkle Trees/Tries .
Ok now that I conveniently sneaked in the difference between a full node and light node, how does it relate to the Byzantine Generals Problem?
You see .. Immediately you ran that installation and became a full node, you also became a “General”. Your computer opened up TCP port 30303 to talk to other computers in the Ethereum network. Run the following 3 commands in another terminal:geth attach
admin.peers
net.peerCount
admin.peers returns the other nodes you are connected to (these are the other Generals or messengers). net.peerCount is the total number of connections in you have.
VERY HIGH LEVEL OVERVIEW OF HOW A TRANSACTION WOULD WORK
Now let’s say you made a transaction of 2 Ethers (what Ethereum currency is called) to someone. You would have to communicate that transaction via messengers (master nodes, light nodes and other full nodes). These messengers will validate the transaction and also pass it on like gossip until it reaches all active nodes. Each node has a waiting area called a Mempool. Here the unconfirmed transaction (transaction that has not passed global consensus) will wait till someone (a.k.a miner/ validator) runs a specific consensus algorithm on the transaction known as Proof of Work (PoW) / Proof of Stake (on the Ethereum Beacon chain). Only after this is done successfully will your 2-Ether transaction join a block. Now everyone has agreed that the 2 Ethers belong to your recipient, so they have ownership.
Note that the majority of all Ethereum nodes would have to agree (come to a consensus) that you actually own the money you want to spend before the transaction is considered successful. This is all engrained within the consensus algorithm.
In summary the Byzantine Generals’ problem is a spot on analogy. Generals have to agree on how to take a city and the only way is via messenger gossip. In the same way, your computer now has to agree with other computers over a transaction you have made. And the only way is by peer-to-peer gossip. Any node (computer) connected to the Ethereum network could be Honest, Semi-honest or Dishonest. Anyone could be a traitor sending fraudulent transactions . Understanding this problem is therefore, crucial.
The Byzantine Generals Problem is crucial because, it provides a simplified representation of the real world consensus problems in decentralisation. Any solution to this problem could be directly translated into a real world Blockchain solution. It has immense value.
Note that, the Byzantine Generals’ Problem will rarely occur in modern warfare simply because there is a trusted central command and control that gives instructions via satellite phone or some other communication channel, thus helping coordinate the execution of the required military tactics.
Similarly the Byzantine General problem typically occurs in decentralised networks NOT networks with a centralised command and control system.
CONCLUSION
I would like to conclude by asking you to take a look at the first image under the “words are inefficient” section of this episode again. You should have:
- Understood the Byzantine Generals’ Problem as another perspective to consensus problems. The other perspective you understood is the Bread & Cake blockchain.
- Understood how all these puzzle pieces hold together.
You should also be asking yourself questions like:
- What is Blockchain Trilemma?
- What is CAP Theorem?
- And what are these consensus categorisations?
In the next 2 episodes, we complete the foundational big-picture knowledge part of this series. Thus, we answer the 3 questions above: Blockchain Trilemma, CAP Theorem and consensus categorisation and how it fits.
The expected result after Episode 5 is that: you should be able to pick any blockchain randomly and put it in this mental framework (the image under the Words are Inefficient section) . Thus just inputting the different variables and configurations into the different sections of the image and quickly arriving at the specific blockchains pros and cons, possible improvements and which area need a deeper dive.
Once the foundational knowledge is complete, we can move on to even more interesting topics such as BFT and eventually translating this into our own experimental Blockchain solution.
Catch you later!
About Naoris Protocol
Naoris Protocol is a Decentralized CyberSecurity Mesh for the hyper-connected world. Our disruptive design pattern makes networks safer as they grow, not weaker, by turning each connected device into a trusted validator node. A robust Blockchain protocol that every company can use to protect against the escalating levels of cyber threat.
Devices are rewarded for trusted behavior fostering a secure environment. Participants earn $NAORIS staking rewards for securing the network.
The more users, businesses, and governance structures that use the Decentralized Cyberecure Mesh, creating networks of networks, the stronger and more secure it becomes.
Want to learn more about it?
Visit our Website or check out our Whitepaper
