Creating an Execution Layer for Cosmos Hub: Integrating Cosmwasm in a Secure Way

Conversation
1

Introduction

One of the biggest debates on the Cosmos Hub is whether to add Cosmwasm smart contract capabilities into Cosmos Hub. The main debate is whether to compromise security and neutrality of the Hub for the additional use cases and utility, with different proposals being rejected proving the point such as:

I do agree that Cosmwasm does add potential security risks or attack vectors that bad actors could take advantage of to halt or exploit the Hub that can lead to removal of the positioning of the Hub as a ICS Provider. I also heavily agree that the Hub is being left behind due to other appchains integrating Cosmwasm and the use case of the Hub is more ambiguous as time moves on, with a lot of discussions sparking that the Hub is no longer (or will no longer be) the center of the ecosystem.

This is why I decided to open a conversation and propose to create an Execution Layer (similar to an L2) for the Hub that brings in all the benefits and usecases of Cosmwasm to the Hub without compromising on its security or neutrality.

The Execution Layer

Layer 2s are solutions that were created as an extension of Ethereum Mainnet for two main reasons:

  1. Ethereum is too expensive for retail use. → Transactions at scale are not feasible.
  2. Ethereum is too congested for retail use. → Transactions are taking too much time to execute.

The good thing is that as of today, there is no need to provide a scaling solution for any appchain, especially the Cosmos Hub. It is cheap and is mostly scalable due to its architecture.

This does not mean that the Hub does not need to be extended. Layer 2s were created due to Ethereum being too “busy” for daily retail use, while the goal to extend the Hub is to create this demand that is lacking compared to EVM.

Extending an Execution Layer to the Hub allows to bring in this demand at scale without any compromise to the security and neutrality of the Hub. It allows the Hub to take back the center of the Hub in two major ways:

  1. It allows to bring the main application and use cases such as: Decentralized exchanges, liquid staking and DeFi apps directly to the Hub.
  2. It allows to connect the Hub seamlessly through IBC to other dApps and appchains in the ecosystem.

By extending the security and popularity of the Hub, the Execution Layer can become the preferred chain to deploy applications in rather than less secure or obscure app chains. The EL does not have governance (but defers to the Hub governance).

Architecture

The main goal of the EL (Execution Layer from now on) is to accrue even more value to ATOM. Therefor, the EL will not have a token of its own, but all fees are paid with the ATOM token that can easily bridged with IBC over to the EL (different ways for this to happen, to be discussed separately).

The EL would be an app chain also built with the Cosmos SDK but with heavily modified modules to operate as an extended layer to the Hub rather than an independent chain similar to other chains in Cosmos.

Similarly to Layer 2s on Ethereum, it would inherit the security of the Hub by cementing the state of the EL directly on the Hub (this can be done through a new module or through inscriptions that Asteroid Protocol created) and through ICS. Unlike Layer 2s, transactions would NOT be processed on an off-chain channel, but through another Cosmos-SDK chain that has a much lower time to finality (10 blocks in EL to 1 block in Hub for example).

Data from the EL can be verified and signed through ICS by validators from the Hub and then posted on the Hub for further verification and inspection by any party.

A module would allow for easy swap between IBC ATOM on the network and native ATOM on the EL by minting 1 native ATOM for each IBC ATOM and allowing an easy swap. The token can easily be bridged back to the Hub through swapping back to IBC ATOM and back to the Hub through an IBC transfer.

Validator Sets and Decentralization

Similarly to Layer 2s, validator sets in the EL need to be much smaller, since it does not need to be secure or decentralized (since it inherits it from the Hub), and the only use case is storing the data of the blockchain to post through a module directly to the Hub.

The main goal of these validators is to ensure uptime of the chain and distribution of the network on multiple nodes. The set of validators (10-20) will then earn part of the fees in ATOM from transactions occurring on the EL. The other (majority) portion of the fee is then distributed to post the data of the EL on the Hub (to extend its security). The validators, due to ICS, will need to be validators from the Cosmos Hub.

