Cosmos Blockchain: Ultimate Guide Below!

The world was shook after the Bitcoin White Paper was written by Satoshi Nakamoto on October 31, 2008. Bitcoin has, among other others, opened the world to blockchain technologies. Since then, floodgates have opened, blockchain technology has been embraced by some of the biggest corporations in the world. Ethereum has showed the world the power of blockchain technologies.

However, there are issues with accelerated adoption. Problems exist in the fields of scalability and interoperability. Cosmos Blockchain is trying to overcome all of these and push blockchains to the next level. Before we get to learn Cosmos, let’s take a closer look at the problem of Scalability and Interoperability.

What is Cosmos Blockchain? Most Comprehensive Guide

Scalability and Interoperability

Issue # 1: Scalability

For bitcoin and ethereum to contend with more popular systems like Visa and PayPal, they need to really step up their game when it comes to transaction times. Although PayPal manages 193 transactions per second and Visa manages 1667 transactions per second, Ethereum performs just 20 transactions per second, while Bitcoin manages 7 transactions per second! The only way these numbers can be strengthened is by focusing on their scalability.

There have also been several potential solutions to the problem of scalability, such as:

• Segwit.
• Lightning network/Raiden.

However, though they can all be helpful, they have their own drawbacks.

Segwit is a vertical scaling method, which means that it is highly dependent on the physical capability of a single system. Lightning Network, on the other hand, is a great payment system, but it can only accommodate microtransactions right now.

Issue # 2: Interoperability

Taking a look at the current environment, we have various crypto coins in the cryptosphere, such as Bitcoin, Ethereum, Litecoin, etc. Similarly, in the legacy financial world, we have structures such as the traditional banks that use SWIFT, ACH, etc.

The concern is that it is extremely difficult for these different institutions to interact with each other. It’s rare for bitcoin to learn what’s going on in Ethereum, and vice versa. More frequently than not, these blockchains are silos and only exchange details with each other. However, we do have options such as atomic cross-chain exchange, which is not genuine interoperability.

It’s twice as complicated when banks want to connect with cryptos.

That’s why crypto exchanges, which provide a gateway between cryptos and banks, are becoming so powerful and significant. There is, indeed, a question in itself. Exchanges are not a decentralized body and are particularly vulnerable.

• They might get hacked.
• They will blackout for long stretches of system update.

In fact, there is another area where this miscommunication between the legacy world and the Crypto universe can lead to a catastrophic outcome: the ICOs.

In ICOs, an individual earns millions of dollars in return for their tokens, but keeping the money in their bank accounts can be difficult. The banks will naturally like to know where all the money comes from, and who were the ones that supplied the money, which is something that is almost impossible to do.

Cosmos Blockchain is the Solution

Cosmos strives to become a “internet of blockchains” that can address all challenges once and for all. The architecture of Cosmos consists of multiple separate blockchains called “Zones” connected to the main blockchain called “Hub”.

As they state on the Cosmos whitepaper, the zones are operated by Tendermint Core, which offers a high-performance, reliable, stable PBFT-like consensus engine where strict fork-accountability guarantees hold over malicious actors’ behaviour. Tendermint Core’s BFT trust algorithm is well-adapted for scaling blockchain’s that are public proof-of-stake.

The Crew That Made Blockchain Cosmos

Cosmos is sponsored by the Interchain Foundation (ICF). The Tendermint team has been hired by the ICF for production.

Here’s a brief snapshot of the ICF and Tendermint teams:

Tendermint and, by extension, Cosmos have a brilliant team behind them. Let’s see the key players:

Jae Kwon: He is the CEO and founder of Tendermint. He had earlier co-founded the “I done this” collaboration app for teams. He has also made a number of contributions to multiple projects, including Scramble.io, Flywheel networks and Yelp.

Ethan Buchman: CTO and co-founder, has a University of Guelph Master’s degree and 2+ years of experience as a research scientist. His first job in blockchain was with Eris Industries in 2014.

Peng Zhong: The head of design. He is a self-described autodidact with 7+ years of experience as a full-stack JavaScript developer for Nylira, a web development company he founded.

Tendermint: The Fuel That Powers Cosmos Blockchain

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

The Byzantine Fault Tolerance or BFT system is a system that has successfully solved the Byzantine General’s problem.

