sharpdata

L1 vs L2: Entering The Endgame （转载）

sharpdata@newsletter.paragraph.com (sharpdata) — Sat, 08 Jan 2022 03:50:35 GMT

又是Delphi的一力作，值得仔细阅读。

https://members.delphidigital.io/reports/l1-vs-l2-entering-the-endgame/

部分图未copy过来，建议通过链接阅读。

Key Takeaways

Monolithic chains are bounded by what a single node can process, whereas modular ecosystems surpass this limitation, offering a more sustainable form of scaling.

A key motivation behind modularity is efficient resource pricing. Modular chains can offer more predictable fees by separating applications into different resource pools (i.e. fee markets).

Modularity, however, introduces a new problem known as data availability, which can be addressed several ways. Rollups, for example, batch off-chain data and submit it on-chain. By making the “data available” on-chain, they overcome this issue and inherit the underlying security of the base layer, establishing trustless L1<>L2 communication.

The newest form of modular chains, known as specialized data availability (DA) layers, is designed to act solely as a shared security layer for rollups. Given their scalability advantages, DA chains may become the end game of blockchain scaling. Celestia is the pioneering project on this front.

ZK-Rollups can offer more scalability than Optimistic Rollups, which is already being seen in practice. dYdX, for example, has been processing roughly 10x more throughput than Optimism while consuming 1/5th of it’s L1 footprint.

BOOKMARKPDF

On-chain activity is taking off at warp speed, and with it so is demand for blockspace. While Ethereum’s blocks have been nearly full for over a year, we’ve seen multiple L1 & L2 networks gain meaningful traction.

At its core, this is a scalability war. And this introduces technical terms like parachains, sidechains, bridges, zones, shards, rollups, data availability, and a plethora of others. In this post, we aim to dampen this noise and elaborate on this scalability war. So grab a cup of coffee or tea before you strap yourself in, because this is going to be a long ride.

Searching For Scalability

Ever since Vitalik’s famous scalability trilemma, there has been a misconception in the crypto community that the trilemma is set in stone and that everything must be a trade-off. While this is true most of the time, every now and then we see the boundaries of the trilemma stretched — either via real innovation or by introducing additional (but reasonable) trust assumptions.

We highlight some of these examples as we go through the different designs. But before we start, it’s important to define what we mean by scalability. Put simply, scalability is the ability to process more transactions without increasing the cost to validate them. With that in mind, let’s take a look at current TPS figures for various chains. Throughout this post, we’ll explain the design properties that enable these varying levels of throughput. Importantly, the numbers shown below are not the max levels that can be achieved, but rather the actual historical levels which are dependent on usage.

Monolithic vs Modular

Monolithic Blockchains

First, let’s zoom in on standalone chains. Under this camp, Polygon PoS and BSC don’t match our scalability definition as they increase throughput via bigger blocks — a well-known trade-off that increases the resource requirement of nodes and sacrifices decentralization for a performance improvement. While this trade-off has its market fit, it’s less compelling as a long-term solution. Polygon, however, recognizes this and is pivoting to a more sustainable solution centered around rollups.

Solana, on the other hand, comes as a serious attempt to push the boundaries of a fully composable, monolithic chain. The secret sauce of Solana is known as the Proof of History (PoH) ledger. The idea with PoH is to create a global notion of time — a global clock — whereby all transactions, including consensus votes, carry reliable timestamps attached by the issuer. These timestamps allow nodes to make progress without waiting to synchronize with each other on every block. Solana further complements this ability by optimizing its execution environment to process transactions in parallel, as opposed to one at a time as in the case of EVM, to achieve a higher scale.

Even though Solana’s throughput gains are beyond what can be achieved by simple parameter tweaks, it’s still in large part owed to more intensive hardware and network bandwidth usage. While this lowers fees for users, it restricts node operations to data centers. This comes in contrast to Ethereum which, although inaccessible to many due to exorbitant fees, is ultimately governed by its active users who can run nodes from home.

Where Monolithic Chains Fail