Possibly, nodes on the EL should not allow for staking of tokens but be rewarded equally for running a node to keep the EL alive. A sybil attack in that case is not possible (maybe I’m wrong here) since:

  1. Voting power on the EL is useless.
  2. ICS will allow to have certain trust with the set of validators on the EL due to having a proven track record validating the Hub.
  3. The set of validators is chosen in a predefined period to mitigate the risk of Sybil attacks and if a validator is jailed, there is a pre-vet and predefined list of validators from ICS that are allowed next to validate the chain.

There is different ways to choose the set of validators (through voting or most delegated validators).

Interchain Security

Using one of the best features of the Hub, ICS, there is no need for smart contracts to validate proofs of the transactions on the EL or any change to Hub source code. Using ICS, “bad actor” validators can have their ATOM slashed from the Cosmos Hub set (more on this here: ibc/spec/app/ics-028-cross-chain-validation/system_model_and_properties.md at main · cosmos/ibc · GitHub), and can ensure that the EL is secure to run and perform transactions.

After the data is validated on the EL, the data is batched and posted to the Hub (possibly through a Merkle Tree data structure) to ensure that there is a verified and secure as well as verification through ICS.

There might be a need to add a new ICS standard that allows proof verification and management of ATOM validators for the state of the EL through a certain algo (to be discussed separately).

Proof Verification

In case of any sybil attack or exploit on the EL that leads to breaking consensus, the Hub remains a source of truth by storing a certain proof of the data from the EL over on the Hub through a potential new module or ICS.

I believe this is the area that would need the most research in order to ensure a fair and secure EL that acts as an extension of the Hub that extends the scope of this conversation.

Blocks and transactions should not be finalized on the EL until a dispute period is completed on the Hub for dispute of such transactions by any of the ICS validator nodes.

Why Not an Independent AppChain?

This is probably a common question in the reader’s mind, but I believe there are multiple reasons that a separate EL is a good idea:

  1. Independent App chains accrue barely any value to the ATOM token and are not obliged to.
  2. Other app chains do not extend the functionality and use cases of the Hub and actually act as a competitor (even if they use ICS).
  3. Other app chains do not guarantee alignment with the Hub due to its own governance while the EL would defer governance over to the Hub. It does not have its own community pool as well to spend from.

Benefit for the Hub

The EL and its validators (through ICS) are a completely different entity from the Hub and therefore any exploit or halt to the EL will not lead to any exploit on the Hub. This allows to bring all the added value of Cosmwasm to the Hub without any compromise needed (except validators having to run multiple nodes for both the Hub and the EL but should be compensated enough to be worthwhile).

Moving Forward

It is important to note that the architecture is just a proof of concept and some of what is described above might be contradictory or false. Please treat the above as just an introduction to a conversation to potentially lead to a more in-depth research of the architecture and pros and cons of an Execution Layer for the Cosmos Hub, that leads to bringing useful applications over to the Hub.

What do you think of the Execution Layer? Is it a net benefit for the Hub or useless?

9 Likes
2

I like the phrasing. Execution Layer. Maybe this is a bit different than Neutron. How does Celestia fit in here? I have an idea of how I would like to see an execution layer architected with the cosmos-sdk and it would be different than Neutron. What kind of design requirements does your hypothetical execution layer have or what architecture are you proposing with this suggestion?

The governance model of chains (which I’ve been critical of for a while - a homogenous cryptographic oligarchy of sorts) and capital allocation of community pool resources could be revamped with something like World Coin authentication. 1 Person - 1 Vote or 1 Person + weighted votes on what ever specified parameters.

A well thought out EL would be an advantageous addition to the Cosmos Hub in my opinion.

1 Like
3

I believe that any independent chain will not align 100% with the Cosmos Hub since it has its own token and governance model, and even if in the short term they may align, they are very likely to diverge in the long term.

A Cosmos SDK chain rebuilt to remove governance, inflation, staking and basically defer all of this over to ATOM and the Hub. An easy IBC bridge to migrate between ATOM and ELATOM (just a naming) 1:1. Might need to refactor nodes to validate transactions and store the data and proof on the Hub and allow for any dispute for a certain period of time through certain IBC/ICS standards.