The Byzantine Generals Situation

Okay, so assume that there’s a bunch of Byzantine generals and they want to invade the city. They face two very distinct problems:

• The generals and their armies are so far apart so that unified control is impractical, which makes a coordinated attack so difficult.
• The city has a vast army, and the only way they can win is by fighting all together at once.

In order to have good communication, the armies on the left side of the castle send a messenger to the armies on the right side of the castle with a message that says “ATTACK WEDNESDAY.” But, imagine the armies on the right are not ready for the assault and say, “NO. ATTACK FRIDAY “and send the messenger back to the army on the left through the streets. This is where we have a challenge.

A variety of things could happen to the messenger. He could be arrested, betrayed, killed and replaced by another city messenger. This would lead to the armies having their info tampered with, and that could end in an uncoordinated assault and defeat.

This has many strong ties to blockchain. The chain is a vast network; how could you possibly trust it? If you sent anyone 4 Ether out of your wallet, how would you know for sure that someone on the network is not going to tamper with it and shift 4 Ethers to 40?

What these generals need is a compromise structure that can guarantee that their army will actually attack as a unit after all these setbacks. It just so happens that Tendermint is one of those consensus structures.

Another Tendermint property that makes it a good BFT algorithm is its fork accountability. The framework of Bitcoin and Ethereum (as of right now) is not really the most fork-accountable. Forks are still going on in Bitcoin, as we have seen with Bitcoin and Bitcoin Cash, and we all heard about the notorious ETH-ETC break.

Having a system that is fork-accountable means that the malicious actors do not allow the network to be broken by their actions. This also reduces the chance of a double-spending attack.

Defining some Terms in Tendermint

Tendermint is a simple, high-performance BFT consensus framework that is fork-accountable.

Let’s first get familiar with some of the terminology we’re going to use:

• The network consists of a number of nodes. Nodes that are connected to a single node are referred to as peers.
• The negotiation process takes place at a common block height H. The method of deciding the next block consists of multiple rounds.
• The round consists of a variety of states: NewHeight, Propose, Prevote, Precommit, and Commit. Every state is called a Roundstep, or just a “step”.
• The node is said to be at a given height, round, and step, or at (H, R, S), or at (H, R) in short to escape the jump.
• To pre-vote or pre-commit is to announce a pre-vote vote or to pre-commit a vote on something.
• If a block gets > 2/3 of the pre-votes at (H, R) then it’s called proof-of-lock-change or PoLC.

What is the State Machine?

The state machine is the Tendermint protocol engine, so to speak. The following diagram gives you a clear idea of what it is going to be like:

Okay, so what’s going on here?

Can you recall the states that every round is going through? NewHeight, Propose, Prevote, Pre-commit, and Commit.

Of such, “Propose, Prevote, Precommit” consists of one round, while the other two are particular rounds. In the optimal case, the state change will be something like this:

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

But, that’s not how it would always function. Multiple rounds can be needed until the block has been committed. The following are the reasons why multiple rounds may be needed:

What happens in every state?

Okay, so now let’s look at each and every situation and see how the entire thing comes together.

Propose

A block to be inserted at (H, R) is suggested at this point by the appointed proposer, i.e. the node chosen. This stage finishes in one of two ways:

• The block is proposed and it begins the prevote stage.
• The time of the promoter to pick a block expires as he reaches the prevote stage anyway.

Prevote

Now we’re heading to the prevote stage. Every validator needs to make a decision at this point.

• If the validator is locked on a proposed block from a previous round, it will immediately sign off and broadcast the block.
• If the validator has obtained an appropriate proposal for the current round, they must sign and broadcast a pre-vote for the proposed block.
• However, whether they consider anything fishy about the proposal or have not obtained a proposal at all (e.g. because the time of the sponsor has elapsed), then they sign with the “nil” prevote.
• At this level, no block-locking happens.
• During this time, all nodes spread the prevotes across the network through the gossip protocol.

Precommit

Now we begin the final phase of the “loop” called the “precommit.” After reaching this stage, the validators pre-commit to their decision by transmitting their prevotes. Each of the following three situations that arise

