Detailed explanation of the vertical expansion of Cosmos


We have introduced Cosmos many times. Similar to Polkadot, the Chain Agnostic Layer0 solution of Cosmos is mainly dedicated to solving the horizontal expansion problem of various blockchains built on it. Compared with Ethereum, Solana is a vertical expansion solution. , Cosmos can be understood as a horizontal expansion framework composed of independent zones, and Zone can be understood as various verification nodes in the Cosmos framework, security assumptions, and a sovereign blockchain that communicates through IBC.

Of course, compared to the single-chip chain of Ethereum, where nodes participate in verifying all issues (the capacity of the verifier is tight), the network of the application-specific chain is more scalable, so how do you understand it? If the Zone is congested or the block space is full, another blockchain can be connected to achieve horizontal expansion. For example, applications on Osmosis are blooming and the scalability of the chain has encountered a bottleneck. Then a new chain can be connected. The new chain can have its own verification node, or it can borrow the security of OSMO’s existing nodes in the form of a consumption chain. way to access. Pay attention to the understanding of horizontal expansion and IBC here. IBC solves the communication problem between chains and zones, rather than horizontal expansion. For example, they can communicate with each other by using Rollups, which use Zone as a settlement layer.

If a Zone starts to get congested then they can also introduce Rollups at the execution layer and use Celestia as the data visibility layer. If an area starts to get overcrowded, they can implement aggregation at the execution layer and have them use Celestia as the DA layer. Besides extensibility, its design framework and developer-friendly modular framework are also one of its core features. Developers can use various languages ​​(the Cosmos SDK uses Go language for development, but the contract is Rust; Goland, as a fork of the Cosmos SDK, uses Go language smart contracts), the current main languages ​​include Rust, Golang, CosmWasm, JavaScript and Solidity Also coming soon. Cosmos SDK, Tendermint, IBC, CosmWasm These core technology stacks of Cosmos are convenient for developers, allowing developers to focus on application-oriented development of specific blockchains.

Compared with the composability and programmability of Ethereum, which emphasizes interoperability and sovereignty, the application chain can have more flexibility and selectivity to customize its performance, operation and other parameters. At the same time, compared with the probabilistic confirmation block model such as POW, under the deterministic confirmation mechanism dominated by TendermintBFT, its anti-MEV design also introduces a transaction ordering mechanism (Tranasaction order mechainism, Osmosis is the forerunner of this mechanism). Interested Friends can watch the MEV game of the encrypted economy: Osmosis’s threshold encryption technology vs Flashbot’s SGX?.

Of course, the trade off of its design is also reflected in the following issues. Before cross-chain security is officially launched (Q3, 2022), all Zones are currently independently responsible for their security, and applications on Ethereum rely on their security. And we have mentioned before that the security of a network depends to a certain extent on the value of its pledged tokens to maintain its network, and when the TVL is greater than this value, it will bring potential risks to the network, so for some long-tail/new For the application chain, how to find a suitable security verification node and maintain a relatively stable currency price is particularly important.

Therefore, cross-chain security, Osmosis’s superfluid pledge, and Celestia DA, consensus and shared security are all trying to solve this problem. If you are interested in this, you can see the Cosmos technical principle, design framework and ecological overview. At the same time, IBC currently only supports cross-chain communication of homogeneous chains, and can support synchronous interaction inside the chain. Externally, IBC is also connecting to other heterogeneous chains represented by Polkadot, Near, EVM, etc. Internally, IBC The launch of the cross-chain account module will also support synchronous interaction between different chains (currently, chains represented by Juno v8.00, Osmosis, Cosmos Hub, etc. have been connected to the cross-chain account module).

So although there are some problems with the design of Cosmos, there are already good solutions. Since the horizontal expansion benefits from the natural “perfect” architecture of Cosmos, we will focus on its vertical scalability solutions in this article, including Celestia, cross-chain security, Dymension, etc., partly from our communication with related teams .


Celestia is currently the most interesting project in the modular blockchain, dedicated to solving the problem of data visibility. We also believe that the solution it proposes (whether Celestia will dominate the world is hard to say, but the direction chosen is very promising). ) is likely to become the mainstay of the Ethereum and Cosmos ecosystems. So what exactly does Celesita solve.

