Interoprebility in Blockchain Using Cosmos and Tendermint protocol

What is Cosmos Blockchain?…

What is Cosmos Blockchain? The Most Comprehensive Guide. The world was turned upside down when Satoshi Nakamoto published theBitcoin whitepaper back on October 31, 2008. Among many things, Bitcoin introduced the world to the blockchain technology. Ever since then, the floodgates have opened, blockchain technology has been adopted by some of the biggest companies in the world. Ethereum showed the world the versatility of blockchain technology.

However, with fast adoption comes problems. The problems come in the fields of scalability and interoperability. Cosmos Blockchain, is looking to solve all these and bring blockchains to the next level Before we acquaint ourselves with Cosmos, let’s take a closer look at the Scalability and Interoperability problem.

What is Cosmos Blockchain? Most Comprehensive Guide

The Scalability and Interoperability Problem

Problem #1: Scalability

For bitcoin and ethereum to compete with more mainstream systems like Visa and PayPal, they need to seriously step up their game when it comes to transaction times. While PayPal manages 193 transactions per second and visa manages 1667 transactions per second, Ethereum does only 20 transactions per second while bitcoin manages a whopping 7 transactions per second! The only way that these numbers can be improved is if they work on their scalability.

Now there have been many possible solutions to the scalability problem like:

• Segwit.
• Lightning network/Raiden.

However, while both can be useful, they have their own disadvantages.

Segwit is a vertical scaling solution, meaning that it is extremely dependent on the physical capabilities of one single machine. Lightning Network, on the other hand, is a brilliant payment system, however, it can only handle microtransactions as of right now.

Problem #2: Interoperability

Let’s look at the current ecosystem. In the cryptosphere, we have different crypto coins such as Bitcoin, Ethereum, Litecoin etc. Similarly, in the legacy financial world, we have systems like the traditional Banks which use SWIFT, ACH etc.

The problem lies in the fact that it is extremely difficult for these individual entities to communicate with one another. It is tough for bitcoin to know what is going on in Ethereum and vice-versa. More often than not, these blockchains become silos and rarely share any information with each other. We do have solutions like atomic cross-chain swap however, that is not true interoperability.

It becomes doubly difficult when banks try to communicate with the cryptos.

This is why, the crypto exchanges, which provide a portal between cryptos and banks become so powerful and important. However, there in itself lies a problem. Exchanges are not a decentralized entity and are extremely vulnerable.

• They can get hacked.
• They can blackout for long periods for system upgradation.

Plus, there is another area where this miscommunication between the legacy world and the crypto world can lead to a disastrous result:ICOs.

In ICOs, an entity gets millions of dollars in exchange for their tokens, however, saving that money in their bank accounts can become difficult. The banks would obviously want to know where all that money came from and who were the ones who provided that money which is something that is near impossible to provide.

Cosmos Blockchain is the Solution

Cosmos aims to become an “internet of blockchains” which is going to solve these problems once and for all. Cosmos’ architecture consists of several independent blockchains called Zones” attached to a central blockchain called “Hub”.

According to the Cosmos whitepaper:

“The zones are powered by  Tendermint Core, which provides a high-performance, consistent, secure PBFT-like consensus engine, where strict fork-accountability guarantees hold over the behavior of malicious actors. Tendermint Core’s BFT consensus algorithm is well suited for scaling public proof-of-stake blockchains.”

Before you go any further into the details, let’s meet the team.

 

Tendermint: The Fuel that Runs Cosmos Blockchain

Tendermint is a variant of PBFT i.e. Practical Byzantine Fault Tolerance.

A Byzantine Fault Tolerance or BFT system is a system which has successfully answered the Byzantine General’s Problem.

What is the Byzantine Generals Problem?

Ok so imagine that there is a group of Byzantine generals and they want to attack a city. They are facing two very distinct problems:

• The generals and their armies are very far apart so centralized authority is impossible, which makes coordinated attack very tough.
• The city has a huge army and the only way that they can win is if they all attack at once.

In order to make successful coordination, the armies on the left of the castle send a messenger to the armies on the right of the castle with a message that says “ATTACK WEDNESDAY.” However, suppose the armies on the right are not prepared for the attack and say, “NO. ATTACK FRIDAY” and send back the messenger through the city back to the armies on the left

