Cosmos has historically been an ecosystem that has promoted horizontal scalability, as opposed to vertical scalability. The Cosmos ecosystem has been able to scale horizontally more efficiently than any other ecosystem as a result of having the most mature interoperability protocol and software development kit in cryptocurrency, known as the Inter-Blockchain Communication Protocol (IBC) and Cosmos Software Development Kit (Cosmos SDK). Simply put, IBC is a set of standards that facilitates communication between blockchains in the Cosmos and the Cosmos SDK is an open-source framework for building permissionless Proof-of-Stake (PoS) blockchains. IBC and Cosmos SDK enable teams to spin-up application-specific PoS blockchains with ease, which connects to all other PoS blockchains built with Cosmos SDK and IBC. As of time of writing, there are 46 zones (Cosmos SDK blockchains) that are connected to IBC. The power of having the flexibility and optionality to create your own blockchain in the Cosmos allows the ecosystem to scale ‘horizontally’. Any time blockspace reaches capacity on a single blockchain, another blockchain can be conceived that connects to the existing blockchain. This is in stark contrast to other ecosystems such as Ethereum, whereby an application suffers if blockspace on Ethereum is at capacity because bandwidth becomes much more expensive. Now, for the first time in Cosmos history, there are multiple vertical scaling solutions being built in the Cosmos ecosystem that complement existing horizontal scaling solutions that already exist within the ecosystem. This article focuses on four vertical scaling solutions being worked on in the Cosmos, which include (Cosmos Hub) Interchain Security, Dymension, Celestia and Saga. The Cosmos ecosystem is unique in that each vertical scaling solution being worked on intrinsically scales horizontally as well, thanks to the flexibility facilitated by the modularisation of Cosmos.
When bandwidth becomes expensive on networks such as Ethereum, users suffer from high transaction fees. Networks such as Ethereum have attempted to solve issues with scalability by creating scaling solutions that work ‘vertically’, as opposed to ‘horizontally’. Vertical scaling entails another layer being built on top of Ethereum network, which leverages the underlying security of Ethereum (known as the Layer 1) yet handles transaction execution off-chain (known as the Layer 2). This is an important step to take transaction execution off-chain because as of right now, transaction execution on Ethereum is responsible for the majority of bandwidth woes. Another word for a Layer 2 is an execution layer because transactions are executed off-chain. After transactions are executed on a Layer 2 (execution) layer, a proof is sent to the underlying Layer 1 (e.g. Ethereum) of the state changes that have occurred off-chain. There is then either a period of time whereby other actors in the network can prove fraud if execution off-chain is different to what has been written on-chain (via fraud proofs) or a verifying contract on-chain has to verify the validity of a zero-knowledge proof coming from an actor such as a sequencer that must also ensure all transactions are available so any full node can recover all transactions in order to also verify that execution being written on-chain is correct. Without diving too deep into the technical details, simply speaking Layer 2s can save users gas due to superior encoding, which is well-explained by Vitalik Buterin here.
Using a Layer 2, or vertical scaling is an alternative way for users and applications to execute transactions off-chain and write data to the Layer 1 to save blockspace by using compressed data and calldata (as opposed to writing directly to storage of a Layer 1, which is more expensive bytes-wise) and hence results in lower transaction fees.
In the past, Cosmos and Ethereum have taken a completely different approach, with Ethereum focusing on vertical scaling and Cosmos focusing on horizontal scaling. Now, the two ecosystems seem to be converging as both are making progress towards incorporating elements of the opposite approach to scaling in order to compliment its existing work on either vertical or horizontal scaling. This article will focus on vertical scaling solutions that are in the works in the Cosmos ecosystem that aim to complement the existing horizontal scaling solutions that are already available in the Cosmos. In particular, this article will cover 4 vertical scaling solutions in no particular order that are being worked on in the Cosmos, including: Interchain Security, Dymension, Celestia and Saga.
The first vertical scaling solution to mention going live in the Cosmos is Interchain Security on Cosmos Hub. In short, Interchain Security allows networks to lease security from the Cosmos Hub. In practice, this means that networks do not have to spend time ‘bootstrapping’ validators for its network, which can be a drawback of horizontal scaling. To explain further, each network that goes live in the Cosmos has security equal to the amount of value it has staked, meaning there is an argument that networks could be seemingly less secure in the Cosmos if the amount of assets backing a network (staked) is not high enough. For example, due to the nature of Tendermint consensus, if a validator (or group of validators) controls more than 34% of stake on a network, it is able to halt finality in a Cosmos network and essentially censor a network. Therefore, it can be appealing for a Cosmos team to instead opt for using the security of Cosmos Hub, which currently has ~$1.5bn worth of stake (ATOM) securing it. Not only would a team not have to worry about increasing the value of its network to ensure the security of it but it can also ‘lease’ validators that already exist on Cosmos Hub and therefore not have to do business development work to obtain validators and work on its security budget for its own validator set. In return, a ‘consumer chain’ (a chain that borrows security from Cosmos Hub) pays a leasing fee to the Hub itself and those who secure it, which is x% of a consumer chain’s emissions schedule being redirected to Cosmos Hub delegators. The fee paid to Cosmos Hub delegators for each consumer chain will be specified in a Cosmos Hub governance post. A governance post that pitches a team’s vision / product is required from teams looking to rent security from Cosmos Hub because consumer chains are ‘permissioned’, meaning consumer chains can only borrow security from the Hub if enough ATOM holders vote YES on it in a governance vote. One nice feature of interchain security is that it gives team the choice of either creating their own ‘custom consumer chain’ or ‘contract consumer chain’. The main difference between the two comes down to the binary that validators run. In contract consumer chains this is standard, whilst in customer consumer chains teams have the flexibility of customising the binary to experiment with different transaction fees and transaction assembly. A good overview of Cosmos Hub interchain security versus other solutions is presented here:
Figure 1 — The advantages Interchain Security offers versus existing deployment options (source: Informal Systems)
Whilst the promise of leasing security from Cosmos Hub sounds enticing, there is a trade-off to be had here on decentralisation of Cosmos Hub. This is because validators that operate nodes on Cosmos Hub will also be required to run nodes for consumer chains simultaneously to the Hub (at least in version 1). This extra requirement on validators will likely result in validators needing ‘beefier’ hardware in order to keep up with the workload as consumer chains vertically scale whilst borrowing security from Cosmos Hub (similarly to shards borrow security from Ethereum in that ecosystem). To put it simply, validators suffer at the hands of making it easier for teams wanting to get a headstart with security and a validator set. However, it is important to note that consumer chains always have the option to create it’s own network (i.e. a team can use vertical scaling via interchain security to start and then transition to horizontal scaling outside of the Cosmos Hub with its own blockchain at a later point). To date, there is two projects that are a certainty to use interchain security, which is Quicksilver and Neutron. Quicksilver for example, has opted to use interchain security over building out its own network because it is focused on liquid staking, which directly impacts security of all Cosmos networks, therefore security of its own chain is paramount in order to keep the entire Cosmos ecosystem secure.
Another vertical scaling solution being worked on in the Cosmos is Dymension. Dymension is taking a very similar approach to Ethereum’s current vertical scaling roadmap. The main difference that Dymension is taking compared to Ethereum is the level of customisation and flexibility on offer versus what is available in Ethereum. Dymension is working on creating a Rollup Development Kit (RDK). The RDK takes inspiration from the Cosmos SDK and can be tweaked effortlessly by any team, depending on their needs. Dymension is working on ‘enshrined rollups’, which communicate and transact with the settlement layer via native protocols and modules and thus increase the overall security over traditional rollups. Another element Dymension has thanks to interoperability properties materialising from the Cosmos is that of native interoperability between Dymension rollups, which are connected to the Dymension settlement layer. Another unique property Dymension is leveraging that is not available in the Ethereum ecosystem is PoS for sybil resistance / to solve the keeper’s dilemma. Dymension has come up with a unique way to solve the keeper’s dilemma that rollups currently face in Ethereum.
Dymension is in its very early stages, so not much can be given away about the protocol design at this stage. The best way to think of Dymension is like Ethereum’s current settlement and execution layer design (e.g. ORUs executing tx off-chain and then writing state to the ‘settlement’ layer), only Dymension inherits many properties that makes Cosmos networks so dynamic, such as native interoperability, PoS and a developer framework to easily spin-up rollup chains.
Related to Dymension but also with its own unique design that is a vertical scaling solution going live in the Cosmos is Celestia. In a nutshell, Celestia is a ‘data availability network’. Breaking this down, Celestia validators guarantee that state (data) is available for verifiers to verify themselves that execution has been done properly off-chain in order to mitigate any need for a challenge period on the ‘settlement layer’. Celestia network itself does not execute any transactions. It is merely a network that has the latest state of an L2 that can be leveraged by verifiers to determine whether or not data is available (and therefore can reconstruct the previous state to check if execution has been done appropriately in different intermediate states). A nice design choice of Celestia is the way in which it uses 2d Reed-Solomon erasure coding to involve non-consensus nodes in determining whether or not data is indeed available. This is a scaling decision in itself, as light nodes in the past had no role in consensus. In Celestia, light nodes can probabilistically determine that all transactions are available because a block producer would have to withhold >50% of a block’s data in order for censorship to occur. Due to the technology of 2d reed-solomon erasure coding, it becomes a trivial task for light nodes to find out whether even just 1 transaction (which could be 1 in potentially thousands) is being censored by a block producer sequencing to a settlement layer. In data availability design without this, it is burdensome for light clients to sample transactions because if only 1 transaction was withheld (which could be critical), the more transactions that were being batched to a settlement layer, the harder it would be for a light client to find, the less security a roll-up would have.
In the Ethereum ecosystem, a rollup (such as Optimistic Rollup) could post calldata to Ethereum but it is still (relatively) expensive versus posting the same data to Celestia to ensure data is available (and therefore recoverable to challenge what is sequenced to the settlement layer). There is a chance that rollups that exist in Ethereum now might only use Ethereum in the future to challenge the off-chain execution if it was incorrect (and slash on Ethereum) and use Celestia as the data availability layer to verify that data is available in order to submit the challenge.
Celestia is also working on creating a framework that allows zones (outside of rollups) to also write transaction data to Celestia, whereby Celestia ensures it is available. In Celestia’s own words:
Optimint is the software that allows a chain to deploy directly on Celestia, as a rollup. It spins up its own p2p network, collects transactions into blocks and posts them onto Celestia for consensus and data availability.
Optimint is essentially a framework for developers to use that does not require them to undergo business development to find their own validators or create its own security budget as Celestia handles the work for them. Optimint is the consensus layer of Celestia, which provides a framework for transaction ordering that can be used in the data availability layer as well as settlement layer (if required). It is likely that Optimint could rival interchain security because the value proposition is the same for both of them. It is unknown how consensus will differ in Optimint vs Tendermint as it exists in Cosmos Hub today.
In any case, Celestia is a completely unique and elegant design that tailors to all execution layers’ needs. Celestia is blockchain-agnostic and provides consensus over data availability within an execution layer. This is a powerful concept and Celestia’s importance could transpire across both Cosmos and Ethereum in the near future.
Finally, another vertical scaling solution being built in the Cosmos is Saga. Saga is a network that is purpose-built to give each application that launches on its network its own execution environment. This means there could potentially be hundreds / thousands of ‘chainlets’ running on Saga. A core value proposition of Saga is that execution environments are customisable, an application has the flexibility to choose its own execution environment depending on its needs. The power of each individual application having its own execution environment is that resources can be managed in a more efficient way. Whenever one application runs out of blockspace, it can easily spin-up another execution environment that is focused on a particular subset of the activity from the original application via deploying another instance of the same smart contract in order to handle the load. Saga suffers a relatively similar fate to interchain security in that there is a lot of burden placed on validators in order to allow applications and application-specific chains to run smoothly. It is Saga’s intention to have chainlets provisioned by validators in a fully-automated way but this is a complex challenge to solve. If Saga is able to solve provisioning automation in an efficient way, it will be a force to be reckoned with within the Cosmos.
Figure 2 — An overview of the design choices made by Interchain Security, Dymension, Celestia and Saga
To conclude, traditionally Cosmos was fully-focused on scaling the ecosystem horizontally. Horizontal scaling is in stark contrast to the approach Ethereum has taken, which has focused on scaling the network vertically. In 2022, there has been a trend for teams to start working on experimenting with vertical scaling solutions in the Cosmos to complement the already existing horizontal scaling solutions that exist. The four major vertical scaling solutions that are being worked on in the Cosmos are Cosmos Hub Interchain Security, Dymension, Celestia and Saga.
Each vertical scaling solution comes with its own design choices and trade-offs. However one theme holds true amongst all vertical solutions being worked on in the Cosmos — flexibility. All vertical scaling solutions in the Cosmos are completely customisable and offer a tremendous amount of freedom for developers to experiment with. The original value proposition of the Cosmos — IBC, Cosmos SDK and Tendermint is being leveraged in different ways by new vertical solutions in the Cosmos. What is unique to scaling in the Cosmos is that it is intrinsically horizontal. All vertical scaling solutions being built still scale horizontally. This is in large part due to the seamless experience, standards and software development kits that are prevalent in the Cosmos. Even if a vertical scaling solution is built that leverages the security of an underlying validator set, it scales horizontally in an easier manner than what can be found in other networks because of the modularity of the Cosmos. For the first time in Cosmos history, vertical scaling will accompany existing horizontal scaling to pioneer what could be the most scalable blockchain ecosystem in existence.
Xavier Meegan is Research and Ventures Lead at Chorus One.
Medium: https://medium.com/@xave.meegan
Twitter: https://twitter.com/0xave
Chorus One is one of the largest staking providers globally. We provide node infrastructure and closely work with over 30 Proof-of-Stake networks.
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Telegram: https://t.me/chorusone
Newsletter: https://substack.chorusone.com
YouTube: https://www.youtube.com/c/ChorusOne