We think there are several directions: 1) Scalability. By separating the data visibility layer, the consensus layer and the execution layer, and through the data visibility sampling method, light nodes can ensure that the producer has released all the data without executing transactions. The data. The thing to understand here is that Celestia’s light nodes do not participate in validating transactions, but only need to ensure that data is visible and participate in data sorting. So compared to other L1 chains, Celestia nodes only ensure data visibility and transaction ordering through the Tendermint consensus protocol. There is no need to participate in the verification and execution of transactions like other L1s. This verification is handed over to the verification node of the settlement layer that Rollups relies on, and the execution is carried out on the client side of Rollups.

2) To solve the expansion route of Rollups centric, the biggest problem at present is that calldata is too expensive to be on-chain, although the current L2 vertical expansion solution of Ethereum moves transactions off-chain and sends data by compressing data and calldata to L1 (of course, this compression technique is much cheaper than sending directly to L1), but the cost is still high, so Celestia tries to solve this problem. For example, for Ethereum Rollups, they can choose Celestia as the DA layer. Celestia will send these proofs of processing (rather than the compressed data itself, which can be understood as a basket of signatures and Merk roots that are much cheaper than uploading data) to Ethereum, and optimize the gas cost by batch processing, So this is much cheaper than Rollups uploading compressed data directly to Ethereum. The whole process can be understood as Ethereum Rollup -> Celestia -> Ethereum main network. Of course, there is also a related solution to this problem in Ethereum 2.0 (EIP-4884). EIP-4844 introduces a transaction format that is different from the call data, with transactions with data fragments for storage. Data fragments can carry 125KB of data, and are much cheaper than calling data with the same amount of data. These pieces of data are typically deleted after a month, reducing storage requirements. And this month is enough time for validators to complete the security assumptions in the data sampling. For details, see The Ultimate Solution for Ethereum Expansion – Danksharding (1), and the Ultimate Solution for Ethereum Expansion – Danksharding and MEV Design (2).

3) The flexibility of multi-VM deployment. Unlike Rollups on Ethereum, Rollups on Celestia are not necessarily implemented for EVM-compatible fraud proofs/validity proofs. As far as we know, Celestia has collaborated with many teams (not yet officially announced). This opens up the design space for virtual machines that Celestia can support, and to more developers. We have seen that Starkware, LLVM, MoveVM, CosmWasm, FuelVM, etc. have custom virtual machines that can support operations, database structures, transaction formats, and software languages, and can achieve optimal performance while dealing with specific application scenarios. For FuelVM, we can focus on the recently launched Fuelv1, the biggest difference between Fuel and today’s ORus is that it runs a brand new VM architecture, namely FuelVM and its toolchain and language. FuelVM features WASM, EVM and Solana’s SeaLevel. The most compelling potential aspect of FuelVM is that it executes on a UTXO-based data model.

Ideas for a future multi-VM landscape are also described in CosmWasm: Evolving Virtual Machines and Smart Contracts. Of course, there are also advantages such as easy deployment and efficient resource pricing, which we will not discuss here.




The core design in Celestia is its Data Visible Sampling (DAS), which is also the premise of fraud proof/valid proof. The key of DAS lies in the erasure code technology, which means that any data can be doubled in size through the erasure code technology, and the original data can be recovered by extending any certain percentage of the data. In this way, the light nodes on Celestia can obtain small pieces of data in the way of data sampling, and ensure the visibility of the data based on a high probability.

Of course, in order to ensure enough data samples for data recovery, this sampling process should ensure the number of participating nodes. A core feature of DAS is that when the number of participating nodes is increased, the more data is collected, and based on the same probability assumption, more data can be verified. So in theory, when the number of participating nodes is more, the size of the block can be larger and support more TPS. This is different from the design of the monolithic chain. In the monolithic chain, the larger the number of nodes (full node verification), To ensure decentralization is achieved, block size/gas limits are set to suppress state growth, thus reducing the cost of full nodes.

Of course, the trade off problem of this design is that although light nodes can enjoy the same security as full nodes, they are limited by the bandwidth cost of O(√n), where n is the block size. Therefore, the visible throughput of Celestia data is mainly limited by the following two points:

  1. The amount of data that can be sampled collectively
  2. Target block header size for light nodes

Currently, there are two types of nodes on Celesita:

consensus node

Validation node: Participate in consensus.

Consensus full node: Celestia-App full node that synchronizes blockchain history.

Data Availability Node

Bridge Nodes: Bridge blocks between the data availability network and the consensus network.

Full Storage Node: Stores all data but does not connect to consensus.

Light Nodes: Light clients sample data availability on the data availability network.

Optimint is a product that allows chains to be deployed on Celestia as Rollups. These chains can start their own P2P networks, collect transaction data into blocks, and publish them to the Celestia mainnet, responsible for data visibility and consensus. Optimint is essentially a framework for developers to build chains on without having to find a secure validator, Celestia will handle the work for them.

Optimint can be understood as Celestia’s consensus layer, which provides a transaction ordering framework that can be used in the data availability layer and settlement layer (but does not participate in transaction verification). This seems to be similar to the concept of cross-chain security that we will introduce on the Cosmos Hub soon, and whether Optiminent will pose a threat to cross-chain security, we will also judge based on the differences in their consensus. But nonetheless, we believe that Celestia’s advanced concept and its importance in the Cosmos and Ethereum ecosystem will not be known until it goes live (2023). For those interested in Celestia, see our Celestia Modular Architecture and Celestia 2 – Technical Practice.

Cross-chain security

Cross-chain security can be understood as lease security in essence. Currently, only all nodes of the Cosmos Hub are supported in the V1 version. Of course, for the module itself, it is a pluggable and optional module. For the consumption chain that chooses to access, in the V1 version, the consumption chain must be forced to access 175 verification nodes, and needs to pass the governance, which is essentially a product with an access mechanism. The consumer chain needs to submit the core products and concepts of the team, and it can only be accessed after ensuring enough Atom holders to vote. At the same time, the consumption chain also needs to pay a certain fee (% inflation fee) to the validator node. This proportion also needs to be specified in the governance proposal. At the same time, in V1, the consumption chain will give 75% of the gas fee to the treasury DAO, and then Multi-signature wallet management, and 25% of the gas fee is given to the Hub to incentivize validators and stakers.

As mentioned in our previous article, teams can choose to create (embodies flexibility and optionality) “custom consumer chains” or “contract consumer chains (implemented through CosmWasm)”. The main difference between the two is the binaries that the validator nodes run. The binaries in the contract consumer chain are standard, while in the custom consumer chain, teams can flexibly customize the binaries to accommodate different transaction fees and transaction assemblies. There will be three versions of ICS in total. The first version is that the security of the consumption chain is completely maintained by the Cosmos Hub nodes. Whether these consumption chains can be connected needs to be finally decided by Cosmos Hub through governance according to their risk profile (for example, whether it is a consumption contract chain developed based on Cosmwasm or a consumption custom chain with unchanged SDK).

Therefore, Atom stakers need to decide which validator they stake, because while enjoying the extra benefits, they also face the same risk of downtime and misbehavior of consumer chain nodes as other POS chains. In the first version, the consumer chain and the Cosmos Hub shared a common security guarantee. However, in this case, the Atom value pledged by the nodes participating in ICS and the slashing risk these nodes will face. At the same time, for validating nodes, additional hardware requirements are required to guarantee the workload. In the second version, the consumption chain can combine its own pledged tokens with the Atom tokens of the Cosmos Hub, and finally determine the composition of the validator set of the consumption chain. In the V3 version, this relationship will be further expanded and deepened, and a horizontal shared security protocol can be implemented between two-way large networks. The Cosmos Hub can share the Atom value with the verification set of any other Cosmos SDK project, and vice versa, it can be understood Assurance for the mutual security of sovereign networks. In the V3 version, Hub validators can have the right to stop validating which chain. Second, compared with the first version, the network security of the three versions will ultimately depend on the common security of the consumer chain and the supply chain.

For some participating nodes of the Cosmos Hub, if the only validating node on the consumption chain maliciously attacks, there will be a possibility of a witch attack. Projects that can currently be followed include Quicksilver and Neutron (P2P, a custom contract chain built by a large node). If you want to know more about cross-chain security, you can read the in-depth analysis of Cosmos’ pioneer – Osmosis. After IBC, see how ICS and ICA reconstruct the encryption industry and the rise of Cosmos Thessis-Osmosis application sovereign chain.