I believe this could lead to an architecture where app chains have 2 layers (governance and security → The Hub and execution → the EL) where the EL is faster layer where smart contracts can be executed where the GSL (Governance and Security Layer) is more robust and secure. This will allow more testing and features to be added to an EL without the fear of breaking consensus at any time and could actually bring much more innovation to the Cosmos.

1 Like
4

Two key design factors for my support would be - ephemeral and parallel processing. If the execution layer scales to ∞ transactions and processes those transactions in parallel I would think that would be an optimum design for a Cosmos Hub Execution layer.

The only protocol I know of that is working on something as such is filecoin with Interplantery Consensus. As of right now IPC uses CometBFT so this approach should be a relatively straight forward for an EL. -

EDIT - Also the Regulated Liability Network I mentioned in the previous post, which was about utilizing the sdk to create an ephemeral stack for a product like this described execution layer.

ConsensusLab is working on a fast consensus as a module for filecoin. I’m not sure if this will affect the utilization of CometBFT or if it enhances it. I suspect it’s an enhancement to filecoin’s consensus that take 900 epochs to finalize. CometBFT doesn’t have that finalization property so I’m not sure what benefit this module provides, but IPC is cited in the discusssion.

Screenshot 2024-02-06 082724
Screenshot 2024-02-06 0827242103×1179 152 KB

FIP0086: Fast Finality in Filecoin by jsoares ¡ Pull Request #896 ¡ filecoin-project/FIPs (github.com)

This fast finality module, in my mind, looks very similar to architecture I’ve seen with another project called Conflux.

I have reached out to filecoin on Slack to see if they were work working collaboratively with any of the Cosmos’s teams.

Screenshot 2024-02-06 083259
Screenshot 2024-02-06 0832592317×230 78 KB

3 Likes
5

Introduction:

First and foremost, we want to clarify that we don’t intend to represent the entire community but rather share our perspective on the matter. Correct us if we’re mistaken, but is this topic proposing the construction of a SDK Consumer chain for the Hub consisting of a Cosmwasm module and a custom-tailored Governance module that uses ATOMs as a voting token ?

Analysis:

Assuming the answer is yes, it becomes evident that this proposal poses direct competition to Neutron’s chain, which already holds a similar market share. The proposed changes include using ATOM or LS versions of ATOM as a gas token to compensate validators, essentially turning it into a utility token. This strategic move is intriguing as it aims to add more value to the asset and generate new types of demands within the existing supply. Still, it may pose a few underlying problems:

  • Shared Security Concerns: However, there’s a significant drawback to this approach. It contradicts a crucial aspect of ATOM today – the shared security aspect. Directly competing with an existing consumer chain, such as Neutron, poses serious threats. This concern extends beyond Neutron, as one could argue that the Hub might do the same with Stride or any other future ICS chain. The community should recall past discussions about the Hub potentially acquiring the entire STRD supply and integrating the founding team into the Hub’s core – discussions that, since then, have lacked conclusive outcomes.

  • Open-Source Dynamics: This dilemma underscores the open-source nature of our public blockchain infrastructure. In an open environment, anyone can replicate a good product. Govmos holds a particular interest in the Hub’s model as it appears distinct from major competitors striving to maximize value for their native token. The Hub, in contrast, has adopted an initial cooperative stance, advocating for the app-chain thesis to segregate different services into distinct sovereign chains. Entities then choose whether or not to partner with the Hub in exchange for its primary service: security.

Comparative Economic Models:

In comparison to other economic models, the Hub’s cooperative model is evident. It fosters an ecosystem where different services operate in separate sovereign chains, deciding independently to collaborate with the Hub for security. This vision is detailed in the Cosmos Ecosystem Report under the Network Architecture section found here: Cosmos Ecosystem : A permissionless B2B2C network. The report likens Cosmos to an ancient city, with ICSv1 as the core primitive securing public infrastructure while aligning governance with the Castle (the Hub). It introduces Mesh security as the second primitive, securing the city as a whole.