Scalability in a monolithic chain is ultimately bounded by what a single, powerful node can process. Regardless of subjective opinions on decentralization, this capacity can only be pushed so hard before it restricts governance into the hands of relatively few actors. In contrast, modular chains split the total work among different nodes so that more throughput can be produced in total than what any single node can process.

Crucially, decentralization is only one-half of the modularity picture. The other motivation behind modular chains, as important as decentralization, is efficient resource pricing (i.e. fees). In a monolithic chain, all transactions compete for the same blockspace and consume the same resources. Naturally, in the scenario where a chain gets crowded, outsized demand for a single app has adverse effects for all apps on the chain as fees rise for everyone. This has been Ethereum’s reality ever since CryptoKitties clogged the network in 2017. Importantly, additional throughput never really solves the problem once and for all – it merely postpones it. The internet’s history tells us that every additional capacity increment makes room for new, otherwise infeasible applications which tend to quickly consume the additional capacity that has just been added.

Finally, a monolithic chain simply can’t optimize itself for vastly different applications with different priorities. In the case of Solana, one example could be Kin and Serum DEX. Solana’s low latency is suitable for an app like Serum DEX. However, maintaining such latency also necessitates a restriction on state growth which is enforced by charging a state rent for every account. This, in turn, has adverse effects on account-heavy applications like Kin who can’t offer Solana’s throughput to the masses due to high fees.

Looking into the future, it’s naïve to expect a single resource pool to reliably support the diverse range of applications crypto enables; from the Metaverse and gaming to DeFi and payments. While increasing the throughput capacity of a fully composable chain is useful, we need a wider design space and better resource pricing for mainstream adoption. This is where modular approaches come into play.

The Evolution of Blockchains

In the holy mission of scaling, we’re witnessing a trend shift from “composability” to “modularity”. First, to define these terms: composability refers to the ability for applications to seamlessly interact with one another in friction minimized fashion while modularity is the facility for a system to be broken down into multiple individual parts (modules) that can be stripped and re-assembled at will.

Ethereum Rollups, ETH 2.0 Shards, Cosmos Zones, Polkadot Parachains, Avalanche Subnets, Near’s Chunks, and Algorand Co-Chains can all be thought of as modules. Each of these modules processes a subset of the total workload in their respective ecosystems while maintaining the ability to cross-communicate. As we dive deeper into these ecosystems we will notice that modular designs greatly vary with how they approach security across modules. Multi-chain hubs like Avalanche, Cosmos, and Algorand are most suited for independently secured modules whereas Ethereum, Polkadot, Near, and Celestia (a relatively new L1 design) envision modules that ultimately share or inherit security from one another.

Multi-Chain / Multi-Network Hubs

The simplest modular design is known as interoperability hubs. This refers to multiple chains/networks which communicate with each other through a standard protocol. Hubs enable a wider design space as they can have application-specific chains customized on many different levels; this includes the virtual machine (VM), node requirements, fee models, and governance. An app-chain’s flexibility can’t be matched by smart contracts on a general-purpose chain. Let’s briefly go over some examples:

Terra, which powers more than $8B worth of decentralized stablecoins, has a special fee and inflation model optimized for the adoption and stability of its stablecoins.
Cross-chain DEX Osmosis, which currently processes the largest IBC throughput, wants to encrypt its transactions until they are finalized to prevent front-running.
Algorand and Avalanche aim to host enterprise use cases on custom networks. These can range anything from a CBDC run by government agencies to a gaming network run by a committee of gaming companies. Importantly, the throughput of such networks can be boosted by beefier machines without impacting the decentralization level of other networks/chains.

Hubs also offer scalability advantages to the extent that they provide more efficient use of resources. Take Avalanche as an example. The C-Chain is for EVM compatible smart contracts while the X-Chain is for P2P payments. Because payments can often be independent of each other (Bob paying Charlie is not dependent on Alice paying Dana), the X-Chain can concurrently process certain transactions. By separating the VMs based on their core utility, Avalanche can thus process more transactions.