dYmension believes that its importance to rollups is similar to the importance of Cosmos to the entire blockchain industry. dYmension is a settlement layer and execution layer based on Cosmos, which provides Rollups with a flexible and optional chain-agnostic execution layer environment. The core product (Rollups Development Kit) RDK development kit, similar to the CosmosSDK module, is currently developing RDK in addition to dYmension, Celestia and Cosmos. This development kit provides developers with all the tools and infrastructure to easily build Rollups on Cosmos. dYmension targets enshriend rollups, not Discret Rollups. Enshrined rollups have more flexibility and choices, provide users with more flexibility, and ensure maximum security and stability, while Disrete Rollups represented by Arbitrum, Optimism, StarkNet, zkSync, Aztec etc. provide A good technical path and brand. Polynya believes that in the short and medium term, discret rollups will be accepted by most users, and in the long run, the two solutions may coexist.

At the same time, dyMension is also trying to solve the keeper’s dilemma, witch attack and other problems. The Keeper problem can be expressed as, in some cases, arbitrageurs will not liquidate for certain positions (such as the small position of $120 on MakerDAO) because of unprofitable or unclear incentives, which leads to Whales can disperse large positions into different positions, and pay a certain cost to ensure that the positions are not liquidated, which may affect the overall stability of the network. Of course, there is no way to confirm this threshold value due to different market conditions, time, etc. Although the MakerDAO Liquidation 2.0 upgrade promises to make the entire liquidation process simpler and more predictable. However, the actual situation is more complicated. In response to some black swan events, these liquidators usually prepare complex trading and hedging systems months in advance, which is unimaginable for retail investors.

At present, most of the clearing systems in the market are incentivized to the fastest liquidators, which exposes the network to a large amount of MEV risk, and makes a lot of profits go to the miners instead of the real liquidators. Therefore, for many professional market makers As far as traders are concerned, they did not participate in building the relevant systems and participated in the entire liquidation process. Dymension’s specific solution cannot be shared yet, but we have also seen many other competitors on this track, such as Kujira, after breaking away from the shackles of Terra ecology, in just over a month, completed The deployment of the application chain, and quickly ranked among the top ten positions of mapofzone. Kujiara’s approach to liquidation takes a different approach. The liquidation pool is directly invoked by contracts that hold positions that need to be liquidated. Ensuring that liquidable positions can be searched on-chain requires more work, but it means that all value capture is in the hands of pool participants.

For more complex positions, which users can easily index and search on-chain, Kujiara will provide the bot runner with a small “crank” fee to help actually perform the liquidation, but the funds will still come from the liquidation pool. So it’s still democratic and of sufficient scale to liquidate the largest loans. More information about the project will be shared with the community members later. dYmension is still very early, and we will continue to pay attention to its subsequent development. In essence, you can understand it as the execution layer and settlement layer design of Ethereum, but it inherits the essence of Cosmos design, such as the interoperability between Rollups (Thanks to the IBC and Cosmos native interoperability) and modular design (pluggable and easy deployment, etc. developer-friendly experience). Of course, there is also Saga, which can customize the execution environment. We will not elaborate here. The comparison of each solution can be seen in the figure below.



So far, we have sorted out most of the vertical scalability solutions of the Cosmos ecosystem on the market. Of course, our current status as Ethereum-rollups centric is still unshakable, so while we pay attention to Cosmos, we also need to pay close attention to the development of Ethereum and Solana’s efforts in the execution layer, innovation (not consensus layer) public chain. Fuel V1, the first ORUs launched on Ethereum, is currently the only Rollups designed for P2P payments with fraud proofs, immutable smart contracts and permissionless block production. Fuel V2 will be a modular execution layer, providing Ethereum-style smart contracts on UTXO, using Ethereum/Celestia for settlement, data availability and consensus, and cutting into multiple application scenarios.

We have seen many innovations in the consensus layer. Bitcoin, EVM, and Tendermint are all systems that establish the underlying consensus algorithm to protect the network from attacks. However, in real industrial applications, the demand for the execution layer may be greater, users need cheaper fuel costs, and the network needs higher throughput and performance. Solana, Aptos/Sui and other chains are also trying to solve the execution layer problem. We will discuss in a later article.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-07-24 10:08
Next 2022-07-24 10:09

Related articles