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.
Layer 2s are solutions that were created as an extension of Ethereum Mainnet for two main reasons:
- Ethereum is too expensive for retail use. → Transactions at scale are not feasible.
- 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:
- It allows to bring the main application and use cases such as: Decentralized exchanges, liquid staking and DeFi apps directly to the Hub.
- 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).
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.
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:
- Voting power on the EL is useless.
- 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.
- 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).
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).
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.
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:
- Independent App chains accrue barely any value to the ATOM token and are not obliged to.
- 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).
- 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.
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).
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?