These ecosystems can also vertically scale through fundamental innovations. Avalanche and Algorand particularly stand out here as they achieve a higher scale by reducing the communication overhead of consensus. Avalanche does this through a “sub-sampled voting” process while Algorand uses a cheap VRF for nodes to randomly select a unique committee for consensus on every block.

So far, we’ve laid out the advantages of the hubs. However, this approach hits some key limitations as well. The most obvious limitation is the need for chains to bootstrap their own security, as they are unable to share or inherit security from one another. It’s known by now that any secure cross-chain communication requires a trusted third party or synchrony assumption. In the case of hubs, the trusted third party becomes the majority validators of the counterparty chain.

For example, a token pegged from one chain to another via IBC can always be redeemed out (stolen) by a malicious majority of source-chain validators. This majority trust assumption may work fine today where only a handful of chains co-exist. However, in an possible future where there are a long tail of chains/networks, expecting these chains/networks to trust each other’s validators to communicate or share liquidity is far from ideal. This brings us to rollups and sharding that offer cross-communication with stronger guarantees beyond majority trust assumptions.

(While Cosmos will introduce shared staking across Zones and Avalanche can have multiple chains validated by the same network, these solutions are less scalable as they impose heavier requirements on validators. In practice they are likely to be adopted by most active chains and not the long tail.)

Data Availability

After years of blood sweat and tears, it has become widely accepted that all security sharing efforts boil down to a very subtle problem called data availability. To understand why, we must shortly re-visit how nodes operate in a typical blockchain.

In a typical blockchain, full nodes download and validate all transactions while light nodes — who don’t have the necessary resources for intensive audits (99% of users) — only check block headers (summary of the block committed by majority validators). As such while full nodes can independently detect and reject invalid transactions (for ex. unlimited printed tokens), light nodes deem whatever the majority commits to as a valid transaction.

To improve on this, ideally, any single full node can protect all light nodes by issuing small-sized proofs. Under such design, light nodes can operate with similar security guarantees as full nodes without spending as many resources. However, this introduces a new problem known as DA.

If malicious validators publish a header, yet withhold some or all transactions in the block, full nodes won’t be able to tell if the block is valid because the missing transaction(s) may be invalid or cause a double spend. Without this knowledge, full nodes can’t generate a fraud-proof for invalidity to protect light nodes. In conclusion, for a protection mechanism to work in the first place, light nodes must make sure that a full and complete list of all transactions has been made available by validators.

The DA problem is an indispensable part of modular designs looking to go beyond majority trust assumptions when it comes to cross-communication. What makes rollups special amongst L2s is that they don’t try to get around this problem.

Rollups

In the context of rollups, we can think of the main chain (Ethereum) as a light node to the rollup (Arbitrum). Rollups post all their transaction data on L1 so that any L1 node willing to put the resources together can execute them and construct the rollup state from scratch. With the full state at hand, anyone can transition the rollup into a new state and prove the validity of the transition by issuing validity or fraud-proof. Having data available on the main chain allows rollups to operate under a negligible single honest node assumption instead of an honest majority.

Consider the following to understand how rollups achieve better scalability with this design:

Since any single node with the current rollup state can protect all others without the state, centralization of rollup nodes is less of a risk, and therefore rollup blocks can be made reasonably bigger.
Even though all L1 nodes download a rollup’s data with regards to their transactions, only a fraction of them execute these transactions and construct the rollup state, thereby reducing overall resource consumption.
A rollup’s data is compressed using clever techniques before getting posted on L1.
Similar to app chains, rollups can tailor their VM for specific use cases which implies more efficient use of resources.

By now it’s common knowledge that there are two broad rollup categories: Optimistic rollups and ZK-rollups. From a scalability perspective, ZK-rollups are more advantageous than Optimistic rollups because they compress data in a more efficient manner thereby achieving a significantly lower L1 footprint for certain use cases. This nuance is already seen in practice. While Optimism posts data to L1 to reflect every transaction, dYdX posts it to reflect every account balance. As such, dYdX’s L1 footprint is 1/5th that of Optimism, and it’s estimated to process roughly 10x more throughput. This advantage naturally translates into lower fees for ZK-rollups.

