Previously on Episode 3 of “The Magic Behind Blockchain”…

• we worked through the Byzantine Generals’ Problem
• we connected the Byzantine Generals’ Problem to the real world by setting up an Ethereum node
• we created a framework for visualising everything we have learnt so far

Today, we improve upon the framework / mind map from the previous episode. Additionally, we build up our understanding, even further, on some of the missing puzzle pieces from the previous mind map.

VERSION 1 OF MIND MAP / BLOCKCHAIN FRAMEWORK

In version 1 of the mind map above, we explained every puzzle piece EXCEPT:

1. Blockchain Trilemma,
2. CAP Theorem, and
3. Consensus Categorizations

Let’s fill in the gaps …

THE TRADE-OFF (COST) OF USING BLOCKCHAIN (CAP THEOREM)

The whole point of consensus is usually to arrive at some data (or action) you can agree on. Like how much Bitcoin / Ethereum is in a wallet, who owns what coins, or which house belongs to whom if you use blockchain in property ownership.

The business layer of this essentially deals with assets (crypto-currency, physical assets, intellectual property, etc.) or smart contracts

You have to store and retrieve all this data somehow. Therefore, it is natural to have some expectations on data storage (content layer)(whether it is blockchain or local).

What exactly are these expectations?

1. We expect that, whenever you query for some data, it would be available. The data store is simply not allowed to be unavailable. Every request must receive some response. Let’s call this requirement “Availability”.
2. Any results you get from the database will be correct information and relevant to the timeline (so not outdated information). For example: If you just deposited 50,000 euros into your bank account, the bank database shouldn’t be reflecting this in the database 1 year later. Whenever you use your bank app, your should be able to see your current balance. Thus, query responses must contain fresh values. Simply, the database needs to be consistent. Let’s just call this expectation / requirement “Consistency”. Note that this is not the same Consistency from ACID in Relational Databases.

You should also note that there are some inherent advantages of using centralised servers, which are lost when you shift to the decentralised world. This is why blockchain is not always the magic fairy dust for every computing problem.

The most important advantage here is that when your server is centralised, especially locally on your machine, you can guarantee both Availability and Consistency simultaneously. If the bank app is not working, the entire database fails as a whole NOT parts of it. This means, if it fails, you lose both Availability and Consistency (so at least you don’t have wrong data). And if it succeeds, you have the correct / consistent data also available most of the time.

3. Immediately you start dabbling with Distributed data storage / blockchain, all bets are off! No distributed system is safe from network failures. Remember, there is no central storage. After all, we said a central storage / node is hard to trust. Every computer / node in the network stores its own version of the data; and may or may not be trusted to send correct data.

This introduces a tricky problem. Some of the computers in the network may fail while others are working. A sort of partial failure of the network. Blockchains must be able to tolerate these partial failures. Let’s call this Partition Tolerance. (so the focus is tolerating a partition of the network that has failed).

Whenever a part of the network fails, you are forced to make a choice:

1. Cancel all operations until all nodes are working so that you have consistent data. In this case, you choose Consistency over Availability. Relational Databases (RDBMS) like MySql, Microsoft Sql, PostgreSql, etc. usually use this philosophy. But Imagine using this philosophy for Ethereum. If some nodes fail in the Ethereum network (which happens rather often), well everything will be halted. This will result in very lengthy transaction times. So not desirable for blockchain.
2. At least, proceed with the data you have from the nodes which are currently active even if they are NOT consistent. Here, you choose Availability and risk inconsistency. This is where blockchains like Bitcoin fall. Consensus algorithms are just used to compensate for the Consistency expectation.
   For example, immediately you make a valid Bitcoin transaction, you are not sure whether it is committed or not. However, as time goes on, you become more and more confident. This is because after you issue the transaction, the transaction will be relayed to the world in a matter of seconds making it difficult to reverse (See BitUndo). After 5 minutes, the transaction will be inserted into a block (There is a 1 in 1000 chance that the block your transaction falls in doesn’t end up in the blockchain). Eventually, even transactions in orphan blocks are resolved. The longer you wait, the more blocks pile on top of the block your transaction is placed in; making it more permanent. After about 5 hours, you are good to go. Till date no transaction more than 5 hours old has ever been rolled back.