The proposed SDK Consumer chain, if implemented, could be seen as replacing core public services with their sovereignty under the direct governance of the Castle. This top-down approach seems reminiscent of efforts in other ecosystems and may not align with Cosmos’ ethos. There is a risk that the Hub might struggle to survive if it attempts to impose such verticals on the broader Cosmos city.

Conclusion:

In conclusion, we hope this comprehensive post was worth your time. Thank you for considering our perspective.
Govmos (the governance arm of the PRO Delegator’s validator)
pro-delegators-sign

3 Likes
6

Not a tailored governance model but no gov model at all as all governance is deferred to the main Hub in that instance, since the EL is only an extension of it.

At the end of the day, I believe it will be a competition to other app chains in the ecosystem since the Hub will have its own smart contract layer. But both can coexist at the end of the day since the Hub is a provider of security for Neutron and that won’t change the fact.

I agree that currently the Hub has taken a different stance in its neutrality and the security provider for the Cosmos, but the Execution Layer came from a potential risk that in the future that assumption may not be true anymore as another chain may surpass it as the main provider.

Again, heavily agree with what was said above and the goal of the execution layer was to create a separate layer to experiment contracts on the Hub without directly influencing the main vision defined above.

Finally one last point is that due to consumer chains such as Neutron etc… having their own governance model, it is not certain that there will be long term alignment between the Hub and consumer chains (unless I am wrong here) while an execution layer, having only the ATOM token and no governance basically guarantees it.

3 Likes
7

Agreed, as an extension, and without posing any security risk to the Hub, scaling can be infinite on that end with the main goal of providing proof of the transactions to the Hub.

8

it seems pretty good idea, the principal counter argument was the security of the hub … if this does not involve in it, it is a big Yes for me. Consumer chain can leave ICS in the futur, what is the alternativ in the case of neutron leave ? dont know

9

This is one question, and the other question is if ATOM is able to sustain the main provider of security for the ecosystem? If the price keeps on dipping, stakers and validators may move on to more lucrative chains over time.

10

atom must not be just the security provider of cosmos … atom has to be more. PSS, megablock, AAT, POL on the way

2 Likes
11

Thank you for addressing the mains pinpoints of our post one by one. There’s still one critical factor that we think could be elucidated further for anyone reading us.

1. Being “Unforkable”

Ultimately, this concept ties back to the “forkable theory,” rooted in the notion that any open-source blockchain can be replicated instantly—either as an identical version or an improved separate version. The sustained value of an open-source project over time hinges on its ability to be “unforkable.” In other words, while anyone could duplicate the software, achieving meaningful competition would remain incredibly challenging.

2. Symbiosis

Each replicated security consumer chain plays a vital role in the global AEZ (liquid staking and EL for now). In exchange for a share of their revenue, the Hub provides them with its entire professional validator set and its community of users, all while allowing consumers to retain complete sovereignty. Thanks to Informal’s efforts, we will even offer atomic composability between replicated security partners in the not-so-distant future. If Neutron were to ever leave ICS, it could be promptly replaced by a duplicate chain like the EL proposed in this conversation. This symbiotic relationship is mutually beneficial, far surpassing the potential gains of attempting solo ventures.

3. Cooperation

Wouldn’t the Hub benefit more by having its own EL? This would mean retaining 100% of the EL revenue instead of a share from Neutron. However, introducing direct competition to an existing consumer chain could prove extremely detrimental. It would convey the message to other consumer chains that they, too, could be at risk. Such a move not only jeopardizes the Hub’s neutral credibility but also undermines its very essence as an “unforkable” top security provider. Recognizing this is crucial to understanding the symbiotic and cooperative nature that the hub proposes.

4. Maintaining Balance

While this may be speculative, we could invite Neutron’s @Spaydh to share his opinion directly and explain why Neutron has chosen replicated security. From our perspective (acknowledging the potential for error), any consumer chain in replicated security appears to be a long-term strategy. It represents a bilateral agreement aimed at maintaining a symbiotic balance between the hub’s sustainability and its “unforkable” advantage, alongside sovereign and highly composable revenue-generating consumer chains. It seems that each party attempting to eliminate the other would end up less efficient at both aspects compared to accepting reliance on the other, even without direct control.

pro-delegators-sign

