October 31, 2008, was one of the most important moments in human history. No, we are not exaggerating. That was the day when Satoshi Nakamoto created Bitcoin. In an instant, the entire world was introduced you to a decentralized, peer-to-peer cryptocurrency. Along with that, Bitcoin also educated the world about the blockchain technology and its limitless possibilities.
However, two factors exist which is stopping the blockchain from gaining faster recognition:
- Lack of scalability
- Lack of interoperability
Cosmos, which calls itself the internet of blockchains, is looking to solve both these issues and help bring blockchains to the next level. So, before we talk more about Cosmos, let’s look into both the Scalability and Interoperability problem.
Lack of Scalability and Interoperability
The main problem that Bitcoin was facing (and still facing) was “scalability.” Back when Satoshi Nakamoto created Bitcoin, he was forced to impose a 1 MB limit on the Bitcoin blocks. He envisioned that Bitcoin blocks may get filled with spam transactions and that would lead to DoS (Denial of Service) attacks.
While the block limit may have worked, unfortunately, this led to a problem. Bitcoin became popular! And as a result, it just didn’t have the provisions required to keep up with the increasing demand. Check out this graph (via Blockchain.info):
That graph shows the increasing amount of transactions per month since 2009 and as you can see, the increase has been pretty drastic. Now, this is obviously good news, right? After all, it just goes to show that more and more people are getting into this space and that cryptocurrencies are getting the mainstream condition. However, what this has unfortunately led to is a decrease in the speed of the overall system.
Bitcoin’s and a part of Ethereum’s utility is as a payment protocol. As such, it is only fair that we compare them to other similar and popular payment protocols. Think of mainstream payment protocols like visa and PayPal. While Visa manages a whopping 1667 transactions per second, Paypal still manages to do a respectable 193 transactions per second. So, how do you think Bitcoin and Ethereum do in that regard?
Well…Bitcoin does a miserable 7 transactions per second while Ethereum manages 20. Now, these are certainly not good numbers and they are really not going to help cryptocurrencies in the long run. The only way that these numbers can be improved is if they work on their scalability.
If we were to categorize the main scalability problems in the cryptocurrencies, they would be:
- The time it takes to put the transaction inside the block
- The time that it takes to reach a consensus.
The Time Taken To Put A Transaction In The Block
When you deal with fiat currency, you can simply conduct transactions by physically sending money to one another. However, that is not really the case with digital currencies like Bitcoin and Ethereum. In these cryptocurrencies, we have people called miners who actually put the transaction details in the blocks that they have mined for them to go through.
So suppose Alice wants to send 4 BTC to Bob, she will send this transaction data to the miners, the miner will then put it in their block and the transaction will be deemed complete.
Seems pretty straightforward right? However, this is where we face another problem.
As Bitcoin becomes more and more popular, this becomes more time-consuming. Also, there is another issue that one should take note of, transaction fees. When miners mine a block, they quite literally become temporary dictators of that block. In return for putting transactions in them, they charge a “toll” called transaction fees.
The higher the transaction fees that you pay, the faster your transaction will get processed by the miners. This may not be the best proposition for people who don’t have a high supply of bitcoins. In fact, check out this graph:
If you pay the lowest possible transaction fees, then you will have to wait for a median time of 13 mins for your transaction to go through.
Also, remember another thing. Bitcoin and Ethereum need to account for block production time as well. Bitcoin has a block production time of 10 mins while Ethereum does it in 15 seconds. So, more often than not, one may actually have to wait for the block to be mined for their transaction to go through.
There is another thing that hinders the number of transactions that the blocks can actually hold, and that is the block size. Bitcoin, as we have mentioned above, has a 1 MB block size which limits its transaction carrying capacity.
Ethereum doesn’t have a “defined” block size and a new block gets mined every 15 seconds. So it must be doing pretty well right? Unfortunately, that doesn’t seem to be the case.
Each and every block in Ethereum is limited by a gas limit of 6,700,000 and each transaction costs 21,000 gas, you can see that there is a limit here as well.
So, one debate that has raged on in Bitcoin is, why not simply raise the block size?
This single question has pretty much ripped the Bitcoin community apart. There is one group that feels that increasing the block size without looking at proper innovations is a folly while there is another group that feels that increasing the bitcoin block size is the correct way to go forward. However, even if you just increase the block size 2X or 4X or 10X, the increase in the number of transactions is only going to be linear and not exponential. Meaning, a 10X block size increase will increase the transaction number 10 times, which in bitcoin’s case will be ~70 transactions per second, which is still not good enough.
Let’s take the example of Bitcoin Cash, which forked from the original Bitcoin protocol and increased the block size to 8 MB which is an 8X increase. Bitcoin cash can handle ~62 transactions/ second which is roughly 8X that of Bitcoin.
These limitations when it comes to scalability has seriously hampered the Bitcoin and Ethereum blockchains. Never was this issue more evident during the Cryptokitties fiasco.
In case you didn’t know, Cryptokitties is a popular game built on the Ethereum blockchain which allows its users to buy and nurture digital cats. Think of Pokemon on Ethereum. This game became so popular that it pretty much broke the Ethereum blockchain. Because of the increasing demand for the kitties, the number of unconfirmed transaction on the blockchain increased exponentially.
Because of this, Axiom aka the company behind cryptokitties was forced to increase their birthing fees. In an announcement they said:
“The excitement and adoption we’ve seen this week has been overwhelming and we couldn’t be happier! However, the Ethereum network is completely full. The only way to keep CryptoKitties from lagging is to increase the gas prices so that all transactions can complete quickly. We know that increased prices will mean that some of you will need to slow down your breeding regimen, and we are incredibly disappointed by that. But who knows? Maybe this slowdown will just mean that you’ll love the Kitties you already have that much more”
In fact, things became so bad that some ICOs were forced to delay their release. SophiaTX, for example, had to delay their ICO because of how much the game clogged up the blockchain.
In order to understand the interoperability problem, let’s take a closer look at the current and (possible) future ecosystem. In the current crypto sphere, there are several different coins like Bitcoin, Bitcoin Cash, Ethereum etc. At the same time, even in the legacy world, there are several payment channels like SWIFT, Alipay, Paypal etc.
Now, with so many payment mechanisms out there, it will become extremely difficult, if they cannot interact with each other at all. The last thing that you would want is to make different silos out of all the payment systems that are out there.
To understand what we mean by that, consider this for a second. Suppose Alice sends some cash to Bob via Paypal and Bob wants to send that money to Charlie via Alipay. Now, what all needs to happen for this transaction to go through?
- Firstly, both Alice and Bob should have a verified Paypal account
- Now, Bob and Charlie should have verified Alipay accounts
- Alice now needs to send money to Bob, a bit of it will be deducted as a result of transaction fees
- Now, Bob will send the money from his PayPal account to his bank account. Which will once again have transaction fees and it will take some time to do the transfer as well.
- After getting the money in his bank, he will transfer it to his Alipay account, which will once again deduct a transaction fees
- He will then transfer it to Charlie, which will deduct another transaction fees
- Charlie will transfer the money from his Alipay account to his bank account, which will…you guessed it…deduct another transaction fees.
Overall, this entire transaction chain will have multiple transaction fees and take a lot of time. As you can see, right now, this entire process is extremely inefficient and time-consuming.
This problem lies in the crypto-crypto transactions as well, at least the way it is designed right now.
It is tough for bitcoin to know what is going on in Ethereum and vice-versa. This 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.
Now let’s see what happens if you want to trade using obscure cryptos, which may not be available in a fiat-to-crypto exchange like Coinbase?
Suppose Alice wants to send Bob LBRY tokens.
- Alice and Bob both need to make accounts in the crypto-crypto exchange, let’s say Binance
- Alice sends Bob LBRY which also deducts transaction fees
- Bob will then convert LBRY to BTC or ETH
- Bob will then transfer BTC to ..say…Coinbase (which will deduct transaction fees)
- You can then use Coinbase to convert BTC to fiat money and send it to your account
Again, the centralized exchanges prolong the process and are more time-consuming.
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.
A more elegant and risk-free solution to interoperability was needed.
A third-generation crypto coin must provide an ecosystem where each individual blockchain can communicate with another blockchain and with external legacy financial systems.
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.
How Cosmos can Help
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.”
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”.
The Cosmos Team
Cosmos is supported by the Interchain Foundation (ICF). The Tendermint team has been contracted by the ICF for development.
Tendermint and, by extension, Cosmos has a brilliant team behind it. Let’s meet the chief players:
Jae Kwon: He is the CEO and founder of Tendermint. He had earlier co-founded “I done this” a productivity app for teams. He has also made many contributions to multiple projects including Scramble.io, Flywheel networks, and Yelp.
Ethan Buchman: The CTO and co-founder, has a Master’s degree from the University of Guelph and more than 2 years of experience working as a research scientist. His first work in the blockchain space was with Eris Industries back in 2014.
Now that we know about the Cosmos’ hub and zone architecture, let’s look more into it.
Hub and Zones: The Heart of Cosmos Blockchain
As noted earlier, Cosmos’s architecture will follow the Hub and Zones method. There will be multiple parallel blockchains 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.
Hubs on the network are basically the central ledgers for each individual chains, which are also called zones. The zones engage in token swapping through the hubs.
If there weren’t any hubs in the network, Cosmos would be a mess of unrelated blockchains. The exchange of tokens between blockchains of this type puts a lot of pressure on trusting the source of the token, in particular, their validators. This issue compounds as tokens move along the network from chain A to chain B to chain C, and so on. In fact, this is
Each time requiring the receiving chain to trust all sets of validators before them exponentially.
So, how do Hubs in the network resolve this situation?
Well…they resolve it by merely existing! They help the zones to connect with each other which dramatically reduces the risk of double-spending. Zones do not need to trust other zones directly or the ones that passed on tokens before them. They only need to account for trusting the hubs.
The first hub of the Cosmos Network is the Cosmos Hub, which is a Proof of Stake (POS) blockchain utilized using the Tendermint algorithm (which is explored later).
Along with the Cosmos Hub there are already other teams working on secondary Hubs that will talk through IBC. IRIS Network is a project based out of China working on a Hub to connect to the Cosmos network. This opens up great scaling potential, and it shows how crucial open source code is in growing a decentralized network.
The decentralized nature of the Cosmos universe stems from the multiple Hub architecture that is being built by a decentralized group of open-source developers.
A multi-hub Cosmos Network would be well connected between each hub. Each Zone must connect to a Hub, but in general Zone to Zone connects are not needed.
Cosmos Dual Tokens
Cosmos uses two tokens:
- Atom: The staking coin that will be used for governance. The validators of the Zones must become a part of the Hub by staking Atom coins. If the zone acts maliciously, then their staked Atom gets slashed.
- Photon: The fee coin which will be used in the ecosystem for paying the transaction fees
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/$17 million 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%).
Photon tokens are used to pay the 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.
Now you might be wondering, how are these Zones connected to the Hubs?
The answer….Inter Blockchain Communication(IBC) packets!
Let’s see how IBC packets work.
IBC – An Introduction
So, to understand the IBC system, let’s look at a simple example. Suppose you have three components:
- 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
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 Hub and Spoke architecture requires blockchains to have smart contracting abilities that would allow for the implementation of the Inter-Blockchain Communication Protocol (IBC). IBC allows for arbitrary messages to be exchanged between blockchains.
The first iteration of IBC will, for the most part, contain data for the exchange of digital assets. Along with that, it will also be possible for messages to be exchanged that makes contract calls on other blockchains and anything else you can think of. The IBC protocol gives developers a straightforward way to build a blockchain that can communicate with other blockchains
Looking Deeper into IBC
As you may have guessed, IBC is what helps Cosmos attain interoperability. IBC can only work if the starting and destination chains have settlement finality. The problem with that is that most of the major blockchains, like Bitcoin and Ethereum, don’t have proper finality guarantees, especially when it comes to settlement. Ethereum may have that once Casper FFG is fully executed.
According to their blog, “What this means is, the deeper down the chain a block is, the less likely the chain it’s on will get reorganized, giving you a high level of confidence that the block is “final”. But because probabilistic guarantees do not protect against reorgs, transferring assets securely across chains via IBC is impossible.”
So then, that brings us to an obvious question. How exactly can cosmos help interoperate these diverse blockchains which don’t have proper finality?
The answer…Peg Zones. So, what exactly are peg zones?
A peg zone is an account-based blockchain which bridges zones within Cosmos to external chains like Bitcoin or Ethereum. It acts as a finality portal which pretty much “translates finality for probabilistically finalized blockchains by imposing a “finality threshold” at some arbitrary number of blocks to achieve pseudo-finality. Generally, this “translator” zone design can be classified as a 2-way peg (2WP).”
Tendermint Core, which is the consensus engine within cosmos offers settlement finality.
So now, let’s check how Cosmos connects to Ethereum.
Peggy – The Ethereum and Cosmos Connection
The Ethereum peg zone is one of the most important areas of development for Cosmos. This is very different from Ethermint(more on this later), which is the EVM, stripped of Proof-of-Work mining, then layered on top of Tendermint’s consensus and networking protocol stacks.
So, what exactly is this peg zone going to do?
It will help enable the movement of ERC20 tokens and Ether between the canonical Ethereum chain and all IBC-connected zones within the Cosmos Network.
This peg has been named “Peggy”.
Going Into Peggy
To transfer crypto-assets between Cosmos and Ethereum, however, is very technically complex because IBC packets cannot be efficiently decoded in Ethereum, simply because the EVM isn’t designed to be IBC-compatible. However, this is where Peggy comes in.
The first ever version of Peggy attempted to connect Cosmos to Ethereum was a hackathon project called ETGate. The problem was that it just consumed a lot of gas.
ETGate initially was a direct bridge between the Cosmos Hub and Ethereum which attempted to translate compatibility within the EVM itself. It looked something like this:
[ Ethereum ] <- ETGate -> [ Cosmos Hub ]
While this design was pretty straightforward, there was a major obstacle. It was highly impractical when confronted with the problem of the different building blocks used in Tendermint and Ethereum. The simple problem is that Tendermint and Ethereum are fundamentally different entities. In order to make these incompatible elements to get along with each other, you will need complicated processes which are extremely gas hungry.
Here are the main points of differences between Tendermint and Ethereum:
- Serialization formats. Tendermint’s encoding method to serialize objects is go-wire. Ethereum serializes objects using RLP (Recursive Length Prefix).
- Signature schemes. Tendermint uses ed25519 whereas Ethereum uses secp256k1.
- Data structures. Tendermint stores key-values in IAVL+ trees while Ethereum stores them in Patricia Tries.
So, why is ETGate’s design so expensive?
Well, it decodes IBC packets within the EVM, of which the contents were Tendermint’s headers, transactions, IAVL+ tree proofs, and ed25519 signatures. This takes a huge amount of computational power.
Something needed to be done to evolve Peggy and save the massive amounts of gas that it would have otherwise consumed. So, what Cosmos did was take out the translation mechanism from the EVM and onto its own blockchain designed for this specific application.
Peggy’s 5 Components
Since we have heard quite a bit about Peggy, let’s see what it is made out of”
- Ethereum Smart Contracts: There will be a set of Ethereum smart contracts acting as asset custodians, capable of taking custody of Ethereum native tokens and issuing Cosmos native tokens.
- Witness: The witness component attests witness to events in Ethereum. It waits for 100 blocks, the finality threshold, and implements this pseudo-finality over the non-finality chain. It runs a fully validating Ethereum node in order to attest to state changes within Ethereum by submitting a WitnessTX to the peg zone. We use a shared security model here by taking the set of Cosmos Hub validators also to be peg zone Witnesses.
- Peg zone: The peg zone is a translator blockchain, built on Tendermint, that allows users to perform and query transactions. This is how Cosmos communicates with Ethereum.
- Signer: The signer signs messages using the secp256k1 signature scheme which Ethereum understands to make signatures efficiently verifiable by smart contracts. The signer component generates secp256k1 signatures via the SignTx message and posts it to the peg zone for relaying transactions for validation in the smart contract down the pipeline.
- Relayer: The relayer component relays a batched list (array) of transactions—signed by the Signer component—and posts them to the Ethereum smart contract.
How to Move Cosmos’s Token to Ethereum
Let’s say, for example, you want to move some quantity of Photons out of Cosmos and convert them to Ether of equal value on Ethereum. How would this work via Peggy?
Let’s see a general overview of the process:
- Starting at the Cosmos Hub, the photon tokens are moved to the peg zone via IBC
- The peg zone receives an incoming IBC packet. An IBC packet is a which message contains the transaction which is sending the Photon tokens.
- The IBC transactions are then signed by signers monitoring the peg zone. They convert the signature scheme to Ethereum-understandable private keys, in secp256k1 format.
- Up next, the relayers come into play. They wait for transactions which gain >2/3rd approval from the signers. The batch the approved transaction with all other transactions that have sent through IBC.
- They then relay this batch to the EVM where the Ethereum smart contract is.
- The smart contract will now check the validity of the list of transactions.
- Once the validity is checked, the smart contract will generate an equivalent ERC20 version of the Photons that you have sent. These ERC20 Photons are sent to the destination address in Ethereum
- Converting your ERC20 Photons to ETH is as simple as using an ERC20 decentralized exchange (DEX) like the 0x protocol or OmiseGO.
Current Status of Peggy
Peggy is still at an early stage. The Ethereum smart contract part of Peggy has already been written and is currently being tested. The main problem lies in the sheer level of complexity in Peggy which is a lot more complex technically than the Cosmos Hub itself.
The deployment of Peggy is a high priority and the Cosmos/Tendermint team has devoted a significant portion of its resources to its development in tandem with the rest of our ecosystem projects.
What is Ethermint?
Well, we have heard quite a bit about Ethermint, so what exactly is it?
According to them:
“The Ethereum Virtual Machine is an example of a virtual machine that can be connected with IBC using the Cosmos SDK. With the SDK, a developer can use Tendermint BPOS for consensus, rather than relying on longest chain POW. This has been shown to reach speeds of over 200 tx/s, and the core developers building Cosmos is working on bringing this to reality with Ethermint.”
So, how exactly will this empower the developers?
The developers can now potentially run their applications on a different EVM!
Remember, Ethereum uses the POW protocol (as of writing) and has developers constantly face gas issues. Ethermint will allow developers to use a platform which has all the functionalities of the EVM but with better throughput and lower gas costs.
Speaking of which, let’s go deeper into the application-specific blockchains of Cosmos.
Cosmos SDK – Creating Application-Specific Blockchains
The Cosmos Software Development Kit or SDK makes it easier for developers to build an application specific blockchain.
The Cosmos SDK is an ABCI framework written in Golang and is designed for supporting the development of multi-asset PoS blockchains, Proof-of-Authority (PoA) blockchains, and applications on top of them.
The primary purpose of the SDK is to reduce the complexities in building the ABCI for common blockchain functionality and allowing developers to focus on customizable applications within a standardized framework. The modular structure of the SDK is layered over the low-level ABCI and provides a suite of tools and resources for developers. It was built for Gaia, the first implementation of the Cosmos Hub and the mainnet launch will follow an audit of the SDK code as well as the completion of the Game of Stakes PoS testnet.
Prediction markets (i.e. Augur), Auction Markets, and many other specific applications may be better suited with their own blockchain, rather than trying to cram them all on a single platform such as the Ethereum mainnet.
Getting a successful project built on a general purpose platform like Ethereum could end up having their product too expensive to use if gas prices get too high. For extremely niched applications, it is much better for them to create their blockchain. This can greatly increase performance, while also decreasing the attack surface.
Did you know that you can create your own Plasma sidechain using Cosmos SDK?
The Cosmos SDK is a part of the Cosmos tech stack that developers can get really excited about, as it gives them a framework to build new blockchain applications with.
Developers can even build Plasma sidechains with the SDK. The sidechain code could be written using the Cosmos SDK, while the Plasma smart contract could be written in Solidity. Once one sidechain is created, it becomes easy to create endless Plasma sidechains with the SDK. This is analogous to how the first ERC-20 token was hard to create, but now it is very easy to find and use ERC-20 code that works.
What is Tendermint?
Finally, we get to the topic of Tendermint.
There is a reason why we have kept this as a separate section, because, to be honest, it is a topic of its own. The sheer utility of Tendermint is so huge that it can pave the way for numerous blockchain products down the line.
There is a lot that we need to go through here and there will be some technical terms that you need to familiarize yourself with. However, by the end of this article, you will know exactly what the Tendermint Protocol is and what it does.
Tendermint Core combines the Tendermint consensus algorithm along with a p2p gossip protocol. So, when you put it all together in the software stack, you get the Tendermint Core along with the Cosmos-SDK application layer.
Anyway, so before we go in any further, let’s look at why Tendermint is such a necessity.
Bitcoin and Blockchain
When Satoshi Nakamoto created Bitcoin, he made the first-ever decentralized cryptographic system. The really remarkable part about this discovery was that he was able to solve the Byzantine General’s Problem which helped a wide area network(WAN) to come to a consensus in a trustless environment. Bitcoin used proof-of-work algorithm to take care of their consensus.
Bitcoin’s main contribution was that it introduced the world to the blockchain technology.
A blockchain is, in the simplest of terms, a time-stamped series of immutable record of data that is managed by a cluster of computers not owned by any single entity. Each of these blocks of data (i.e. block) are secured and bound to each other using cryptographic principles (i.e. chain).
In other words, a blockchain is a deterministic state machine replicated on nodes that do not necessarily trust each other.
By deterministic we mean that if the same specific steps are taken, then it will always lead to the same result.
Eg. 1+2 will always be 3.
So, what does state mean? Let’s look at it wrt Bitcoin and Ethereum.
In Bitcoin, the state is a list of balances for each account, which is a list of Unspent Transaction Output(UTXO). This state gets modified via transactions which change the balance.
On the other hand, in Ethereum, the application is a virtual machine which runs smart contracts. Each transaction goes through the Ethereum Virtual Machine and modifies the state according to the specific smart contract that is called within it.
If you look at the architecture of the blockchain technology, then you will three specific layers:
- Networking: The propagation of the transaction/information throughout the nodes
- Consensus: Allows the nodes to come to a decision provided >2/3rd of the nodes are non-malicious
- Application: Responsible for updating the state given a set of transactions, i.e. processing transactions. Given a transaction and a state, the application will return a new state.
For visual cues:
Problems With The Current Blockchain Architecture
Turns out that building a blockchain from ground up with all these 3 layers is really hard work. So, many projects preferred building on by forking the Bitcoin codebase. Now, while this does save up on a lot of time, the fact is that they are still handcuffed by the limitations of the Bitcoin protocol. Obviously, you can’t execute complex projects when you are using a protocol which is well-known for its throughput issues.
Things got a whole lot better when Ethereum came into play. Ethereum actually gave developers a platform that they could use to create their own customized code aka smart contracts and projects. However, as with Bitcoin, Ethereum also suffers from the same problem. They both have monolithic architecture as opposed to modular.
Monolithic Architecture vs Modular Architecture
Monolithic architecture means that everything is composed all in one piece. When a software is deemed “monolithic” the components are interconnected and interdependent with each other and the design is more self-contained. In this case, the architecture is more tightly-coupled and the associated components must be all present in order for the code to be executed or compiled.
While this makes the system it was created for more robust, you can’t really derive from it and create custom codes. It is not the most flexible of systems. Plus, there is another problem with this system. If any component of the program needs to be updated, the whole application will have to be reworked. This not really the most ideal of situations now is it?
On the other hand, we have modular architecture. Unlike Monolithic, the layers are not that linked to each other. So, while it may not be as robust, it is quite easy to update the whole application by working with the different separate modules.
Modular architectures reduce the risk that a change made within one element will create unanticipated changes within other elements because modules are relatively independent. Modular programs also lend themselves to iterative processes more readily than monolithic programs.
Tendermint’s Architecture and Goals
Tendermint utilizes the modular architecture. Tendermint’s goals are as follows:
- Provide the networking and consensus layers of a blockchain as a platform where different decentralized applications can be built
- Developers only need to worry about the application layer of the blockchain, saving all the hours that they would have wasted working on the consensus and the networking layer as well.
- Tendermint also includes the Tendermint consensus protocol which is the Byzantine fault tolerant consensus algorithm used within the Tendermint Core engine
Let’s look at how Tendermint’s architecture will look:
As you can see, the application is connected to Tendermint Core via a socket protocol called the APCI or Application Blockchain Interface. Since Tendermint Core and the Application running on it run in separate UNIX processes, they need to have a method to speak with each other. ABCI helps these two in their communication.
So, what does ABCI’s design look like?
ABCI will have some distinct design components:
#1 Message Protocol
- Pairs of request and response messages
- Requests are made by the consensus while the application responds
- It is defined using protobuf
- The consensus engine runs the client
- The application runs the server
- There are two proper implementations: async raw bytes and grpc
#3 Blockchain Protocol
ABCI is very connection oriented. The three connections for Tendermint Core are as follows:
- Mempool connection: This checks if the transactions should be relayed before they get committed. It can only use CheckTx
- Consensus connection: This connection helps in executing transactions that have been committed. Message sequence is, for every block, BeginBlock, [DeliverTx, …], EndBlock, Commit
- Query Connection: Helps in querying the application state. This part only uses Query and Info
All in all, the main goal of Tendermint is to provide developers with a tool that is not only practical but also has a high throughput. Here are the properties of Tendermint that makes it so alluring:
Public or Private Blockchain Compatible
Different projects have different needs. Some projects need to have an open system where anyone can join in and contribute, like Ethereum. On the other hand, we have organizations like the Medical Industry, who can’t expose their data to just about everyone. For them, they require something like the permissioned blockchain.
Ok, so how can Tendermint help in satisfying both these needs? Remember that Tendermint only handles the networking and consensus for the blockchain. So, it helps in the:
- Propagation of the transaction between the nodes via the gossip protocol
- Helps the validators agree on the set of transactions that gets appended to the blockchain.
What this means is that the application layer is free to be defined any way that the developers want it to be defined. It is upto the developers to define how the validator set is defined within the ecosystem.
- The developers can either allow the application to have an election-system which elects validators based on how many native tokens these validators have staked within the ecosystem..aka Proof-of-stake and create a public blockchain
- Plus, the developers can also create an application that define a restricted set of pre-approved validators who take care of the consensus and the new nodes that get to enter the ecosystem. This is called proof-of-authority and is the hallmark of a permissioned or private blockchain.
Applications made via Tendermint Core can expect exceptional performance. Tendermint Core has a block time of just 1 second. It can also handle a transaction volume of 10,000 transactions per second for 250byte transactions, as long as the application allows it to do so.
What is finality?
In simple terms, it means that once a certain action has been executed, it cannot be taken back. So, let’s take the example of a simple financial transaction. Suppose you buy some stocks in a company, just because a glitch in their system, you shouldn’t lose out on the ownership of your stocks. As you can imagine, finality is super critical for a financial system. Imagine doing a million dollar transaction and then the very next day, that transaction isn’t valid anymore because of a glitch.
Like we have mentioned before, Bitcoin and Ethereum (until full implementation of Casper FFG) don’t really have settlement finality. On the occasion of a hardfork or a 51% attack, transactions have a chance of getting reverted.
Tendermint, on the other hand, gives instant finality within 1 second of the transaction completion. Forks are never created in the system, as long as less than 2/3rd of the validators are malicious. As soon as a block is created (which is within a second) the users can rest assured that their transaction is finalized.
Tendermint is secure and forces its participants to be accountable for their actions as well. Like we have said before, tendermint can never be forked as long as less than 2/3rd of the validators are malicious. If in some case, the blockchain does fork, there is a way to determine liability. Plus, Tendermint consensus is not only fault tolerant, but it’s also optimally Byzantine fault-tolerant
Another great thing about Tendermint is its user-friendliness. Like we have mentioned before, they have a modular architecture where the application layer can be suitably customized. This makes it possible for existing blockchain codebases to be effortlessly linked on to Tendermint via ABCIs. The perfect example of this is Etheremint which is basically the Ethereum virtual machine codebase plug on top of Tendermint.
Ethermint works exactly like Ethereum but also benefits from all the positive features that we have listed above. All the Ethereum tools like Metamask and Truffle are compatible with Ethermint.
Tendermint’s proof-of-stake implementation is a lot more scalable than a traditional proof-of-work consensus algorithm. The main reason being that POW-based systems can’t do sharding.
Sharding basically horizontally partitions a database and creates smaller databases or shards which are then parallelly executed by the nodes. The reason being that a strong mining pool can easily take over a shard.
Tendermint will allow the implementation of sharding which will greatly increase the scalability.
Tendermint Consensus Protocol
Ok, so let’s look into how the Tendermint consensus protocol works. What exactly is a consensus protocol?
This is how Wikipedia defines consensus decision-making: “Consensus decision-making is a group decision-making process in which group members develop, and agree to support a decision in the best interest of the whole. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the “favourite” of each individual. “Consensus” is defined by Merriam-Webster as, first, general agreement, and second, group solidarity of belief or sentiment.”
In simpler terms, consensus is a dynamic way of reaching agreement in a group. While voting just settles for a majority rule without any thought for the feelings and well-being of the minority, a consensus, on the other hand, makes sure that an agreement is reached which could benefit the entire group as a whole.
From a more idealistic point-of-view, Consensus can be used by a group of people scattered around the world to create a more equal and fair society.
A method by which consensus decision-making is achieved is called “consensus mechanism”.
So now what we have defined what a consensus is, let’s look at what the objectives of a consensus mechanism are (data taken from Wikipedia).
- Agreement Seeking: A consensus mechanism should bring about as much agreement from the group as possible.
- Collaborative: All the participants should aim to work together to achieve a result that puts the best interest of the group first.
- Cooperative: All the participants shouldn’t put their own interests first and work as a team more than individuals.
- Participatory: The consensus mechanism should be such that everyone should actively participate in the the overall process.
- Inclusive: As many people as possible should be involved in the consensus process. It shouldn’t be like normal voting where people don’t really feel like voting because they believe that their vote won’t have any weight in the long run.
- Egalitarian: A group trying to achieve consensus should be as egalitarian as possible. What this basically means that each and every vote has equal weight. One person’s vote can’t be more important than another’s.
Now that we have defined what consensus mechanisms are and what they should aim for, we need to think of the other elephant in the room.
Which consensus mechanisms should be used for an entity like blockchain.
Before Bitcoin, there were loads of iterations of peer-to-peer decentralized currency systems which failed because they were unable to answer the biggest problem when it came to reaching a consensus. This problem is called “Byzantine Generals Problem”.
Byzantine General’s Problem
In order to get anything done in a peer-to-peer network, all the nodes should be able to come to a consensus. The thing is though, for this system to work, it lays a lot of emphasis on people to act in the best interest of the overall network. However, as we know already, people aren’t really trustworthy when it comes to acting in an ethical manner. This is where the Byzantine General’s problem comes in.
Imagine this situation.
There is an army surrounding a well-fortified castle. The only way that they can win is if they attack the castle together as a unit. However, they are are facing a big problem. The army is far apart from each other and the generals can’t really directly communicate and coordinate the attack and some of the generals are corrupt.
The only thing that they can do is to send a messenger from general to general. However, a lot of things could happen to the messenger. The corrupt generals can intercept the messenger and change the message. So, what can the generals do to make sure that they launch a coordinated attack without relying on the ethics of each individual general? How can they come to a consensus in a trustless way to do what needs to be done?
That’s the Byzantine General’s Problem and Satoshi Nakamoto solved this problem by using the Proof-of-Work (POW) consensus mechanism.
What is Proof-of-Work?
Let’s check how POW works with context to our example given above. Suppose a general wants to communicate with another general. How do you think it will go down?
- A “nonce” is added to the original message. The nonce is a random hexadecimal value.
- This new message is then hashed. Suppose the generals agree beforehand that they will only send messages, which when hashed begins with 4 “0”s.
- If the hashed does not give the desired number of 0s, the nonce is changed and the message is hashed again. This process keeps repeating until the desired hash is received.
- The entire process is extremely time-consuming and takes up a lot of computational power.
Now when they finally get the hashed value, the messenger is given the original message and the nonce and told to communicate with the other generals. So what does happen if someone does try to intercept the message? Well, remember the avalanche effect of the hash functions? The message will change drastically and since it won’t start with the required number of “0”s anymore, people will realize that the message has been tampered with.
So, to put POW in the context of crypto mining:
- The miners try to solve cryptographic puzzles to add a block to the blockchain.
- The process requires a lot of effort and computational power.
- The miners then present their block to the bitcoin network.
- The network then checks the authenticity of the block by simply checking the hash, if it is correct then it gets appended to the blockchain.
- So, discovering the required nonce and hash should be difficult, however checking whether it is valid or not should be simple. That is the essence of proof-of-work.
Now, you are probably wondering, why should the miners sacrifice their time and resources to mine bitcoins? Well, turns out that they have a pretty healthy economic incentive:
- When you discover a block, you receive a block reward of 12.5 bitcoins. The reward halves every 210,000 blocks.
- Once you have mined a block, you become the temporary dictator of the block. You are the one responsible for putting transactions inside the block and are hence entitled to transaction fees.
There is only a limited number of bitcoins out there, 21 million to be exact. So, what is stopping these miners from mining out all the bitcoins at once? Turns out that bitcoin mining gets progressively harder over time. This feature is called “difficulty”, and the difficulty of mining keeps on increasing as you keep on mining.
This is why it is pretty much impossible nowadays for solo miners to mine Bitcoins using just their computers. Miners have now joined forces and created “mining pools” to pool their computational power together and mine as a group. These pools use ASICs (Application-Specific Integrated Circuits) specifically created for mining to mine bitcoins.
Problem with POW
#1 Energy Wastage
The biggest problem of Proof-of-work is the energy wastage. This is how much energy Bitcoin has consumed over the last few months. As you can see, Bitcoin has a voracious appetite:
In December 2017, research showed that Bitcoin consumes more energy than 159 individual countries. That is a pretty crazy statistic!
As we have already told you, Bitcoin uses ASICs for mining. The problem with that is ASICs are expensive, and pools with more money tend to have more ASICs and, consequently, more mining power. In fact, check out the hashrate distribution chart for Bitcoin via Blockchain.info.
As you can see, 3 pools BTC.com, AntPool, and SlushPool alone own more than 50% of the network’s hashrate aka mining power. This completely defeats the purpose of decentralization, plus, there is one more big issue. Individual users simply can’t compete with big money pools.
The very architecture of POW prevents scalability. Bitcoin manages a mere 7 transactions per second. For a modern-day financial system, it is simply not adequate enough.
So, to counteract the many problems with the Proof-of-Work consensus system, Jae Kwon, a computer science and system engineering graduate, created Tendermint. Tendermint is a purely BFT-based protocol, built in a permissionless setting with the Proof-of-Stake(PoS) as the underlying security mechanism.
Because of the complexity, Tendermint has taken almost 4 years to be completed.
Jae Kwon and Tendermint CTO Ethan Buchman were inspired by Raft and PBFT to create a consensus system which satisfied the Byzantine general’s problem. It is “modeled as a deterministic protocol, live under partial synchrony, which achieves throughput within the bounds of the latency of the network and individual processes themselves.”
Alright, we know that’s a lot of complicated words to throw one after another but in order to understand what Tendermint consensus is and why it was designed the way it was designed, you need to understand what some of those complicated terms mean. You will see how all of them link up with each other like an intricate puzzle.
#1 FLP Impossibility
The FLP (Fischer Lynch Paterson) Impossibility states that a consensus algorithm can only have 2 of the following 3 properties:
- Guaranteed termination or liveness
- Fault Tolerance
Image Credit: Medium
In other words, the FLP impossibility states that “both termination and agreement (liveness and safety) cannot be satisfied in a timebound manner in an asynchronous distributed system, if it is to be resilient to at least one fault (they prove their result for general fault tolerance, which is weaker than Byzantine fault tolerance, since it only requires one fail-stop node — so BFT is included inside FLP impossibility claims).”
So, basically, it is quite impossible for an asynchronous WAN to come to a consensys as there is no specific amount of time that the nodes will take to receive, process, and respond to messages. This is obviously a big problem because it is extremely impractical for a large network of nodes like Bitcoin to assume that they are going to synchronize.
Ok, so synchronicity was going to be a problem. However, researchers Dwork, Lynch and Stockmeyers threw a lifeline here with their paper called “Consensus in the Presence of Partial Synchrony.” This was called DLS consensus.
#2 DLS Consensus and Partial Synchronicity
The DLS paper states that between a synchronous system and an asynchronous system, there exists a special system which is “partially synchronous”. Since this partially synchronous system can have an upper bound time given, it will be able to design a feasible BFT protocol.
According to DLS, the real challenge in designing protocols is to have one that works correctly in a partially synchronous system.
So, let’s see how popular decentralized protocols like Bitcoin and Ethereum works in that regard.
Bitcoin has a known upper bound which is around 10 mins. So, a block of transactions is produced every 10 mins. This timing assumption is imposed on the network so that the nodes get 10 whole mins to collect the information and transmit it along via gossip.
On the other hand, we have Ethereum which makes a synchrony assumptions for their blocks and network by keeping an upper block time on 15 seconds. With such a low block time, they are more scalable than Bitcoin, however, they are not really that efficient. Ethereum miners produce a lot of orphan blocks.
#3 Liveness and Termination
Termination is a property which states that each correct processor should eventually make a decision. Most consensus algorithms that we have right now relied on a synchronous model for their safety and termination. They have fixed bounds and rules that are known so, in the event that they don’t hold up, the chain forks into multiple protocols
Sure there are consensus protocols that work in asynchronous networks, however going by the FLP impossibility theorem, they cannot be deterministic. Which brings us to….
#4 Deterministic vs. Nondeterministic Protocols
Usually, purely asynchronous consensus protocols depend upon nondeterministic members such as oracles which involves a high degree of uncertainty and complexity.
So How Does Tendermint Deal with All these Factors?
Tendermint is a mostly asynchronous, deterministic, BFT consensus where validators have a stake which denotes their voting power. In the FLP impossibility triangle, it prefers Fault-tolerance and safety (consistency) over liveness.
Tendermint constantly swings between periods of synchrony and asynchrony. This means that, while it relies upon timing assumptions to make progress, the speed of the said progress doesn’t depend on system parameters but instead depends on real network speed.
Also, Tendermint never forks in the presence of asynchrony if less than 1/3rd of the validators are corrupt/careless. This is the very reason why Tendermint is Byzantine Fault Tolerant. Like we have said before, Tendermint focusses on safety above liveness. So, if more than a third of the validators are malicious, instead of the network forking, the Tendermint blockchain will simply come to a temporary halt until more 2/3rd validators come to a consensus.
Tendermint is also completely deterministic and there is no randomness in the protocol. The leaders in the system are all elected in a deterministic version, via a defined mathematical function. So, we can actually mathematically prove that the system is behaving in the way that it is supposed to behave.
Tendermint – The Proof of Stake System
In a proof of stake (POS) system, we have certain people called “validators”. These validators lock up a stake inside the system. After that, they have the responsibility of betting on the block that they feel is going to be added next to the blockchain. When the block gets added, they get a reward proportional to their stake.
Alright, so that’s how a generic POS works. Now, let’s look into how tendermint works.
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 may be 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.
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.
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.
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 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.
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 pre-committed 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/3rd precommits for the block.
Once this is done, the block gets committed to the network.
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, What About Results?
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:
Limitations of Cosmos
There are currently three main limitations of Cosmos:
- Cosmos-SDK based blockchains are being run by multiple validators with Tendermint consensus. Theoretically speaking, they should have lower throughput than single-validator Plasma chains. Having said that, Plasma’s transaction latency is very high due to having to wait for confirmation on the root chain.
- Slashing doesn’t really protect users from state machine faults, which may allow malicious validators to steal from users. So, to put this into perspective, there is currently no protocol level punishment in Cosmos v1.0 for Zone operator misbehavior. (It is worth noting though that Cosmos will ship with shared security shortly after they launch.)
- If a Zone that is connected to the network has malicious actors, any digital assets that users have on that Zone could be compromised. The way to prevent this from happening right now is by ensuring stakeholders of the Cosmos Network pay attention and trust every single Zone that is connected to the network.
Governance Within Blockchain
Strict governance is necessary for the proper functioning of Cosmos. Let’s take a look at how it is going to work. 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 need to a stake a certain amount of ATOM within the ecosystem. This makes sure that they have skin in the game and that they are economically incentivized to take care of the ecosystem
- Validators need to constantly on their toes. If they don’t vote in a timely manner, then they will be punished via deactivation for a certain time period.
- For each proposal, the voters may vote with one of the following:
Now, based on how the voting has been done, the following scenarios are possible.
- The proposal is passed if the majority of the votes are Yea or YeaWithForce
- The proposal drops off if a majority of the votes are Nay or NayWithForce
- However, if more than 1/3rd of the validators vote “with force” then the proposal can be vetoed
- If a strict majority is vetoed, everyone participating gets punished by losing 1 day’s worth of block fees.
- On top of that, the party that vetoed the majority decision will be punished by losing 0.1% of its ATOMs.
Cosmos Use Cases
So what are some of the use cases of an interoperability machine like Cosmos?
- Decentralized Exchanges or DEX: Since so many blockchains are going to be linked to each other via Cosmos, the most obvious use case is as a decentralized exchange. Enabling users to exchange one token for another, without going through a centralized entity.
- Along with DEXs, another obvious use case are cross-chain transactions. One zone can avail the services of another zone through the Cosmos hub.
- Ethereum Scaling: This is one of the more important 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.
The Road Ahead for Scalability
As we have mentioned before, scalability is a burning problem for blockchain right now. There are several possible solutions out there. Most of them fall under two categories:
- Layer 1: Solutions being created on Blockchain’s network
- Layer 2: A network layer created on top of the blockchain network.
Projects like Raiden and Plasma are possible Layer 2 solutions for Ethereum.
Plasma looks to improve Layer 2 by scaling high throughput applications with UTXO state. The researchers behind Plasma will continue to fine-tune their mechanisms, and work towards mass exit designs that prove to be secure for all stakeholders, and support more stateful applications.
Raiden, on the other hand, creates a payment channel between entities for them to conduct multiple microtransactions without actually registering itself into the blockchain.
On Layer 1, Sharding is an interesting solution, which basically breaks up the state of the blocks in the Ethereum blockchain into multiple shards. The shards are then handled by groups of validators who work in parallel to finish the task efficiently.
Cosmos looks to improve Layer 1 Horizontal scaling by enabling the exchange of arbitrary messages between blockchains with highly specific state machines. Tendermint provides Layer 1 Vertical scaling to reach consensus faster than longest chain POW protocols. With the Cosmos-SDK, they provide all the building blocks to connect blockchains across the Cosmos network. All you have to do is design and implement your high-level application logic.
In the future, Layer 1 and Layer 2 scaling will likely be used together to scale blockchains for commercial-scale applications. One day we could see the Cosmos Hub connected to an EVM Zone using Tendermint for consensus, which has a Plasma child chain connected to it!
Scaling will continue to be a hot topic in the blockchain space for years, and the solutions put forth by Cosmos and Plasma are only the beginning of what’s to come.