Unlike fraud-proofs on Optimistic rollups, validity proofs from a ZK-rollup also enable a new scalability solution known as volition. Although the full effects of volition remain to be seen, they seem very promising as it gives users the freedom to decide whether to post data on-chain or off-chain. This allows users to decide on their security level on a per transaction basis. Both zkSync and Starkware have volition implementations launching in the next weeks/months.

Even though rollups apply clever techniques to compress the data, all data must still be posted to all L1 nodes. Therefore rollups can only offer linear scalability gains and are limited in how much they can reduce fees. They’re also highly impacted by the volatility of Ethereum gas price. For sustainable scaling, Ethereum needs to scale its data capacity – which explains the need for Ethereum sharding.

Sharding & DA Proofs

Sharding further relaxes the requirement for all main chain nodes to download all data, but instead make use of a new primitive known as DA proofs to achieve higher scalability. With DA proofs, instead of all nodes downloading all of the data from every shard, each node downloads only a tiny fraction of shard chain data, knowing a minority of them can collectively reconstruct all shard chain blocks. This enables shared security across shards as it ensures that any single shard chain node can raise disputes to be resolved by all nodes on-demand. Polkadot and Near have already implemented DA proofs in their sharding design, and this will also be adopted by ETH 2.0.

At this point, it’s worth mentioning how ETH 2.0’s sharding roadmap differs from others. Although the initial roadmap of Ethereum was to shard execution just like Polkadot, it seems to have recently pivoted to sharding data only. In other words, shards on Ethereum will serve as DA layers for rollups, which in turn perform all the execution. This means Ethereum will continue to have a single state just like today. In contrast, Polkadot performs all execution on the base layer where each shard has a different state.

A major advantage of having shards as pure data layers is the flexibility for rollups to dump data on multiple shards while remaining fully composable. A rollup can therefore have throughput and fees unbounded by the data capacity of a single shard. With 64 shards, the max aggregate throughput of rollups is expected to increase from 5K TPS to 100K TPS. In contrast, no matter how much throughput Polkadot generates as a whole, fees will be bound by the limited throughput capacity of a single parachain (1000-1500 TPS).

Specialized DA Layers

Specialized DA layers are the latest form of modular blockchain design. They use the base idea of ETH 2.0’s DA layer, but steer it in a different direction. The pioneering project on this front is Celestia, but newer solutions such as Polygon Avail are also heading in this direction.

Similar to the DA shards of ETH 2.0, Celestia acts as a base layer that other chains (rollups) can plug into in order to inherit security. Celestia’s solution differs from Ethereum in two fundamental ways:

It doesn’t perform any meaningful state execution at the base layer (and ETH 2.0 does). This frees rollups from highly unreliable base layer fees which, in a stateful environment, may spike any time there is a token sale, NFT airdrop, or high-yield farming opportunity. Rollups consume the same resources (i.e. bytes in the base layer) for security, and security only. This efficiency allows rollup fees to be predominantly tied to the usage of that particular rollup instead of the base layer.
Celestia can grow its DA throughput without sharding thanks to DA proofs. A key property of DA proofs is that as more nodes participate in sampling, more data can be stored as there is additional collective work being done. In the context of Celestia, this means blocks can be made bigger (higher throughput) as more light nodes participate in DA sampling (without centralization).

As with all designs, specialized DA layers also carry some drawbacks. One immediate drawback is the lack of a default settlement layer. As such in order to share assets with each other, rollups will have to implement methods to interpret each other’s fraud proofs.

Conclusion

We have evaluated different blockchain designs including monolithic chains, multi-chain hubs, rollups, sharded chains, and specialized DA layers. Given their relatively simple infrastructure, wider design space and ability to expand horizontally we think multi-chain hubs are best suited to address the immediate needs of blockchain space. In the longer term, given their resource efficiency and unique scalability properties, specialized DA layers may very well be the end-game.

The Cosmos Ecosystem Has Arrived (转载）

sharpdata@newsletter.paragraph.com (sharpdata) — Sat, 08 Jan 2022 03:46:38 GMT

发表于2021/9/15的一篇文章，当时币价40左右，后面真实跌倒怀疑人生（$22)。