5 Likes
12

Thank you for the elaborate response, just wanted to clarify a few ideas about my main point.

I completely agree here. The main point of EL was not to be a replacement or competition to any consumer chain out there, and it does not mean that if the Hub does actually have an EL that it should not provide security to other consumer chains such as Neutron.

I think my thoughts move more along the line of: Since consumer chains will offer X% of their transaction fees + possibly an inital allocation to the Hub validators and community pool, making it a viable idea for the Hub to be the security provider, wouldn’t it make sense for the Hub to have as well a EL where it retains 100% of their transaction fees and guarantees alignment + participation in IBC relaying in the future between dApps?

Also I have some theoretical questions that would be interesting to see your (and community’s) answer on:

  1. On the long run, is it possible for another chain such as Celestia to become a better or more viable security provider than the Hub? If No, why?

  2. Is it possible that when IBC technology advances even more and chains + liquidity becomes more interconnected, will the Hub be left out of the equation due to having no Cosmwasm on the Hub?

  3. Would consumer chains similar to Neutron in the future accept to become a consumer chain from a provider such as Celestia for example?

  4. If consumer chains will feel threatened if the Hub has an EL, and the EL is for the benefit of the Hub, does that mean that the consumer chain is 100% aligned with the Hub interests?

Again, final disclaimer, I am definitely not against any consumer chain or wanting to build competition against them or even bad mouthing them in any way as I love for example what Neutron are doing. This is just a theoretical discussion on the possibility of Cosmos Hub becoming a smart contract enabled chain in a way that does not hurt neutrality or security of the Hub, and allow it to participate in my view of an IBC connected decentralized application ecosystem

3 Likes
13

Thanks for clarifying some potential ambiguity. There are definitely ways in which this proposition could come to life without direct competition to Neutron. This would potentially include governance specific smart contracts as well as the covenants and other types of Hub PoL treasuries which also require wasm capabilities. This could be deployed as a permissioned smart contract environment only targeting governance approved use-cases limited to the Hub’s core mandate. Therefore this would cause no overlap with the existing wasm consumer chain which offers permissionless deployment.

In this case, your discussion falls into the realm of the propositions made by Binary builders with their Atom Alignment Treasury’s design (AATs). More context on the matter on this specific paragraph: Discussion: AEZ Growth & the ATOM Alignment Treasury

TL;DR, they proposed eerily similar implementation options as the one stated in this post. Either to run smart contract via Neutron, or consider adding permissioned wasm under the Hub umbrella. Running this module as a separate chain would maintain Gaia’s minimalist approach and therefore we would agree to include this in the list of options.

Separately to answer your questions one-by-one:

  1. The possibilities to see other shared security hubs emerge are arguably narrow for two reasons. First, the hub offers much more history, therefore decentralization of the token supply as well as a more robust liquidity, less volatility, increased depth of market, etc… Secondly, the ATOM token is the only one that is specifically providing security and nothing else, where TIA and others are all having additional utility to their tokens by nature. People often think of Hubs in terms of the highest Marketcap or IBC connections but that’s really a flawed and oversimplified model.

  2. This second interconnection outcome is practically guaranteed as this is the core cosmos vision. In this world we talk about Mesh security, in which ATOM is expected to be a prominent actor, mainly due to the same reasons as stated in point 1. This is simply a more granular approach that would reduce the required alignment with the hub an be more of a financial risk management based on a rehypothecation fabric.

  3. This is a possibility, in this scenario Neutron has to become “unforkable” as well by offering unique primitives and network effects that no other copy can replicate (think about atomic composability with the whole AEZ for example).

  4. In our previous post we clearly explained why consumer chains don’t have to be 100% aligned with the hub, they actually maintain a certain degree of freedom with their own independent and sovereign token. Full Set security does require symbiotic relations but not a full alignment per say. This requires cooperation and mutual benefit as previously stated whilst keeping two separate identities.

I hope this answers your questions, otherwise feel free to ask for more details. Nevertheless we are happy to have thoughtful conversation with you here in a very polite and positive manner. This was an absolute pleasure to speak with you.

4 Likes
14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.