Cosmos Hub Living Roadmap
The living roadmap showcases the ongoing work that Informal Systems is doing on the Cosmos Hub. This is an evolving roadmap that will be updated as we complete items, add new items and remove items that may no longer be necessary. This is intended to give a general overview of our ongoing work and priorities.
What’s included:
- Work that is in the deployment, implementation, or later design phases
- Work that is being done by the Cosmos Hub team at Informal
What’s not included:
- Work that has already been completed
- Ideas that are in the early design phase
- Work on the Cosmos Hub being done by teams outside of Informal
Table of Contents
Replicated Security improvements
Seamless consumer chain onboarding and offboarding
Cryptographic verification of equivocation evidence
Cryptographic verification of downtime
Epochs
Interchain security future
Opt-in security
Mesh security
Replicated Security improvements
There are a long list of improvements that we would like to make to Replicated Security. These range from fundamental changes to the protocol, to minor code cleanup tasks. These improvements will make Replicated Security safer, while also reducing the load on validators and governance. Ultimately, this will let more consumer chains be deployed more quickly and easily, increasing fees going to the Cosmos Hub.
Seamless consumer chain onboarding and offboarding
We want it to be possible for standalone chains to onboard smoothly as consumer chains without having to manually update their IBC connections to other chains. We also want it to be possible for consumer chains to offboard to other forms of security without having to manually update IBC connections. Offboarding is a little bit more complicated since we also have to answer the question of what the new validator set will be. Additionally, enabling offboarding to mesh security is a major strategic goal, and something that consumer chains are already expecting.
Cryptographic verification of equivocation evidence
As designed, ICS trusts consumer chains to honestly report equivocation by their validators by sending slash packets. This is OK in theory for Replicated Security if consumer chain code is well audited, but if there is an exploit in the code, it could slash validators unfairly. However this doesn’t work at all for opt-in security or mesh security because there is less oversight on what security is being used for. Because of the concerns about this we have several mitigations in place: a throttle that doesn’t let too many slash packets through at once, and we have gated this slashing behind a governance proposal, so that the proposal must pass after the slash packet is received.
These mitigations prevent any serious issues but it would be nice not to have to rely on them. In theory it is possible to cryptographically verify equivocation evidence on the provider chain. This is not trivial, but much of the work may already be done in IBC-Go and Hermes relayer.
Cryptographic verification of downtime
In Replicated Security, validators are jailed on the provider chain if they are down on any consumer chain. Currently, this is also done by trusting a jailing packet from the consumer chain, but this has the same potential for issues as trusting equivocation slashing packets. However, we have implemented a throttling mechanism which should stop a catastrophic attack.
It would be better to have some form of cryptographic verification of downtime on consumer chains so that no throttling is needed.
Epochs
Currently, Replicated Security requires a packet to be sent from the provider to the consumer and back for every block which contains a validator power change caused by a user delegating, undelegating, or redelegating. This is not a huge problem in normal operation, but can become an issue if there is a backlog of packets and can be expensive. It should be possible for the protocol to work with packets sent much less frequently, perhaps around once an hour or even once a day.
Interchain security future
We need to keep innovating to ensure that the Cosmos Hub is not only a pioneer of interchain security, but also remains a leader long term. While the ideas in this section are in a defined design stage, they are comparatively less well-defined than previous sections of this document.
Opt-in security
The validator opt-in subset problem is avoided if consumer chains are fraud-provable. With fraud proofs, we can be certain that if the validators validating a consumer chain have (for example) $10m staked on the provider, that chain cannot be attacked without that $10m being slashed. This is not the case without fraud proofs.
By making consumer chains fraud-provable, we can enable opt-in security. Opt-in security allows each validator to decide whether or not to validate a certain consumer chain.
What is the difference between opt-in security and a rollup settlement layer as envisioned by Celestia, Ethereum, and others? Both use fraud proofs. With rollups, a mandatory waiting period on cross-chain transactions from the rollup allows any fraud to be rolled back with a fraud proof before any assets are permanently stolen.
This waiting period is a huge complicating factor for any cross-chain application development on a rollup. Opt-in security removes this waiting period by slashing validators who commit fraud instead of making users wait for withdrawals.
Alternatives to fraud proofs
Fraud proofs are exciting, but are still an area of ongoing development. There are very few functioning implementations, and nothing that works with Cosmos-SDK yet, as far as we know.
But there are alternatives to a full and efficient fraud-proving Cosmos-SDK VM. For example, a governance proposal could be used to slash validators who attack a consumer chain. This needs careful consideration. This could allow the Cosmos Hub to ship this valuable technology more quickly, but some may be uncomfortable with such a governance proposal.
Mesh security
Mesh security is an elegant solution to enable what we refer to as Layered Security (ICS v3). Given that this has always been a long term goal for interchain security, mesh security should be a key focus for us. Also, mesh security will likely be a big presence in the interchain security space. The Cosmos Hub has the potential to be a leader in providing mesh security, and so we should make sure we are involved from day one to support the adoption of mesh security.
However: Like Opt-in Security, Mesh Security is not secure without fraud proofs or an alternative to fraud proofs.
Analysis and implementation of mesh security
Our team has already informed the creation of mesh security. We did the first and only analysis of how much economic security mesh security will actually provide in various scenarios. Given that the *only* thing that mesh security provides is economic security (versus the full-service validator set provided by Replicated Security and Opt-in Security), this analysis is foundational to the concept.
We will stay involved in the design and implementation of mesh security, both to ensure that it is secure enough to run on the Cosmos Hub, and so that we have in-house expertise allowing us to lead adoption.
Display cost to censor and cost to control on block explorers
Before we introduced the cost to censor/cost to control analysis of mesh security, nobody had any idea how much security it would even provide. Since the only thing that mesh security provides is economic security, this information is key. The Cosmos Hub also benefits from this key security information being displayed publicly because the Cosmos Hub has so much security to provide. Users having the ability to check the security of mesh secured chains will tend to lead chains to consume security from the Cosmos Hub because it will improve their cost to censor and cost to control by a lot.
To this end, we will maintain relationships with prominent block explorers, and provide them assistance and code to display the security of mesh secured chains prominently on their dashboards.
Mesh security chain launch platform
The Cosmos Hub could be a great platform for mesh-secured chains to launch on. It could leverage its large high stake and mature validator set to get consumer chains started off right. By submitting a governance proposal (or even a transaction) on the Cosmos Hub, a chain could provide a place for validators to sign up to join its validator set and for delegators to delegate to those validators. When the chain launched, it would have a validator set, as well as a large amount of security from all the assets staked on it from the Hub. It could then go out and get mesh security from other chains as well.
About the Author:
Jehan Tremback is the product owner for the Cosmos Hub at Informal Systems, where he works on exciting new features for the Hub.