现在继续看好Cosmos生态

https://members.delphidigital.io/reports/the-cosmos-ecosystem-has-arrived/

Key Takeaways

The Cosmos ecosystem is comprised of several Application-Specific Blockchains (“App-Chains”), which are all optimized for their given use case. In the past, these App-Chains were siloed and unable to communicate with one another. Now, with IBC seeing increased adoption, that is starting to change.

At the center of the ecosystem lies The Cosmos Hub, an App-Chain secured by validators staking ATOM, the native token of Cosmos. The Cosmos Hub offers three primary use cases which can accrue value to ATOM – 1) IBC, 2) Gravity DEX, and 3) Shared Staking. Only IBC is fully live at the moment. Emeris, the main Gravity DEX frontend, is still in Beta.

Osmosis, which launched on June 19th, is an App-Chain that offers a customizable AMM. It was the first IBC-Native DEX to go live and has attracted a current TVL of ~$440m. Shortly after, it was unveiled that another IBC-Native exchange, Gravity DEX, would be launched directly on The Cosmos Hub.

Osmosis and The Cosmos Hub are in a unique situation, where they complement, yet also compete, with one another. They both can act as Hubs, facilitating IBC transfers and they both will have DEXs as their primary application. One of the main differentiators for The Cosmos Hub is that it plans to offer Shared Staking in the future, which ultimately could be the wild card for ATOM value accrual.

There are several important catalysts coming up for Cosmos, such as Columbus 5 on September 30th and Emeris fully launching to go along with Proposal 56 (Adding the IBC Router to the Cosmos Hub). Shared Staking may also debut on Testnet as early as Q4 and the Gravity Bridge is coming soon.

BOOKMARKPDF

An Introduction To Cosmos

Competition amongst the various Layer 1s has never been hotter. Ethereum, Solana, Avalanche and others have continued to see their token values appreciate as more applications come online and liquidity deepens within their respective ecosystems. Cosmos, a promising ecosystem of its own, has made major strides over the past year but it is often misunderstood. Why? Well, to put it simply, Cosmos is built differently. To understand how, let’s start with a basic comparison to Ethereum. Being the general purpose blockchain that it is, different types of applications are built directly on top of Ethereum. They all share the same security and they all compete for the same blockspace. This has its advantages, namely composability and strong security guarantees, but it also comes with drawbacks, such as high fees from network congestion.

In contrast to this, “Cosmos” is not a single blockchain where all of the applications exist. Rather, it is an ecosystem of many blockchains, all optimized for their specific application. Historically, one of the main things holding the Cosmos ecosystem back was the simple fact that these “App-Chains” couldn’t communicate with one another. The composability between applications, which played such a vital role in Ethereum’s success, was lacking. Importantly, however, this is no longer the case now that the Inter-Blockchain Communication Protocol (aka “IBC”) is live. Even though IBC was launched in February 2021, it hasn’t been implemented by all of the major App-Chains yet. Being such a new and important piece of technology, the hesitation from development teams has mostly centered around a desire to see it functioning as intended out in the wild, for a period of time, before plugging into it. But that is now finally starting to change and the Cosmos ecosystem seems poised to blossom as a result.

In this report, we’ll walk you through how Cosmos works, analyze its traction thus far, and speculate about what the future has in store for it. Before we jump into the more complex points, let’s start by clearly outlining a few key terms that you’ll see repeatedly throughout this post.

App-Chain: An independent blockchain optimized for a specific use case / application. They are built using Cosmos SDK, which allows developers to plug-and-play modules with different functionality (e.g. IBC) when constructing their blockchain. In the absence of Shared Staking, which we’ll cover later on in this post, App-Chains have their own sovereignty and security assumptions.
Zone: An App-Chain, or independent non-Cosmos chain, that has an integration for IBC established. IBC modules communicate with each other by sending data packets over channels.
Hub: In the most basic sense, a Hub is a Zone that has a lot of channels connected to it, allowing it to facilitate IBC between them. While any Zone could theoretically act as a Hub, this language is most often used in the context of the The Cosmos Hub in particular. We’ll revisit the implications of this later in the post.