• If the validator receives > 2/3 of the prevotes for a different appropriate block, the validator signs off and broadcasts the preset to the block. They’re locked on the block, too. One validator will lock to only one block at a time.
• However, if the validator gets more than 2/3 of the NUL votes, it will activate and the precommits will transform to “NIL.”
• Eventually, if they haven’t earned a 2/3rd super majority at all, then they don’t sign or agree on it.

While this goes on, the nodes keep on guessing about the pre-commits throughout the network.

At the end of the day, if the proposed block gets more than 2/3rd pre-commits, then we push onto the “Commit” stage. However, if they do not hit that stage, they must join the next round’s “Propose” round.

Commit

The Commit State is not part of the “round.” It’s one of the two exclusive rounds along with NewHeight. During the commit state, two simultaneous conditions are tested to see whether or not they are being met.

• First, the validators must be supplied with a block that has been pre-committed to the network. When that has been finished, they sign and announce their pledge.
• Second, they will wait until they have earned at least two-thirds for the block pre-commits.

When this is completed, the block will be committed to the network.

NewHeight

Simply raises the height of the block by 1 to indicate that the block has been inserted.

Selecting the Validators

As you might have known, selecting the initial set of validators is essential to the operation of Cosmos. So, how exactly are they going to be selected?

Unlike Bitcoin, where anybody can become a miner at any moment, there are only so many validators that the Tendermint network can take in. Because validators will need to execute a lot of tasks independently, increasing the number of validators will only lead to a delay.

That is why Cosmos chose to select 100 validators on the day of Genesis (i.e. the day of the fundraiser). The number of validators will rise by 13 percent per year for 10 years, when it settles at 300.

So, is Tendermint a good thing?

Cosmos Whitepaper states that the Tendermint delivers exceptional performance. In benchmarks of 64 nodes distributed across 7 data centers on 5 continents, in commodity cloud instances, Tendermint consensus can process thousands of transactions per second, with commit latencies in the order of one to two seconds. Notably, the output of well over a thousand transactions a second is sustained even under extreme adverse circumstances, with validators crashing or sending maliciously designed votes.

The graph below confirms the point mentioned above:

Tendermint’s advantages

• Tendermint can manage transaction rates at a rate of 10,000 transactions a second with 250byte transactions.
• Good and easy consumer protection, making it suitable for smartphone and IoT use cases. On the other hand, Bitcoin light clients need a lot of effort and have a lot of demands that makes it inefficient in certain cases of usage.
• Tendermint has a fork-accountability that prevents threats such as long-range-nothing-at-a-stake double spending and censorship.
• Tendermint is applied via the Tendermint core, which is the “Application-Agnostic Consensus Engine.” It can basically turn any deterministic blackbox program into a distributedly replicated blockchain.

Tendermint Core connects to blockchain systems through the Application Blockchain Interface (ABCI).

The Hub and Zones: The Cosmos Blockchain Core

As mentioned above, the infrastructure of the Cosmos will adopt the Hub and Zone form. There will be several parallel blockchain connected to the main blockchain of the Hub. Think about our Sun and its Solar System.

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

Obviously, since the Hub plays such a critical role in the blockchain network of the Cosmos, its protection is extremely important. As a consequence, it is protected by an internationally autonomous network of validators. This set will withstand attacks as extreme as a continental network partition or a nation-state-sponsored attack.

Now, the Zones are linked to the Hub.

The Zones are communicating with the Hub using IBC packets. A certain number of Atom tokens must be taken by the Zone validators into the hubs. If, in the event, the zone begins to act maliciously, then its staked Atom is slashed.

Let’s see how Zones and Hubs communicate with each other using IBC.

How Does IBC in Cosmos Work?

In order to help understand how Inter Blockchain Communication can work in the Cosmos, let’s look at a working example. Know that you’ve got three blockchains:

• Hub.
• Zone 1.
• Zone 2.

Suppose that Zone 1 decides to communicate with Zone 2 via a Hub by sending a message called a “packet.” How is this going to work?

• Proof is provided in Zone 2, i.e. the receiving chain which states that Zone 1, the transmitting chain, sends a package to Zone 2.
• In order for Zone 2 to be able to receive proof, it must be able to keep up with the block headers of Zone 1.
• The IBC is split into two transactions: an IBCBlockCommitTx transaction that allows the blockchain to show its most recent block-hash to any observer.
• The second transaction is the IBCPacketTx, which allows the blockchain to prove that the packet was actually sent to the latest block hash via the Merkle-Proof chain.

