Blockchain Scaling Solutions: Cosmos and Plasma
Blockchain scaling might be the most important problem being solved in the field today. It will open up opportunities to build commercial scale decentralized applications that compete with their centralized counterparts. Unfortunately, few people understand how to scale blockchains, and this is due to the fact that scaling often isn’t explained with enough detail.
This post aims to fix that with a detailed explanation of two projects with different scaling solutions: Plasma and The Cosmos Network. Plasma is designed specifically to address scaling off-chain. The Cosmos tech stack differs, as it is not directly a scaling solution. Combined, Tendermint and Cosmos aim to solve many challenges in the blockchain field, and scaling is one of them.
Breaking Down Scalability
It is important to understand that increasing the scalability of a blockchain entails trade-offs in decentralization and security. [1] Vlad Zamfir’s triangle gives an excellent visual about how these 3 parameters interact:
Blockchain implementers must choose wisely which metrics they want to optimize for. For example, Bitcoin sacrifices scalability for decentralization and security, which has made it incredibly robust since Day 1. Bitcoin does its job well, but in the last few years many teams have been working on solutions to design a blockchain with scalability in mind.
Now let’s examine blockchain scalability by breaking it down into two smaller scaling problems:
Bandwidth (transactions per second)
Bandwidth is the amount of data that can be transmitted in a fixed amount of time, often expressed as transactions per second (TPS).
An example of increasing bandwidth would be to increase the block size. However, it does require additional processing power, as more transactions are being processed in the same amount of time. This increases bandwidth but makes the network more centralized, since the bandwidth increase will eliminate nodes that can’t handle the necessary increase in CPU power.
If we examine the bandwidth of Bitcoin and Ethereum, we see that they are high latency networks. Some of the design choices that contribute to this are:
- Being heavily optimized for making censorship and Byzantine faults expensive
- For Bitcoin specifically, the developers aim to keep the costs of running a full node low so as to keep the network as permissionless as possible, allowing (albeit infeasible) even a raspberry pi to run a node.
- They have a liveness-favoring fork choice rule under a synchronous model
These are design choices that make the two networks decentralized and secure, while processing a fairly low amount of transactions/second. In contrast, many new blockchain protocols are aiming to have high throughput, but they usually end up sacrificing security or decentralization to do so.
Latency (time to achieve consensus)
Bitcoin’s longest chain Proof-of-Work (POW) algorithm relies on synchrony assumptions which take 10 minutes on average to reach consensus. Ethereum’s block time averages around 14 seconds per block. These consensus mechanisms need to balance many variables, one of which is latency. We will provide a brief summary about Bitcoin’s latency to explain how the network comes to consensus.
If every Bitcoin block is only 1MB, this creates an upper limit for the amount of transactions that can fit in a block. You could decrease the block time from 10 minutes to 5 minutes, and you would effectively double the bandwidth. However, this would lead to more orphaned blocks.
The 10 minute block time is required to give ample time to propagate the newly found block to all nodes in the network. This block time is chosen because it’s in the network’s advantage to propagate a new block to other nodes as quickly as possible. This lowers the chance of propagating two valid blocks almost simultaneously, which can result in a fork. It also allows miners to begin work on the new block as soon as possible, rather than wasting mining resources on a stale chain.
Next, we will describe Plasma’s technical approach to scalability, and what kind of capabilities it will add to decentralized networks.
Plasma
Plasma was first proposed in August 2017 by Joseph Poon and Vitalik Buterin. It focuses on providing increased scalability. This is done by moving transactions onto faster, less crowded, sidechains. These sidechains are secured by the underlying root chain, and Plasma users can always exit the sidechain if they detect malicious Validator behaviour. [2]
It is a Layer 2 solution that increases scalability to reach transactions potentially in the 1000’s.
Breaking Down How Plasma Works
First things first, we need to define what Plasma is. There are three different Plasma concepts that are often talked about:
- Plasma as outlined in the original whitepaper
- Minimal Viable Plasma (or MVP)
- Plasma Cash
- There are other plasmas too, such as Plasma Debit, and More Viable Plasma, as this is still an active design space
Plasma uses cryptography and game theory in order to allow individuals to reliably make transactions on the Plasma blockchain. It should not be thought of as a single specification, such as the Ethereum Yellowpaper. Plasma should be seen as a set of design principles that allow you to build your own massively scalable decentralized application. [4] The main design principle behind Plasma is about guaranteeing end users the same level of security as on the main chain while providing a sidechain with much higher throughput than the main chain. If the end user detects any malicious behaviour on the Plasma chain, they can leave the Plasma chain, and recover their funds on the mainnet. [5]
Most Plasma designs right now have a single validator. This validator can censor a user on a Plasma chain, but the user is able to exit the chain and recover their funds. And this, by extension, makes Plasma chains as censorship-resistant as its associated root chain. The validator loses incentive to censor, because ultimately they’ll be challenged on the mainnet. Because of this implied trust, Plasma’s design allows it to scale to 1000’s of transactions/second.
To compare, a network such as Bitcoin is censorship-resistant because it would be hard for the 1000’s of bitcoin nodes to collude. But it becomes possible with fewer nodes, and recently this happened on the EOS blockchain. With only 21 block producers on the EOS network, it becomes easy to collude and censor an EOS account.
Now let’s explain what Plasma looks like in the original whitepaper.
Whitepaper Plasma
The original whitepaper describing Plasma laid out an extensive design for scaling blockchains to thousands of state updates per second. It was released without an implementation, but it was a catalyst that started more research in the area.
To achieve this, there is a Plasma smart contract stored on mainnet Ethereum. There is nothing special about this smart contract from the mainnet’s perspective, and nothing has to be updated to the core Ethereum protocol to have a Plasma contract on mainnet.
The Plasma contract essentially connects an entire child blockchain to the mainnet, acting as a bridge. Each block of the child chain is recorded on the mainnet Plasma contract by submitting the latest Merkle proof, which can then be used to verify data on the child chain. This allows for 1000’s of transactions to be done on the child blockchain, while only committing a single block hash to the main chain.
Each transaction in a Plasma chain requires the users to sign an acknowledgement that they have seen the transaction in a block, and that the transaction has been included in the main chain. The acknowledgement then gets signed and included in another block, proving both parties have data availability. This is called a “confirmation signature”, and is required to have finality of the original transaction.
A confirmation signature allows for a guarantee that both parties saw a transaction, and that no information is being withheld. However, it is possible that data could be withheld by the Plasma chain’s validator, requiring users to periodically be online. If behaviour like this is noticed, all stakeholders must be able to “mass exit” the child chain. A mass exit in Plasma is often not described in enough detail, so we will do that here.
Exiting the Plasma blockchain begins by halting transactions when a stakeholder has detected malicious behaviour. The process is designed to return the Ether staked on the mainnet Plasma Smart Contract to their true owners. To do this, all Plasma sidechain tokens will have to be exchanged for the original deposit that created them on the Ethereum mainnet.
However, this exit process involves executing at least one mainnet transaction per Plasma account. This can end up being expensive. A 10,000 account Plasma chain would take a long time to mass exit, and would cost a lot of gas.
Needless to say, this is where the Plasma design space starts to get interesting, as there are still a lot of open questions on designing a Plasma chain that will work in production.
As a first step, a simple implementation of Plasma was suggested by Vitalik, called Minimal Viable Plasma.
Minimal Viable Plasma (MVP)
MVP is a stripped down version of Plasma. It meets the design requirements of a Plasma chain, while being simple enough to get a working implementation. The Plasma contract contains the following data structures [5]:
- The owner of the contract
- A list of Plasma blocks. Each block has the Merkle root and the time the Merkle root was submitted
- The “unspent transaction output” (UTXO) position
With these data structures, we also need to enforce priority exit based on transaction ordering. What this means is that in the event of a mass exit, UTXO transactions will be replayed on mainnet in the order they appeared on the Plasma chain, until all funds have been returned to each party. [5] This will ensure that no stakeholder can jump ahead with a falsified block and steal Ether upon exit.
In MVP there are three stakeholders [4]:
- Ethereum mainnet miners
- Plasma validators, called “operators” (they maintain the Plasma child chain, for a fee)
- Users who deposit Ether on the mainnet Plasma smart contract
With this setup for MVP, we are simply doing token transfers, and there are no general smart contract capabilities. Instead, we get strong token security guarantees. Tokens cannot be double spent, cannot be withheld, and can always be redeemed on the root chain with Plasma exits. [4]
We can even run an MVP chain that just has a single POA Plasma validator, and be guaranteed safe exits. [4]
MVP was designed with ERC-20 tokens in mind. Later on, Plasma Cash was designed specifically with Non-Fungible Tokens (NFTs) in mind, such as the ERC-721 token standard.
Plasma Cash
Non-fungible tokens can be thought of as cash in your pocket. [4] Each dollar bill in your pocket has a serial number that makes it unique, and every ERC-721 token also has a unique identifier. From this we can see that no two ERC-721 tokens are the same.
This means that in the Merkle tree of stored data, there will only be one location where the token is valid. Any other party trying to exit that token onto the main chain can easily be challenged by the real owner of that token. [4]
In order to incentivize good behavior, each Plasma chain user puts up an exit deposit upon joining. If they get caught trying to exit a coin that isn’t theirs, they lose their deposit to the challenger.
Plasma Cash owners only need to track the data for their unique coin, and not the entire chain state. [7] In contrast, MVP requires an owner to watch the full state of the blockchain. Both designs require users to login at least once during the checkpoint period to ensure no other stakeholder has attempted to falsly exit their tokens.
Overall, Plasma Cash has a good outlook for high throughput applications that require a simple UTXO state. [7]
How Can Plasma Scale Applications?
Applications that have high throughput and UTXO state come to mind, such as decentralized exchanges and general payments.
Decentralized Exchanges
There have been countless hacks of centralized third party exchanges over the years. Decentralized exchanges (DEX) could provide a solution to this problem. The high transaction throughput of Plasma makes it a great contender to build decentralized exchanges that connect to the main chain, and remove the need for centralized exchanges.
There are existing decentralized exchanges, such as IDEX, and there are decentralized exchange protocols like 0x, but they are currently limited by the current throughput limitations of the Ethereum blockchain. Right now, it would be impossible for these decentralized exchanges to compete with a centralized exchange like Binance.
However, building a Plasma DEX is not a simple job. A decentralized exchange such as IDEX has many smart contracts and state objects on the Ethereum mainnet that allow it to function, and it is likely that smart contract support would be needed to build a functioning DEX as well. Right now, most of the thought process going into Plasma is focused on high throughput applications with simple UTXO state. So IDEX and 0x exchanges would not work on Plasma until it can support more complex state objects for a mass exit.
In particular, an exchange needs an order book to match orders with the best price first, followed by orders placed earlier in history. It also needs market makers, i.e. speculators, to provide liquidity on the platform, for multiple tokens at a time, with millions of dollars involved. [6] Also, traders want fast withdrawals from the platform, which would be limited by Plasma’s challenge period.
Payments
Payments are more appropriate for Plasma MVP and Plasma Cash. Micropayments of less than a cent could easily change hands 1000’s of times with little fees. Keep in mind that in Plasma, the speed of each transfer is still limited to the finality time of the root chain, however.
Aside from micropayments, any group of users that interact in repeated, expensive transactions on Ethereum mainnet could use a Plasma chain to save on fees.
Payments are an important design space for blockchain scalability, and if Plasma can solve this, it would be quite an accomplishment. If we ever want blockchains to process small purchases like coffee, we will have to find a way to reach this level of scalability.
Limitations to Plasma
As of right now, visualizing Plasma chains with full EVM capabilities is not the right approach. Most of the research is focused on getting the UTXO model to work first.
One of the reasons we must keep it simple is because of the nature of ownership in smart contracts. Solidity smart contracts are not good at representing ownership. This means users of an EVM dApp would find it extremely hard to exit. A smart contract can contain many different functions and state variables that are owned by different individuals. This brings up problems in the mass exit game that are required to keep a Plasma chain secure. [3] Any valid state transition from state A to state B will invalidate any exit on state A. Therefore, every single piece of state in a child chain smart contract needs to have clear ownership, otherwise the mass exit game can always be prevented.
It is possible to have complex smart contracts on a Plasma chain, but they must be a constrained form of smart contracts. [5] Nonetheless, Plasma smart contracts should end up supporting more complex state as more research goes into it. They will require well thought out mechanism designs for the complex mass exit functionality. The mass exit is crucial because even if you design a perfectly secure Plasma chain, there must be an effective way to process the Plasma transactions on the main chain. [7] A mass exit that takes too long or is too expensive would not be acceptable as it puts the user’s funds at risk.
The confirmation signatures outlined in the whitepaper are also limiting. They require that both parties send an acknowledgement transaction in order to ensure finality. The user experience is poor because each party has to commit another confirmation transaction just to confirm the original transaction. However, Plasma Cash and More Viable Plasma aim to solve this problem.
For Plasma exits, it also requires that users be online once per checkpoint, which is a design constraint that could turn away a subset of users who don’t want to put up with the hassle.
Cosmos
Cosmos is approaching the scaling problem from a different, yet complementary, angle. Plasma offers numerous off-chain transactions with a single validator producing blocks for the chain. Cosmos is a decentralized public network with many validators, and therefore will not reach the transaction speeds of a single-validator chain. However, Cosmos introduces a BPOS, or Bonded Proof-of-Stake, consensus protocol called Tendermint, which makes performance improvements to Proof-of-Work chains and provides censorship-resistance properties that lack in single-validator chains. The Cosmos Network is also designed to enable blockchain interoperability, and it is the first platform launching with this feature.
There are a few common terms used to describe scalability, defined below:
Layer 1 Vertical Scaling : Layer 1 scaling refers to scaling of the base layer of a blockchain, such as the Bitcoin base layer that is secured by the POW miners. To get more granular, Layer 1 vertical scaling deals with protocol changes to the base layer. Increasing the block size is one example of vertical scaling. Another would be changing the consensus algorithm from longest chain POW to Tendermint BPOS.
Layer 1 Horizontal Scaling : Layer 1 Horizontal scaling can be thought of as scaling by connecting base layer blockchains. These blockchains have protocols that inherently allow them to communicate and transfer messages with other blockchains. Connecting sidechains with a two-way peg is one example. You can think of Cosmos as effectively a sidechain framework on which independent blockchains can be built.
Layer 2 Scaling (Off-chain scaling) : Layer 2 is used to refer to a layer that abstractly sits above the base layer, whose security depends on the security of the base layer. Layer 2 state is checkpointed onto the base layer, which allows for many transactions to be done off the base layer chain. Examples would be Plasma, Payment Channels, and the Lightning Network.
The protocol of a blockchain interoperable network allows for chains to easily become sidechains of each other, which enables horizontal scaling. Cosmos allows blockchain developers to spin up their own blockchains, called “Zones”, to connect to blockchain routing “Hubs”. If a single Zone, or blockchain, were running at full capacity, you could spin up another Zone to effectively double your application’s capacity. Let’s explain how Cosmos uses Hubs and Zones in the network.
Breaking Down How Cosmos Works
The Hub and Spoke model is designed to connect different blockchains in an organized but decentralized way. If the Ethereum mainnet gets overloaded with transactions, it could be scaled with a Layer 2 solution like Plasma. Or it could be connected to a completely different blockchain in a secure way, and distribute some of the load of the Ethereum network onto the newly connected blockchain. Cosmos uses this approach to create a decentralized network of connected blockchains. Hubs and Zones are the two components of this network.
Hubs and Zones
Cosmos Hubs and Zones are best described in the whitepaper, but we will give a brief description of them here for convenience:
Cosmos Hubs — A Hub is a blockchain, and its main function is to act as a router for Zones. It supports routing of messages between Zones for interoperability and keeps a state of invariance for all blockchains connected to the Hub. Hubs are also multi-asset distributed ledgers, where tokens can be held by users. This makes Hubs specialized state machines, while Ethereum is a generalized state machine. So while Ethereum has smart contract capabilities, the Cosmos Hub does not. However, key to building decentralized applications in Cosmos is to build them using the Cosmos-SDK, whereby your specialized state machine could run on its very own blockchain, i.e. “Zone”.
Cosmos Zones — A Zone is an independant blockchain that can exchange messages with a Hub. A zone’s primary function is to act as the application-specific blockchain for the application developer. Packets of information are communicated from one zone to another by posting Merkle proofs as evidence that the info was sent and received. A Zone keeps track of its own state, as well as the state of the Hub it is connected to. Peg Zones are a special type of Zone that are used to connect existing, live blockchain networks that are without transaction settlement finality into the Cosmos Network.
Upon launch of the network, Zones built using the Cosmos-SDK will initially be supported with Tendermint as the consensus engine. But further down the roadmap, there are plans to allow for any possible consensus protocol to be swapped in and for such blockchains to be connected into the Cosmos network.
Tendermint, Proof-of-Stake, and Validators
The blockchains of the Cosmos network require finality to interact with each other. Finality is a guarantee that the state of the blockchain will not revert. With POW, you can only get probabilistic transaction finality.
Tendermint is a Practical Byzantine Fault Tolerant consensus protocol that provides finality. The Cosmos technology stack enables the building of blockchains with the Cosmos-SDK powered by Tendermint’s consensus and networking protocol. All you have to do as a developer is create your state machine application. Then you can connect your blockchain to the Cosmos Network and access the liquidity of every blockchain within the network. Tendermint also improves scaling, because the protocol uses permissioned signing instead of permissionless hashing for reaching agreement.
Tendermint’s deterministic protocol guarantees two key properties: availability and safety. The Validators of the network have skin in the game to provide 100% uptime for availability, and to vote on the correct transactions. If they go against the protocol they will lose monetary value by having their Atoms slashed. Therefore, the end user of the Cosmos network relays on the Proof-of-Stake incentive system to ensure the Validators are good actors.
How Can Cosmos Scale Applications?
Tendermint consensus and the Hub and Spoke Architecture both provide improved scaling for specialized application state machines, as well as blockchain interoperability. Let’s examine some of the ways scaling is improved.
Multi Hub Architectures Using Inter-Blockchain Communication
The Hub and Spoke architecture requires blockchains to have smart contracting abilities that would allow for implementation of the Inter-Blockchain Communication Protocol (IBC). IBC allows for arbitrary messages to be exchanged between blockchains.
Upon the launch of the Cosmos Network, IBC messages will mainly contain data for exchanging digital assets. But it is also possible for messages to be exchanged that make 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.
The Cosmos Hub will be the first Hub, but 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. A multiple Hub architecture that is built by a decentralized group of open-source developers lends to the decentralized nature inherent in the Cosmos universe.
Using the Cosmos SDK to Build Plasma Sidechains
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. Even Plasma sidechains can be built 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.
Ethermint
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.
This gives developers the potential to run their applications on a different EVM. The higher transaction speeds and new platform should provide an alternative option to teams who have built their platform on top of Ethereum mainnet, only to learn it is too expensive or too slow to run their application.
Application-Specific Blockchains
The SDK makes it easy to build an application specific blockchain. 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.
Creating your own application-specific blockchain gives much more power to the developing team. Even 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. Instead, they could create a blockchain specifically designed to run their application. This can greatly increase performance, while also decreasing the attack surface. [9]
Limitations to Cosmos
Cosmos-SDK based blockchains running multiple validators with Tendermint consensus, in theory, should have lower throughput than single-validator Plasma chains. However, Plasma transaction latency is very high due to having to wait for confirmation on the root chain.
Also, slashing doesn’t protect users from state machine faults, and this would allow validators to steal from users. What this means is, there is currently no protocol level punishment in Cosmos v1.0 for Zone operator misbehavior. Though it is worth noting that Cosmos will ship with shared security shortly after they launch. If a Zone 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.
The Road Ahead for Scalability
The blockchain space is facing many challenges in scalability, and there are many projects working to solve these problems. Although this article focuses on Ethereum and Cosmos, every single blockchain out there faces the same scaling issues.
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.
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!
Acknowledgements — For the many reviews and wonderful comments: Zaki Manian, Chjango Unchained, Sunny Aggarwal, Adrian Brink, Aditya Sripal, and Dan Robinson.
Sources
[3] Why smart contracts are not feasible on plasma — Ethereum Research
[4] Ethereum Plasma MVP Overview — Video by Karl Floersch
[5] Minimal Viable Plasma — Ethereum Research
[6] A DEX on Plasma — Ethereum Research
[7] Plasma Cash — Ethereum Research
[8] Vlads Triangle — Vlad Zamfir
[9] Why application specific blockchains make sense — Gautier MARIN