With this jargon in mind, let’s now walk through each component with diagrams that illustrate how the various pieces come together. Let’s start with one of the most important building blocks, Cosmos SDK, and how it’s used to create App-Chains, as seen below.

It can be easy to underestimate the number of blockchains that have already been built using Cosmos SDK. If you venture over to cosmos-cap.com, you’ll certainly notice some recognizable names. Over time, we expect the proliferation of App-Chains to increase, particularly as new modules are added to the SDK, while existing ones are battle hardened / improved. At the time of writing, the combined market cap for all Cosmos-based blockchains is ~$110B.

Now, a single App-Chain is useful on it’s own but it’s full capabilities aren’t truly unlocked until it connects to the broader Cosmos ecosystem. In the diagram below, we’ve depicted how this ecosystem is intended to come together. At the center lies The Cosmos Hub, an App-Chain secured by validators staking ATOM, the native token of Cosmos. The Cosmos Hub area of the diagram is comprised of three distinct rings, which we use to illustrate the three different use cases it supports – 1) IBC, 2) Gravity DEX and 3) Shared Staking. For our explanation we’ll start with the outer ring, IBC, and work our way in.

If you recall the definitions from earlier, an App-Chain that implements the IBC module would subsequently be classified as a Zone. Now, imagine a Zone that opens communication channels with all of the other Zones. What we just described is essentially a Hub. As you can imagine, if there are hundreds or thousands of Zones out there, having each of them connect to one another directly would be cumbersome, resource intensive and perhaps inefficient. Contrasting that approach, if a Zone simply opens a communication channel with a Hub, which has already done all of the heavy lifting from a networking perspective, they can easily interoperate with all of the other Zones connected to said Hub. This is the rationale for why Cosmos uses a “hub-and-spoke” model, which can be seen in the graphic below from mapofzones. Note the two Zones that we’ve highlighted in the map below, more on them soon.

Once interoperability is established, liquidity begins to flow. Where liquidity flows, there exists an opportunity for a decentralized exchange to capitalize on it. Since this is Cosmos, that DEX application would be its own blockchain. Which brings us to Osmosis, the first IBC native DEX in Cosmos. If you’ve been a long time Delphi member, a cross-chain, Cosmos-based DEX may sound familiar. And you’d be right, we first wrote about this topic in our THORChain report from December 2020. In that post, we highlighted how a cross-chain DEX would offer meaningful utility and could accrue significant value. We even took subtle shots at the ATOM token on slide 6 of the report because, despite THORChain being built using Cosmos SDK, the ATOM token didn’t stand to directly benefit from its usage. We probably weren’t the first, nor the last, to levy that type of critique on the ATOM token.

Interestingly enough, Cosmos’ development team recently decided to build an exchange – Gravity DEX – directly into The Cosmos Hub, likely to the chagrin of the Osmosis development team. While Gravity DEX improves the value accrual of the ATOM token, it does hurt claims that The Cosmos Hub is credibly neutral. Before we move on, we should note that the main difference between Osmosis / Gravity DEX and THORChain is that the latter is focused on facilitating trades between non-Cosmos-based chains (e.g. Bitcoin & Ethereum) while the former are focused on the Cosmos ecosystem specifically, at least at this stage.

The final ring from the diagram, in blue, is for Shared Staking (Interchain Security), which may come to testnet as early as Q4 this year. Historically, we’ve seen App-Chains bootstrap their validator sets on their own. For a new chain starting out, with a low token price, this can be difficult due to the weak security it has at that stage. But what if new apps were able to offload this resource intensive endeavor to an external party and instead focus on building the core product? You know, like on Ethereum. We’d see a faster time to market with new apps and a more rich ecosystem connected via IBC. This is where shared security comes into play. It places ATOM validators, from The Cosmos Hub, on the forefront where they are able to lease out security to multiple App-Chains that opt-in, for a price. This is an attractive proposition for validators because they can earn more fees supporting multiple “child chains”, instead of only staking The Cosmos Hub (i.e. the “parent chain”).

