CHIPs signaling phase: Simplified Babylon x Cosmos Hub

Hub Proposals CHIPs
1

This is a significant revision of CHIPs signaling phase: Babylon x Cosmos Hub [Deprecated], which is intended to bring Bitcoin security to the Cosmos Hub with Babylon.

We’ve made a new thread since it is such a significant revision. Refer to the old thread to see prior discussion.

Both of these proposals follow this discussion phase post: Bringing Bitcoin security to the Cosmos Hub with Babylon.

After hearing concerns from the community about the complexity of the previous design and conferring with the Babylon team, we are significantly revising this proposal. The Babylon team has created a CosmWasm contract to enable Bitcoin security. This is installed on chains consuming Bitcoin security from Babylon.

This CosmWasm contract includes a WASM Bitcoin light client, meaning that it does not need an offchain oracle such as Slinky.

How it works

The new integration uses Babylon’s “finality provider” concept. This is a variation on the dual quorum shared security model. The finality providers are effectively a second validator set, whose power comes from staked Bitcoin. They sign off on each block which has been produced by a chain’s main validator set. They protect against forks by refusing to sign two separate blocks at the same height. If a finality provider signs two blocks at the same height, their Bitcoin delegators are slashed.

A client which chooses to take Bitcoin security into account will only accept finalized blocks if they bear the signatures of the finality provider set. Currently this is limited to full nodes, and full nodes can choose not to consider the finality provider signatures if they do not want to. In the future, the Babylon team will work on an IBC client which can incorporate this information.

Cosmos Hub

The Cosmos Hub (if approved by governance) will install the Babylon CosmWasm contract to prove out the integration. The Cosmos Hub is intended to be the second consumer of staked Bitcoin security, after BabylonChain itself. No inflation will be used to pay the Bitcoin delegators and finality providers until another proposal is passed to authorize this. This step is not strictly necessary to enable consumer chains to use Babylon’s Bitcoin staking but will bring attention from the Bitcoin community to the Cosmos Hub as the best place to launch Bitcoin L2s.

Consumer chains

ICS consumer chains who choose to use Babylon’s Bitcoin security will also install the CosmWasm contract. In this configuration, their primary validator set will still be secured by ATOM over ICS, and the finality provider set will exist to add an additional layer of security for clients which choose to use it.

In this scenario, staked ATOM from the Hub will protect the consumer chain against double signing, incorrect execution, and liveness issues. Meanwhile, staked Bitcoin will add an additional high level of security against double signing.

Users of a consumer chain’s full node can verify for themselves that no incorrect execution has taken place, and additionally be protected against double signing by security from both ATOM and BTC. This configuration will provide an very high level of security and may be favored by power users such as exchanges and RPC providers.

Implementation

We are currently working to connect the Cosmos Hub persistent testnet to Babylon’s Euphrates devnet.

Cosmos Hub

Once Gaia v18 with CosmWasm is released, and Babylon is live, we will introduce a governance proposal to upload the Babylon contract to the Cosmos Hub. Once this contract is activated, it will connect to Babylon, and finality providers will be able to begin signing blocks.

No full node or light client of the Hub will need to pay attention to the finality provider’s signatures unless they would like to benefit from the additional security.

ICS Consumer chains

Consumer chains which would like to benefit from Bitcoin security will install Babylon’s CosmWasm contract as well. We may also work to get this integrated into the Spawn tool for new consumer chains launching.

Once they are running the Babylon contract, their first quorum will still be secured by staked ATOM, and Hub validators will run their actual binaries. The Babylon finality provider set will provide an additional layer of security against double signing.

Pros and cons of the two proposed approaches

Old approach (power mixing)

Pros

  • Power mixing can smoothly integrate power from many sources (this is why Mesh Security was supposed to use a power mixing model).
  • Oracle design can work for any security provider, not just those whose light clients can be implemented in WASM.
  • Overall, the approach tended towards a “security aggregation” concept, where the Hub becomes a central security “clearinghouse”.

Cons

  • The power mixing module design was somewhat complex and would have been a lot of implementation work.
  • Oracle design is heavier to run. It would require each validator to run a client for each security source (such as a Bitcoin full node).

New approach (dual quorum)

Pros

  • The finality provider set is optional, and can be used only by clients who desire extra security
  • It is impossible for the finality provider set, or the Bitcoin stakers to halt the chain or to cause safety problems
  • The integration will primarily be developed and maintained by the Babylon team
  • Overall, the approach tends towards a “chain launchpad” concept, where Hub validators provide core security and chain operation services, while additional security from other ecosystems can be layered on top

Cons

  • Dual quorum is not as amenable to getting security from many different providers. It’s unclear if “triple quorum” or “quadruple quorum” would make much sense.
  • Currently, the extra security provided does not apply to IBC channels, until more work is done to make IBC clients verify finality provider signatures and check finality provider’s stakes on Bitcoin

FAQ

What is the benefit of this feature to the Cosmos Hub?

The primary benefit of this feature is to make the Cosmos Hub an appealing place to launch Bitcoin L2s using the Cosmos SDK, thereby bringing more activity to the platform.

Will this result in more work for validators?

No. The finality provider set is separate from the validator set, and Hub validators will not need to run any additional code.

Can Babylon, the finality providers, or the Bitcoin stakers attack the Hub?

No. The finality provider can only sign blocks that have already been produced by the main validator set, so cannot do anything malicious by themselves.

Can Babylon, the finality providers, or the Bitcoin stakers halt the Hub?

No. If the finality provider set refuses to sign blocks, it will only affect full nodes who have chosen to pay attention to them.

Will this cost the Hub anything?

While it may well be a good idea for the Hub to put inflation towards Bitcoin security at some point, the initial integration will not include this.