This is where we face a problem.

A number of things can happen to the poor messenger. He could get captured, compromised, killed and replaced with another messenger by the city. This would lead to the armies getting tampered information which may result in an uncoordinated attack and defeat.

This has clear references to blockchain as well. The chain is a huge network; how can you possibly trust them? If you were sending someone 4 Ether from your wallet, how would you know for sure that someone in the network isn’t going to tamper with it and change 4 to 40 Ether?

What these generals need, is a consensus mechanism which can make sure that their army can actually attack as a unit despite all these setbacks. Tendermint happens to be one of these consensus mechanisms.

Another property of Tendermint which makes it a good BFT algorithm is its fork accountability. Bitcoin’s and Ethereum’s system (as of right now) is not really the most fork-accountable. Forks keep on happening in Bitcoin such as we have seen with Bitcoin and Bitcoin Cash and we all know about the infamous ETH-ETC split.

Having a system which is fork accountable makes sure that malicious actors don’t cause a split in the system through their actions. This also reduces the chances of a double-spend attack.

Defining some Terms in Tendermint

Tendermint is a BFT consensus mechanism which is simple, has high performance, and is fork-accountable.

Let’s first familiarize ourselves with some of the terms that we will be using:

• A network composes of a lot of nodes. Nodes that are connected to a particular node are called its peers.
• The consensus process takes place at a particular block height H. The process to determine the next block consists of multiple rounds.
• The round consists of many states which are: NewHeight, Propose, Prevote, Precommit, and Commit. Each state is called a Roundstep or just “step”.
• A node is said to be at a given height, round, and step, or at (H,R,S), or at (H,R) in short to omit the step.
• To prevote or precommit something means to broadcast a prevote vote or precommit vote for something.
• When a block gets >2/3 of the prevotes at (H,R) then it is called proof-of-lock-change or PoLC.

What is the State machine?

The state machine is the engine of the Tendermint protocol so to speak. The following diagram gives you a good idea of what it will look like:

Ok, so what is going on here?

Remember the states that each round goes through? NewHeight, Propose, Prevote, Precommit, and Commit.

Of these, “Propose, Prevote, Precommit” consist of one round while the other two are special rounds. In an ideal scenario, the state transition would act like this:

NewHeight -> (Propose -> Prevote -> Precommit)+ -> Commit -> NewHeight ->…

However, that’s not how it may always work. Multiple rounds may be required before the block is committed. The following are the reasons why multiple rounds may be needed:

• The designated proposer maybe absent.
• The block proposed maybe invalid.
• The block didn’t propagate in time.
• >2/3 of prevotes weren’t received in time by the validator nodes.
• Even though +2/3 of prevotes are necessary to progress to the next step, at least one validator may have voted <nil> or maliciously voted for something else.
• >2/3 of precommits for the block weren’t received even though prevotes may have been received.

What happens during each state?

Alright… so now let’s look into each and every state and see how the whole thing comes together.

Propose

In this stage, the designated proposer, i.e. the node selected proposes a block to be added at (H, R). This stage ends in one of two ways:

• The block gets proposed and that enters the prevote stage.
• The proposer’s time to choose the block expires upon which it enters the prevote stage anyway.

Prevote

Now we come to the prevote stage. In this stage, every validator needs to make a decision.

• If somehow, the validator is locked on a proposed block from some previous round, they automatically sign off and broadcast that block.
• If the validator had received an acceptable proposal for the current round, then they sign and broadcast a prevote for the proposed block.
• However, if they find something fishy with the proposal or have not received any proposal at all (eg. if the proposer’s time runs out), then they sign with a “nil” prevote.
• No block-locking happens during this stage.
• During this period, all the nodes propagate the prevotes throughout the system via the gossip protocol.

Precommit

Now we enter the final step of the “round” called “precommit.” Upon entering this stage, the validators precommit to their decision by broadcasting their prevotes. One of the following three scenarios can happen

• If the validator receives >2/3 of the prevotes for a particular acceptable blocks then the validator signs off and broadcasts their precommit to the block. They also get locked on to that block. One validator can lock on to only one block at a time.
• However, if the validator receives more than 2/3rd of NUL prevotes then they unlock and precommits turn to “NIL”.
• Finally, if they haven’t received a super majority of 2/3rd at all then they don’t sign off or lock on anything.