With Shared Staking still fresh in your minds, let’s shift our focus and evaluate the current state of the Cosmos Hub’s validator set (i.e. ATOM stakers). As seen in the pie chart above, the top 10 validators account for 48% of all the ATOM staked. For context, the total number of validators is 144 currently. Previously, this had been capped at 125 validators but a governance proposal a few weeks ago voted to raise the maximum to 150.

Importantly, The Cosmos Hub implements DPoS meaning that passive ATOM holders can delegate their staked tokens to active validators in return for a portion of the yield. The exact amount of revenue that is shared varies by validator (you can monitor it here). The greater the revenue share, the more delegators that validator should logically have. When combining the amount of ATOM staked by validators / delegators, 67.8% of all ATOM is currently bonded. While this is down from 70.6% in July, we should note that it’s just north of The Cosmos Hub’s target bonded ratio of 66%.

ATOM stakers earn a return from two primary sources – 1) new ATOM issuance and 2) transactions fees from The Cosmos Hub. Regarding the first point, ATOM’s current annualized inflation rate is ~7%. Regarding the latter point, fees can be derived from several different sources. As we prefaced earlier, The Cosmos Hub supports IBC, Gravity DEX, and Shared Staking, all of which it stands to earn fees from. Since IBC is the only one of those sources that is fully live, let’s quickly recap its recent activity.

Earlier in this report, we outlined how Zones open communication channels between one another to facilitate IBC transactions. The more channels that are open, the more transactions that can happen. With that context in mind, it may come as a surprise to see The Cosmos Hub, which greatly leads total channel count, with fewer IBC transfers than Osmosis, in the chart above. Let’s explore this more.

Osmosis: The First IBC-Native DEX

Osmosis launched on June 19th, with a go-to-market strategy that focused on attracting native IBC assets into its liquidity pools. Osmosis isn’t your typical one-size-fits-all AMM. It offers customizability such as supporting different price curves and self-governing liquidity pools. It supports LBPs, similar to Balancer, which will likely be attractive to new projects launching in Cosmos. The development team is also working on superfluid staking, which will allow Osmosis LPs to delegate their LP tokens to validators. This will enable them to earn liquidity mining rewards and staking rewards at the same time. Notably, 23% of the Osmosis circulating supply is staked and it has 100 bonded validators with an APR of 186%.

Earlier we teased the competition between Osmosis and Gravity DEX. In the table above, we’ve provided a quick comparison of the two. There are several reasons why Osmosis is currently in the lead. To start, and perhaps most importantly, it’s the only one which is fully live, so there’s that. But it has also benefited from leveraging its token supply to liquidity mine traction, attracting a current TVL of ~$440m. This is an impressive amount of liquidity to attain in only a few months and in such a nascent ecosystem.

At a technical level, Gravity DEX is primarily differentiated from Osmosis due to its hybrid orderbook design. It remains to be seen how / if Gravity DEX will offer liquidity mining incentives similar to what Osmosis did. The ATOM token has been around much longer than the OSMO token, so there might be less flexibility in how it could be used as a carrot. The main thing Gravity DEX has going for it is the fact it’s built directly on The Cosmos Hub, putting it in a strong position to directly benefit from the continued adoption of IBC. Although, as an earlier chart showed, channel count isn’t everything and there’s nothing stopping Osmosis’ Zone from being a Hub itself.

Osmosis’ liquidity has been built up entirely using IBC without CEX support. This means, to purchase OSMO, traders have had to use one of the OSMO pairs, like ATOM/OSMO, on the DEX itself. The ATOM/OSMO pool continues to have the deepest liquidity, representing 37% of total TVL.

Increased pool utilization leads to more trading fees being generated. As seen in the chart above, the ATOM/OSMO pool has a 7D volume / liquidity ratio of ~0.20x, which is low relative to other major DEXs like Uniswap V3.

Cosmos Value Accrual