And why are we doing this? Why are we breaking the IBC into two parts?

In Cosmos, the zones are supposed to have separate model tokens, economies and governing schemes. That sounds pretty cool, but what does that have to do with this?

Splitting the IBC into two sections enables the native-fee-market system of Zone 2 to decide which packets are to be transmitted without placing any limits on Zone 1 as to how many packets they can send.

Think of a trade between two nations. Suppose that Country A sends some iron, coal, and gold to Country B. Unknown to A, B, the use of steel has been banned. By going through a portal, say Nation C, A can send whatever they want, and B can receive whatever they want.

Atom Token

The original token used in the blockchain of Cosmos will be Atom. Atom is not meant to be a means of trade or a store of interest. It will be used exclusively for sketching on the blockchain of the Cosmos.

According to Smith+Crown,the atoms present in the crowdsale will not be liquid immediately: once formed, they will vest at a steady rate per hour over the course of two years. In consideration of the two-year vesting period, if the transaction collects $5 million and produces nearly 625,000 Atoms, they will vest at a rate of 35.6 Atoms per hour.

Cosmos held its fundraiser on 6 April 2017 and raised 4.87k BTC/246.89k ETH and released a total of 168,475,963 ATOMs.

During the fundraiser, ATOMs were spread as follows:

• ICF (10 percent)
• AIB (10 percent)
• Original Donors (5 percent)
• Pre-Fundraiser Donors + Fundraiser Donors (75 percent).

Transaction fees in Cosmos

Since the zones can have their own native tokens, the hub validators can accept any token or any mixture of tokens they want as their transaction fees. The exchange rate will also be fixed by the validators as they see fit, as long as the gas cap of the block is not surpassed.

Of the fees collected, 2 percent goes to the reserve pool, while the remainder is allocated among the validators in proportion to their position.

Cosmos Blockchain Governance

As you might expect, for a structure like Cosmos, having a strict governance model is completely necessary. The validators should be responsible for the general safety and well-being of the program. Changes in the ecosystem of the Cosmos are made through the vote of the validators. There are certain conditions that must be met before a vote can take place:

• Validators must be given a certain number of tokens that could be ATOMs of any other token or a combination of different tokens.
• When the validators do not vote on a plan in due time, they will be disciplined by being deactivated for a specified amount of time.

On each initiative, the electors will vote for either of the following:

• Yea
• YeaWithForce
• Nay
• NayWithForce
• Abstain.

On the basis of the votes, the following conditions are possible:

• If the proposal has a clear majority of Yea or YeaWithForce, the proposal will be accepted.
• If the resolution gets a total majority of Nay or NayWithForce, the resolution will be dropped.
• >1/3 of the electorate can, however, veto a majority decision “with force”.
• If a strict majority is vetoed, all parties will be disciplined by sacrificing 1 day of block payments. In fact, the party that vetoed the majority vote will be disciplined by losing 0.1% of their ATOMs.

Cosmos Blockchain Use Cases

Cosmos has some extremely interesting use-cases:

• DEX: Since Cosmos Blockchain binds so many blockchains to each other, it goes without saying that it can easily allow different communities to communicate with each other. This is the perfect setting for an open trade.
• Cross-chain transactions: In the same manner, one zone can use the resources of another zone through the Cosmos center.
• Ethereum Scaling: This is one of the most widely used cases. Any EVM-based zone linked to the Cosmos center will also be operated by the Tendermint consensus system, as per the architecture. This will make it possible for these zones to scale up faster.

Cosmos Blockchain: Conclusion

Cosmos and Tendermint are some of the most interesting projects out there. They bring a whole new level of scalability and interoperability to blockchains, something that it desperately needs right now. Only time will tell how it will keep some of its rivals in interoperability spaces like Cardano, AION, ICON, and so on.

Nevertheless, the software is certainly interesting and they seem to have a very passionate and dedicated team behind them. Let’s hope that all of their solutions are put in place. Scalability and interoperability issues need to be addressed in order to speed up market acceptance. Perhaps Cosmos Blockchain is going to pave the way.