Throughout this stage, the nodes keep on continuously gossiping about the precommits throughout the network.

In the end, if the proposed block gets more than 2/3rd precommits then we move towards the “Commit” step. However, if they don’t reach that stage then they enter the “Propose” stage of the next round.

Commit

The Commit state isn’t a part of the “round”. Along with NewHeight, it’s one of the two special rounds. During the commit state, two parallel conditions are checked to see if they are getting fulfilled or not.

• Firstly, the validators must receive the block that has been precommitted by the network. Once that is done, they sign off and broadcast their commitment.
• Secondly, they must wait until they have received at least 2/3rdprecommits for the block.

Once this is done, the block gets committed to the network.

NewHeight

Simply increments block height by 1 to show that the block has been added.

Choosing the Validators

As you may have understood by now, choosing the initial set of validators is critical for Cosmos to function. So, how exactly they are going to be chosen?

Unlike Bitcoin where anyone can become a miner anytime, there is only so many validators that the Tendermint system can take in. Since validators will individually need to do a lot of functions, increasing the count of validators will only lead to delay.

This is why Cosmos decided to choose 100 validators during Genesis day (i.e. the day of the fundraiser.) The number of validators will increase by 13% every year till 10 years when it will settle on 300.

So…is Tendermint any good?

As the cosmos whitepaper states:

“Tendermint provides exceptional performance. In benchmarks of 64 nodes distributed across 7 datacenters on 5 continents, on commodity cloud instances, Tendermint consensus can process thousands of transactions per second, with commit latencies on the order of one to two seconds. Notably, the performance of well over a thousand transactions per second is maintained even in harsh adversarial conditions, with validators crashing or broadcasting maliciously crafted votes.”

The graph below support the claim made above:

Benefits of Tendermint

• Tendermint can handle transaction volume at the rate of 10,000 transactions per second for 250byte transactions.
• Better and simple light client security which makes it ideal for mobile and IoT use cases. In contrast, Bitcoin light clients require a lot more work and have lots of demands which makes it impractical for certain use cases.
• Tendermint has fork-accountability which stops attacks such as long-range-nothing-at-stake double spends and censorship.
• Tendermint is implemented via Tendermint core which is an “application-agnostic consensus engine.” It can basically turn any deterministic blackbox application into a distributedly replicated blockchain. 
• 
  
• Tendermint Core connects to blockchain applications via the Application Blockchain Interface (ABCI).

The Hub and The Zones: The Heart of Cosmos Blockchain

As noted earlier, Cosmos’s architecture will follow the Hub and Zones method. There will be multiple parallel blockchain connected to one central Hub blockchain. Think of the Sun and the solar system.

The Cosmos hub is a distributed ledger where individual users or the Zones themselves can hold their tokens. The zones can interact with each other through the Hub using IBC or Inter Blockchain Communication.

Obviously, since the Hub plays such a critical role in the Cosmos blockchain system, its security is extremely important. Because of this, it is secured by a globally decentralized group of validators. This set can withstand attacks as severe as continental network partition or a nation-state sponsored attack.

Now, connected to the Hub are the Zones.

The Zones interact with the Hub using IBC packets. The validators of the Zones must stake a certain amount of Atom tokens inside the hubs. If in case, the zone starts acting maliciously, then their staked Atom gets slashed.

Alright, so now we know what the Hub and Zones are, let’s see how they interact with each other using IBC.

How does IBC in Cosmos work?

Image Credit: GitHub

In order to best understand how Inter Blockchain Communication in Cosmos will work, let’s look at a working example. Consider you have three blockchains:

• Hub.
• Zone 1.
• Zone 2.

Suppose Zone 1 wants to interact with Zone 2 via Hub by sending a message called a “packet.” How will this work out?

• A proof is posted on Zone 2 i.e. the receiving chain which states that Zone 1, the sending chain, is sending a package to Zone 2.
• For Zone 2 to be able to receive the proof, it must be able to keep up with Zone 1’s block headers.
• The IBC gets split into two transactions: An IBCBlockCommitTx transaction which enables the blockchain to prove to any observer its most recent block-hash.
• The second transaction is the IBCPacketTx which allows the blockchain to prove that the given packet was indeed sent by the sending chain via a Merkle-Proof to the recent block hash.