Since its launch, Cosmos has only generated ~$215k in total fee revenue and currently trades at a P/S ratio of 9,072x, according to Token Terminal. To be fair, however, this low level of revenue is to be expected given how new IBC is as a technology, and how metered its implementation has been on the part of App-Chains. On the bright side, revenue growth is trending in the right direction and there are a number of upcoming catalysts primed to pour fuel on its growth.

Upcoming Catalysts for Cosmos

Columbus 5 – The highly anticipated Mainnet upgrade to Terra scheduled for September 30th, which will see Terra add support for IBC. While this is arguably more bullish for Terra itself, there should be a trickledown impact that benefits ATOM stakers. Stablecoins are vital for users and the added support for IBC should open the door for UST to become the leading stablecoin within the Cosmos ecosystem.
Gravity Bridge – This is a Cosmos <> Ethereum bridge that will run on The Cosmos Hub and may debut as early as Q4. It could play a key role, tapping into all of the TVL on Ethereum. As we saw with Avalanche’s upgraded bridge, a smooth UX can make a big difference.
Emeris – A cross-chain DeFi aggregator, starting with Gravity DEX, whose beta launched on August 17th.
Add IBC Router to the Hub (Proposal 56) – The IBC Middleware module will enable the hub to play the role of IBC Router. Through governance, a fee can be added over time to benefit ATOM stakers.
Shared Security / IBC / Gravity DEX – Please refer to previous sections.
Future Airdrops – On October 1st, Juno Chain is scheduled to go live and will airdrop its tokens to ATOM stakers who were active during the February 18th Stargate launch. If this trend continues, it would be similar to the ecosystem airdrops we saw succeed on Terra. You can monitor for potential airdrops coming to ATOM stakers here.

Each of these catalysts has the potential to attract deeper liquidity and more users, while also enhancing the overall utility of the Cosmos ecosystem. Ultimately, they are net positive for ATOM stakers who stand to benefit from the increased transaction fees that would result.

Closing Thoughts

Let’s revisit this graphic.

In the center, we have The Cosmos Hub highlighted in blue and to the right, we have Osmosis’ Zone in pink. Recall that any Zone, if it has enough channels connected to it, could be deemed a Hub. This raises the question – will the Cosmos ecosystem revolve around a single mega Hub or will it have several large Hubs? We’re inclined to lean towards the latter, as it is already playing out between Osmosis and The Cosmos Hub. Both can facilitate IBC and both have native DEXs built into them. The main differentiator for the Cosmos Hub is that it plans to offer Shared Staking in the future, which is unique and ultimately could be the wild card for ATOM value accrual.

Is Cosmos a Layer 1? Technically, yes The Cosmos Hub is a blockchain. But unlike the other major Layer 1s (Ethereum, Solana, etc.), Cosmos has to quasi-compete against the applications within its own ecosystem, at least with regards to other DEXs now. There is a possible, albeit less likely, scenario where the Cosmos ecosystem continues to grow and flourish, even if The Cosmos Hub itself doesn’t retain staying power. This type of situation is simply not possible on other networks. Of course, the more App-Chains there are, the more activity there will be within the Cosmos ecosystem, which ATOM stakers could benefit from.

At the time of writing, OSMO‘s fully diluted valuation is ~66% that of ATOM‘s ($6.2b vs $9.3b, respectively). Now, you could compare ATOM’s valuation to that of Ethereum and Solana and say “hey, this looks cheap” relatively speaking. That would be a fair conclusion to reach. The question we’ll leave you with, however, is this – “by that same train of logic, wouldn’t Osmosis, Terra, and all the other App-Chains look cheap as well?” After all, they are Layer 1s too, and they were built using the same SDK. Indeed, perhaps the real differentiator regarding valuations is that a network like Ethereum stands to benefit from all the applications that exist on top of it, while App-Chains only benefit from the single/few applications they directly support.

The Cosmos Hub is an App-Chain. To thrive, it will need to find its own killer app. Maybe that’s Shared Staking, maybe that’s Gravity DEX, or maybe it’s simply being the best IBC hub out there.