[PROPOSAL #49][ACCEPTED] Signaling Proposal - Deployment of Gravity Bridge on the Cosmos Hub

• Moderator edit to add link to on-chain proposal: Mintscan Read on GitHub Author: @jkilpatr | CTO and lead engineer at Althea Screenshot 2021-06-01 at 11.39.12 957×361 71.8 KB Summary This proposal is a Request For Comment to the ATOM community regarding the activation of the Gravity Bridge module onto the Cosmos Hub. By voting YES to this proposal, you will signal that you approve of having the Gravity Ethereum <> Cosmos bridge deployed onto the Cosmos Hub. Vision Gravity as an Ethereum-Cosmos bridge is designed for the Cosmos Hub, to pull as much value as possible into the orbits of Cosmos via a direct and decentralized bridge. Gravity will be able to bring ERC20 assets from Ethereum into Cosmos, as well as Cosmos assets to Ethereum ERC20 representations. ATOM, and any other asset in the Cosmos ecosystem, will be able to trade on Uniswap and other Ethereum AMMs, and interact with Ethereum DeFi like any ERC20 token. This will bring a tremendous amount of liquidity and utility to these assets. Cosmos, Ethereum, and Gravity Gravity is a secure and highly efficient bridge between EVM and Cosmos SDK-based blockchains. At a high level, Gravity enables token…

Excerpt (1199 of 13985 characters). Read the whole post on the forum ↗

catdotfish:

The Gravity bridge is designed with the assumption that the total amount of funds in Gravity.sol is less than the value of the validator set’s total staked tokens.

If this assumption does not hold true, it would be more profitable for validators to steal the funds in the bridge and simply lose their stake to slashing.

There is no automated enforcement of this assumption. It is up to the $ATOM holders to take action if the amount deposited in the bridge exceeds the total value of all stake on the hub.

So i guess that any counter proposal to put the bridge on a dedicated zone instead of the cosmos hub is quite bad on the security side because the new network would be way less secure.

If our intention is to bring a massive amount of value (in the billions) from the Ethereum chain, then it has to happen on the hub.

I support this proposal! Glad to see it’s going up. I think this will be a great addition to the cosmos ecosystem and help kickstart defi on cosmos.

I see this is only erc20s is there any plan to add support for nfts later or is that not possible due to the bridge design?

I will support this proposal,
The only thing that I concerned is security.

im in support of this proposal.

I’m generally in favor of this approach. 1 - I would like to better understand why the bridge should be deployed by hub validators. We started to discuss this during the Chainflow Althea/Gravity AMA yesterday, so I know @jkilpatr has done some deep thinking on this question. 2 - I don’t think it’s unreasonable to require validators to do more work to earn their Atoms as @zaki_iqlusion Tweeted. In this case that means running a Geth light node and the Gravity binary. From running on the current Althea/Gravity testnet, I would like to see - • The Gravity source code released, so it can be built from source. I don’t think this was available during the early testnet stages. • A reliable and accurate way to monitor individual Gravity binary functionality and performance. There’s not a good way to do that right now, as I understand it. This is critical to have before it can be implemented in a reliable way and to reduce slashing risk. 3 - I don’t know if I’d say running a Geth light node and Gravity binary are “easy” or “hard”. I’d frame it in terms of risk. Validators are being asked to go from running 1 process reliability to 3 processes. While I don’t feel this is…

Excerpt (1195 of 1341 characters). Read the whole post on the forum ↗

chris-chainflow: 1 - I would like to better understand why the bridge should be deployed by hub validators. We started to discuss this during the Chainflow Althea/Gravity AMA yesterday, so I know @jkilpatr has done some deep thinking on this question. The mandate of the Cosmos Hub is to be a hub for interchain communication. This means making and maintaining as many IBC connections as possible (which can have an non-trivial governance burden as IBC scales) and accepting as many bridges as is reasonable. It’s up to the Atom holders to decide if the burden of Gravity bridge is reasonable, but I think it’s hard to argue that a hub for cross chain bridges shouldn’t have a bridge to Ethereum as soon as possible. chris-chainflow: The Gravity source code released, so it can be built from source. I don’t think this was available during the early testnet stages. Up to date source code for the Gravity bridge can be found here. GitHub GitHub - althea-net/cosmos-gravity-bridge: A CosmosSDK application for moving... A CosmosSDK application for moving assets on and off of EVM based, POW chains - GitHub - althea-net/cosmos-gravity-bridge: A…

Excerpt (1194 of 2993 characters). Read the whole post on the forum ↗

Support for this being on the Cosmos Hub and thanks for clarifying @jkilpatr. Looking forward to using the bridge and get defi on cosmos going!

We will support this proposal and will follow with the execution and upgrade work. We believe this should be benefit to the Cosmos Hub!

Looking forward to it.

Thank you for the thoughtful responses. The only point holding Chainflow back from voting “Yes” is the pending availability of a reliable way to monitor bridge status.

While we’re relieved to hear that Geth downtime doesn’t cause the bridge to go down, which could lead to slashing, we believe it’s critical to have some way to reliably monitor the bridge itself, to minimize downtime, maximize availability and avoid slashing.

Thanks Chris,

The goal of this proposal is to get community approval for a bridge with these design properties and requirements. We’re hard at work testing and improving monitoring and other factors right now.

Just this weekend on our testnet Gorli had a very rare chain-reorg I’ll be working on monitoring for that case this week as it was difficult to determine what state the bridge was in. We’re doing our very best to test this software rigorously and build the monitoring and tooling in a way that’s driven by actual use and requirements.

Would be happy to schedule a meeting on what sort of monitoring architecture would fit the needs of validators best.