So why do we do this? Why do we split up the IBC into two parts?

In Cosmos, the zones are meant to have independent token models, economics and governance system. That sounds pretty cool, but what does that have to do with this?

Splitting up the IBC into two parts allows the native-fee-market mechanism of Zone 2 to determine which packets get committed without imposing any restrictions on Zone 1 as to how many packets they can send.

Think of a trade between two countries. Suppose Country A is sending some iron, coal, and gold to Country B. Unbeknownst to A, B has banned the use of coal. Via going through a hub say Country C, A can send whatever they want and B can receive whatever they want to receive.

The Atom Token

The native token used in the Cosmos blockchain will be Atom. Atom is not designed to be a medium of exchange nor a store of value. It will be used purely for staking on the Cosmos blockchain.

According to Smith+Crown, “The Atoms available in the crowdsale will not immediately be liquid: once created, they will vest at a constant rate per hour over the course of two years. Given the vesting rate over two years, if the sale raises $5 million and creates approximately 625,000 Atoms, they will vest at a rate of 35.6 Atoms per hour.”

Cosmos had their fundraiser on 6th April 2017 and raised 4.87k BTC/246.89k ETH and a total of 168,475,963 ATOM were issued.

During the fundraiser, the ATOMs were distributed as such:

• ICF (10%)
• AIB (10%)
• Initial Donors (5%)
• Pre-Fundraiser Donors + Fundraiser Donors (75%).

Transaction fees in Cosmos

Since the zones can have their own native tokens, the hub validators can accept any token or any token combination they want as their transaction fees. The exchange rate will also be up to the validators to set as they see fit as long as the gas limit of the block isn’t exceeded.

Of the fees collected, 2% goes to the reserve pool, while the rest gets distributed among the validators in proportion to their stake.

Cosmos Blockchain Governance

As you can imagine, with a system like Cosmos, having a strict governance model is absolutely essential. The validators will be responsible for the overall well-being and health of the system. Changes in the Cosmos ecosystem is done via voting by the validators. There are certain conditions that need to be met before voting can happen:

• Validators must stake a certain amount of tokens, which could be ATOM of any other token or a combination of various tokens.
• If the validators don’t vote for a proposal in a timely manner, then they will be punished by being deactivated for a certain period of time.

For each proposal, the voters may vote with one of the following:

• Yea
• YeaWithForce
• Nay
• NayWithForce
• Abstain.

Based on the votes, the following scenarios are possible:

• If the proposal gets a strict majority of Yea or YeaWithForce, the proposal is passed.
• If the proposal gets a strict majority of Nay or NayWithForce, the proposal is dropped.
• >1/3 of the voters can, however, veto a majority decision “with force”.
• If a strict majority is vetoed, everyone participating gets punished by losing 1 day’s worth of block fees. Furthermore, the party that vetoed the majority decision will be punished by losing 0.1% of its ATOMs.

Cosmos Blockchain Use Cases

Cosmos has some extremely interesting use-cases”

• DEX: Since Cosmos Blockchain is linking so many blockchains with each other, it goes without saying that it can easily enable different ecosystems to interact with one another. This a perfect setting for a decentralized exchange.
• Cross chain transactions: Similarly, one zone can avail the services of another zone through the Cosmos hub.
• Ethereum Scaling: This is one of the more use cases. Any EVM based zone which is connected to the Cosmos hub will be, as per the architecture, powered by the Tendermint consensus system as well. This will enable these zones to scale up faster.

Cosmos Blockchain: Conclusion

Cosmos and Tendermint are both some of the most interesting projects out there. They are bringing in a whole new level of scalability and interoperability to blockchains, something that it desperately needs right now. Only time will tell how it will hold up to some of its competitors in the interoperability space like Cardano, AION, ICONetc.

However, the tech is definitely intriguing and they seem to have a very passionate and dedicated team behind them. Let’s hope that they get all their implementations in place. For faster mainstream adoption, the scalability and interoperability issue needs to be solved. Maybe Cosmos Blockchain will pave the way.