If consumer chains are supposed to install the Babylon contract themselves, what is the Hub for?

The finality provider set cannot produce blocks by themselves. A consumer chain’s ATOM staked Hub validator set plays the role of running the code, installing updates, performing computations, and serving the RPC endpoints. The finality providers simply provide a layer of additional security.

7 Likes
2

We would like to start by saying that we agree with most of the claims presented in this post. We also think the dual quorum model may be a good solution until we alleviate the inherent complexities of “power mixing.” From our perspective, the endgame is to achieve that mixing model as envisioned by the Mesh Security design, but in the meantime, we agree to opt for a step-by-step approach.

To provide comprehensive feedback on the proposed rework for the system design, we would like to highlight one particular problem. With this new design, we can hardly imagine that demand will be there to add Bitcoin security on top of ATOMs. This would cause the security budget to be diluted even further. While we conducted research regarding Partial Set Security (PSS) economics, we discovered that security revenues are mostly overestimated by most participants. This is a far more stretched market than people think. Therefore, the number one risk we foresee is that this dual model would likely add even more strain on an already tight balance of security costs for consumer candidates.

Our assumption is that this additional security may actually encounter very little demand, aside from highly specific cases where collateral security would need to be enormously high (maybe there are cases we don’t envision). This is why we suggest putting effort into researching potential synergies that could be brought by Bitcoin security as an addition to what ATOM can already offer via PSS. Specifically, the fact that Babylon should be able to do more than protect from double-signing.

In our global crypto landscape, we particularly like the ideas put forward by Babylon to protect from long-range attacks as this is a specialty in which Bitcoin is particularly effective. On the other hand, ATOM is perfectly suited to provide the instant finality that BTC can’t. There is a fundamental symbiosis here that we should take advantage of.

This is just wild brainstorming here, but what about creating a dual model in which ATOM brings the fast finality, and as BTC reaches its own, we would be able to shorten epoch times. This could reduce storage costs for operators not running full archive nodes, whilst still maintaining protection from long-range attacks beyond that epoch finalization. This was one of the main benefits proposed by the Babylon’s solution to reduce unbonding times in Cosmos chains whilst maintaining safe protection against long-range attacks.

This could be a great v2 update for this dual model system. It would play around security layering through time instead of just adding layers on top of each other with no specific added utility. This system would split the security budget between the different security providers, reducing their individual revenue, but it would also reduce their operating costs, which makes it efficient.

To summarize, we definitely support the addition of Babylon’s WASM into the Hub, as it is proposed to operate with no fee, at least not in the initial launch phase (we assume this will be the same for consumers willing to use the smart contract as well). To consider sharing revenues, we strongly suggest implementing a dual benefit system. We proposed a wild theory of our own and we hope the community will be able to sort out the best solution. We are confident that there are intrinsic synergies to be explored between Bitcoin’s and ATOM’s properties. We proposed a time-layered approach to be added to the dual-quorum model future updates, but we are eager to hear everyone else’s vision on this.

Thank you for reading,
Govmos
pro-delegators-sign

10 Likes
3

Super interesting. I like the incremental approach, and as a community leader of a chain considering ICS I can say this adds a nice extra layer of security and assurance that I think is compelling.

4 Likes
4

Firstly, thank you for all the research on security aggregation. Here, I will simply share my opinion. Personally, I believe that adding a security proposition and a slashable collateral is an interesting initiative that increases modularity and enhances security for certain specific actors, such as layer 2 solutions on Bitcoin, thus allowing the onboarding of chains like Lorenzo. However, I also think that the largest client in terms of layer 2 is Ethereum. The possibility of launching a layer 2 solution secured by ETH via the Cosmos Hub, thereby benefiting from direct interoperability with Cosmos, deserves to be explored. It is time to start studying the best way to integrate zk proofs secured by the hub to settle transactions on Ethereum. Maybe I’m wrong, but it’s probably the best way to connect to Ethereum.

6 Likes
5

We are 100% aligned with this:

This requires quite some engineering but no doubt someone will target that market-share. Ethereum has announced plans to get Single Slot Finality (SSF) but we won’t get that anytime soon. In the interim combining the instant finality of a Cosmos compatible EVM wrapper secured by the Hub’s ICS with ETH as a dual quorum security :exploding_head:… RIP Ethos which can only offer a Proof of Authority consensus.

6 Likes
6

Can anyone explain what the benefit of this is? Is it the market cap of the other protocols providing security against a 50% attack on Cosmos? I haven’t wrapped my head around the implications - and it doesn’t seem very obvious to me except for the piece that I questioned directly.

For example - I happen to like Proof of Authority consensus, although I know it’s not fully decentralized, but all the parameters for block propagation can be fine-tuned for maximum throughput.

1 Like
8

@jasonsprouse

In practical terms, there are people building systems that they would like to secure with staked Bitcoin (call them Bitcoin L2s, sidechains, whatever). This integration lets them use the Cosmos Hub to launch these chains more easily and securely. The benefit to the Hub will hopefully be to attract this type of project. Lorenzo protocol is one project that will launch a ICS consumer chain which would not do so if we didn’t have this integration.

1 Like
9

Projects that want to build a chain that is secured by stBTC or nBTC…I’m not familiar with the lorenzo project… I’ll have to check it out.

I get it. There are the Maxis’. Anyway that yield is made a token is usually locked for some bonding period. Logically I make comparisons to the value of a protocol that focuses on this kind of staking or a protocol like Kujira and all its features.

I also think about the RWPs I’m interested in and l wonder what kind of benefit staking nBTC or stBTC would have over issuing a token for those projects - other than just saying it’s Bitcoin.

For me it’s just understanding the practicality of it I guess, but I’m out by the lake waiting on the fish to school to get some tackle wet…so I’ll have to check out that Lorenzo protocol later.