So this system which prioritised availability over consistency becomes eventually consistent with the consensus algorithm.

To summarise:

1. Whenever you choose to have a Partition (set of unreliable nodes), you have to choose between Consistency and Availability but not both. So you can have Consistency + Partition Tolerance = (CP) or Availability + Partition Tolerance = (AP)
2. You can only choose both Consistency and Availability = (CA) when there is no Partition.
3. Guaranteeing all 3 (Availability, Consistency and Partition Tolerance is just astronomically unlikely.

In simpler terms: Between Partition Tolerance, Availability and Consistency, you can only choose 2 out of 3. And this is what was formulated beautifully by Eric Brewer as the CAP (Consistency, Availability, Partition tolerance) Theorem.

You can find a visual aid below as well as current software solutions that provide the different combinations of Consistency, Availability and Partition Tolerance.

You noticed that during the entire CAP Theorem talk, we focused mainly on nodes, storage and network. These cover the lower 3 layers of our blockchain framework (Physical, Peer-to-Peer and Content Layer). Together we can abstract them away and call them the Infrastructure layer.

Throughout this process, nodes will communicate mostly via Remote Procedure Calls (RPC), REST APIs, Web APIs, fancy OS Pipes (IPC), etc. This is mostly happening at the Peer-to-Peer layer, Content Layer and Consensus Layer. Let’s abstract this and call it the Platform Layer

DESIGN OBJECTIVES OF BLOCKCHAIN

The last thing we would look at today is the Blockchain Trilemma. When you come across a blockchain solution, you should also ask yourself:

In the big picture, what objective exactly is this blockchain solution trying to achieve?

There are 3 targets most blockchains try to hit: Security, Scalability (Speed), and Decentralisation.

1. SECURITY — Security in a blockchain means, the entire blockchain architecture should be able to defend itself from intentional, unintentional, direct and indirect attacks targeted at all 6 layers (See Episode 1 for details on the layers). The right devices operate expectedly at the physical layer, secure P2P connections, attack-resistant consensus protocols, secure coding implementation of data structures at the content layer (including smart contracts), properly tested and vetted cryptographic primitives and advanced protocols.
2. SPEED & SCALABILITY — How many transactions per second can the blockchain handle? As a point of reference VISA can handle 65,000 transactions per second (TPS) (at the time of writing) and it does relatively well at handling its global transaction demand. Just to put this in perspective, Bitcoin does maximum 10TPS, Ethereum does max 34TPS, Cardano does about 250TPS.
3. DECENTRALISATION — This objective is all about control. The locus of power in any node must just be enough to keep the consensus algorithm secure. Not more! If any node has too much undue power / control of the entire network, this is problematic; whether or not the control is currently being used for a good purpose or not. Some facts to consider: About 12.3% of all Bitcoin sits in crypto exchanges (see more details here). These exchanges usually require KYC (Know Your Customer before allowing you to use their platforms). So your coins are most likely not that anonymous. If you take a look at BTC pool stats, the top 10 mining pools control about 90% of all the mining capacity. So not all decentralizations are created equal.

There is a community of crypto enthusiasts who harbour the fear that one day these pools will gang up and collectively decide to approve a rogue chain (51% attack). Because they have the controlling vote, this is, in theory, possible. However, the game theory also has a counter argument which is that: if that action ever takes place, all trust in crypto will be lost anyway, and the rogue coalition would have set a dangerous precedent; making any new crypto chain they create lose all value very rapidly. (They would have literally seconds to reap this benefit before the value of the entire blockchain comes crashing down). This is a sort of mutually assured destruction.

Why is this a Trilemma?

We call it a Trilemma because it takes a lot of precision to get a good balance of these 3 (Security, Scalability and Decentralisation). Most blockchains do very well in some aspect(s) and lack in others. Note that, what you prioritise here depends on the use case of the particular blockchain solution.

In order to have the best security, you need to know, limit and control your attack vectors. This is the antithesis of scalability and decentralisation. Scalability almost always has to add new attack vectors, many of which are potentially unknown and uncontrolled / uncontrollable. Without the right foundation, your security won’t be able to catch up to the speed of your blockchain growth. In other words, you will NOT be able to keep up with your own success!

Decentralisation also has a speed trade-off. More decentralisation means more people having control of what happens in the network. This also means, normally, it takes longer to arrive at a consensus and hence less transactions per second. Less speed.

MAKING IT A QUADRILEMMA

It is by no means impossible to achieve all 3 parts of the Trilemma, however, it is definitely unlikely to happen by accident. In the first image in this article, we have represented the Trilemma in a pyramid. This is because, in my personal opinion, security, speed and decentralisation are not equally weighted. And one may be a stepping stone to the other.

Recently there have been solutions such as ZK Roll Ups, Sharding, separating main chain and creating side chains, etc. All in attempts to increase the speed of the networks while maintaining the security and decentralisation components.

However this introduces a new problem of Durability. Here we introduce a “Durability rule”. It goes like this:

If you create any sub-process (sub-chain or component) in order to function as a supporting oracle to the blockchain (especially consensus layer), you have to ensure that this sub-process is a non-blocking operation.

Because if the side chain stops, there is no way to determine its state and respond, in a concerted way, with the information on the main chain. This is quite similar to problems you will face with multi-threading and multi-processing and Inter-Process communication at the Operating System level. Except this time everything has to be done in consensus.

Please note that Durability itself is NOT a part of the Blockchain Trilemma as introduced by Vitalik Buterin around 2016. However, Naoris Protocol sees this as an important extension of the Trilemma. Hence the term, Quadrilemma.

CONCLUSION

Let’s conclude with the updated mind map below:

Version 2 of Mind Map

Change Log:

• At the top, we have added the business layer we talked about; which is made up of assets and contracts.
• On the left, we explained the Blockchain objectives, Blockchain Trilemma and the need for Durability (Making it a Quadrilemma).
• In the middle, we have expanded the blockchain architecture by adding 4 abstractions (Infrastructure layer, Platform Layer, Computation Layer and Operating Architecture) to the blockchain architecture layer. The 6 main layers explain what the blockchain IS. The abstractions talk about WHAT the blockchain DOES or HOW it does it.
• On the right, we have also now talked about the limitations on data storage in blockchains and how it affects speed and consensus. This is the CAP Theorem technically operating most at the Content Layer.
• Also we know from Episode 2 that any consensus algorithm mostly deals with some participants (participating nodes). They are usually validators, miners or clients. This is shown on the right side of the image.

A game to play next time you hear of a new blockchain …

Try to put it into this updated framework. Ask yourself:

1. How does this blockchain do Decentralisation, what is its speed, and are there any security features? Will there be a Durability problem?
2. Ask yourself what exists at each layer of this Blockchain’s architecture.
3. Are they promising you 99.99% availability and consistency simultaneously? How do they deal with partitions then?
4. Finally delve into the specific consensus protocols they use.

If you are able to distill a blockchain like Bitcoin, Ethereum, etc into its various components as shown in the framework, congratulations!! Now you see the matrix.

Usually you should find all this information in the associated whitepapers and yellow papers.

In the next episode, we cover the missing parts of our mind map (framework): Consensus categorisations, Computation layer and Operating Architecture.

We are almost at the end of the fundamentals (basic part) of blockchain (Episode 1 to Episode 5). Hang in there! More exciting stuff ahead. :)

‍