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

catdotfish · June 1, 2021, 9:42am

Moderator edit to add link to on-chain proposal: Mintscan - Chain explorer by COSMOSTATION

Read on GitHub
Author: @jkilpatr | CTO and lead engineer at Althea

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 transfers from Ethereum to the Cosmos Hub and back again, by locking up tokens on the Ethereum side and minting equivalent tokens on the Cosmos side.

Gravity is completely non-custodial. Control of the bridge mirrors the active validator set on the Cosmos SDK-based chain, and validator stake on Cosmos can be slashed for misbehavior involving the Gravity bridge.

The Gravity Ethereum contract is highly optimized, utilizing batches to dramatically reduce the cost of Cosmos → Ethereum transfers. Sending funds from Cosmos back to Ethereum can be up to 50% less costly than a normal ERC20 send.

How do validators support the Gravity Bridge?

Cosmos Hub validators will run three key software components of the Gravity bridge:

The Gravity bridge module, integrated into gaiad (the main Cosmos binary)
The Gravity bridge Orchestrator
A Geth light client or any Ethereum full node implementing the JSON-rpc standard

Cosmos to Ethereum:

To send transactions from Cosmos to Ethereum, the Gravity Bridge module first packages the transaction data, and makes it available on an endpoint. The Orchestrator then signs this data with the validator’s Ethereum key, and submits it as a message. These signatures will then be assembled and submitted to the Ethereum chain by relayers.

Validators may be slashed if they fail to submit Ethereum signatures within 6000 blocks (about eight hours) of their creation.

Validators may also be slashed if they sign a message with their Ethereum key that was not created by the Gravity bridge module.

Gravity bridge has no other slashing conditions.

Ethereum to Cosmos:

The Orchestrator also monitors the Ethereum chain, submitting events that occur on Ethereum to Cosmos as messages. When more than 66% of the active voting power has sent a message observing the same Ethereum event, the Gravity module will take action.

This oracle action will not be incentivized, nor will it be enforced with slashing. If validators making up more than 33% of the staked tokens do not participate in the oracle, new deposits and withdrawals will not be processed until those validators resume their oracle obligations.

The oracle was designed without slashing conditions to ensure that a consensus failure on Ethereum does not affect operation of the Cosmos chain.

Slashing Conditions Spec

github.com

cosmos/gravity-bridge/blob/main/spec/slashing-spec.md

This file names and documents the various slashing conditions we use in Gravity.

## GRAVSLASH-01: Signing fake validator set or tx batch evidence

This slashing condition is intended to stop validators from signing over a validator set and nonce that has never existed on Cosmos. It works via an evidence mechanism, where anyone can submit a message containing the signature of a validator over a fake validator set. This is intended to produce the effect that if a cartel of validators is formed with the intention of submitting a fake validator set, one defector can cause them all to be slashed.

**Implementation considerations:**

The trickiest part of this slashing condition is determining that a validator set has never existed on Cosmos. To save space, we will need to clean up old validator sets. We could keep a mapping of validator set hash to true in the KV store, and use that to check if a validator set has ever existed. This is more efficient than storing the whole validator set, but its growth is still unbounded. It might be possible to use other cryptographic methods to cut down on the size of this mapping. It might be OK to prune very old entries from this mapping, but any pruning reduces the deterrence of this slashing condition.

## GRAVSLASH-02: Failure to sign validator set update or tx batch

This slashing condition is triggered when a validator does not sign a validator set update or transaction batch which is produced by the Gravity Cosmos module. This prevents two bad scenarios- 

1. A validator simply does not bother to keep the correct binaries running on their system,
2. A cartel of >1/3 validators unbond and then refuse to sign updates, preventing any validator set updates from getting enough signatures to be submitted to the Gravity Ethereum contract. If they prevent validator set updates for longer than the Cosmos unbonding period, they can no longer be punished for submitting fake validator set updates and tx batches (GRAVSLASH-01 and GRAVSLASH-02). 

To deal with scenario 2, GRAVSLASH-02 will also need to slash validators who are no longer validating, but are still in the unbonding period. This means that when a validator leaves the validator set, they will need to keep running their equipment for 2 weeks. This is unusual for a Cosmos chain, and may not be accepted by the validators. Research is ongoing for ways to allow validators to stop signing before the unbonding period is fully over.

## GRAVSLASH-03: Submitting incorrect Eth oracle claim - INTENTIONALLY NOT IMPLEMENTED

This file has been truncated. show original

How does it work?

Gravity consists of 4 parts:

An Ethereum contract called Gravity.sol
The Gravity Cosmos module
The orchestrator program which is run by Cosmos validators alongside the Gravity module
A market of relayers, who compete to submit transactions to Ethereum

Gravity.sol

The Gravity Ethereum contract is a highly compact and efficient representation of weighted powers voting on Ethereum. It contains an Etheruem key from each Cosmos validator, as well as their voting power. This signer set is continuously updated as validation power changes on Cosmos, ensuring that it matches the current Cosmos validator set.

Sending tokens, or updating the validator set, contained in Gravity.sol requires more than 66% of the total voting power to approve the action. In this way Gravity.sol mirrors Tendermint consensus on the Cosmos chain as closely as possible on Ethereum.

Gravity Cosmos Module

The Gravity module governs and coordinates the bridge. Generating messages for the validators to sign with their Ethereum keys and providing these signatures to relayers who assemble and submit them to the Ethereum chain.

Orchestrator

The Gravity bridge orchestrator performs all the external tasks the Gravity bridge requires for validators. The submission of signatures and the submission of Ethereum events.

While the Gravity module concerns itself with the correctness and consensus state of the bridge the Orchestrator locates or creates the correct inputs.

Market of Relayers

Relayers are an unpermissioned role that observes the Cosmos chain for messages ready to be submitted to Ethereum.

The relayer then packages the validators signatures into an Ethereum transaction and submits that transaction to the Ethereum blockchain. All rewards in the Gravity bridge design are paid to msg.sender on Ethereum. This means that relayers do not require any balance on the Cosmos side and can immediately liquidate their earnings into ETH to relay future messages.

Security assumptions

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.

It should be noted that this condition is not unique to the Gravity bridge. The same dynamic exists for any IBC connection, and even exists in scenarios other than cross-chain communication. For example, in a hypothetical blockchain keeping domain name records, this same vulnerability would exist if the potential profit from exploiting the domain name system was greater than the value of the validator set’s total staked tokens.

Ongoing work

The Gravity Bridge has been continuously tested throughout Q1/Q2 2021 by multiple ongoing test nets with a diverse group of validators.

Testing

The Althea team is committed to playing a long-term role in upgrading, documenting, and supporting Gravity over the coming years. The Gravity bridge is currently live and running in a testnet, which validators can join by following the instructions here

Audit:

The Gravity bridge module is currently undergoing an audit with Informal Systems estimated to be completed by the end of July, 2021.

Phase one of the audit has been completed, which resulted in the addition of evidence based slashing and several other minor design fixes.

The phase two design audit will be completed by the end of June. To be followed by phrase three, an implementation audit to be completed by the end of July.

Conclusion:

With this proposal, the Althea team, together with Cosmos ecosystem partners, will expedite the development of the Gravity Bridge with an incentivized testnet and launch in Q3 2021. Althea will be closely shepherding the Gravity Bridge throughout all phases related to the testing, audit, and implementation process on the Cosmos Hub.

Proposers

The Althea Gravity bridge team.

Deborah Simpiler, Justin Kilpatrick and, Jehan Tremback

We’d like to share praise and thank you for contributions from the following teams!

Interchain Foundation

All in Bits/Tendermint

Sommelier, Informal, Injective, Confio

Gravity Readiness Committee:

Justin Kilpatrick and Jehan Tremback, Althea

Zarko Milosevic, Informal Systems

Zaki Manian, Sommelier/Iqlusion

Governance Votes

The following items summarize the voting options and what it means for this proposal.

YES : You agree that Gravity Bridge should be deployed to the Cosmos Hub.
NO : You disapprove of deploying Gravity bridge on the Cosmos Hub in its current form (please indicate in the Cosmos Forum why this is the case).
NO WITH VETO : You are strongly opposed to the deployment of Gravity bridge on the Cosmos Hub and will exit the network if this occurred.
ABSTAIN : You are impartial to the outcome of the proposal.

Appendix

FAQ

Is running the Gravity Module difficult for Cosmos Validators?

Soliciting feedback from dozens of Cosmos hub validators and over 100 test net participants, we found that running the Gravity module is not a difficult task or undue burden on Cosmos validators.

Is the Gravity bridge secure?

The Gravity bridge is undergoing an audit by Informal Systems. It will then be up to ATOM holders to interpret the results of the code audit and weigh implementation risks in another governance proposal before deployment. Fundamentally, the design of the Gravity Bridge means that its security is directly represented by the security of the validator set on Cosmos Hub.

Are slashing conditions a problem for validators?

Gravity Bridge slashing conditions closely mirror the slashing conditions which validators are already subject to.

Uptime: Validators on Cosmos currently must keep their validator software running at all times, or risk slashing. Gravity adds an additional binary which must be run, which is low in difficulty.
Equivocation: Validators on Cosmos are subject to slashing if they sign two blocks at the same height. It is possible for this to happen through accidental misconfiguration. Gravity adds an additional item which must not be signed, which are the fraudulent bridge transactions that never existed on Cosmos. It is not possible for this to happen by accident, so this slashing condition is much less of a risk than the Hub’s existing slashing conditions.

How is Gravity Bridge different from Peggy?

The original vision for Peggy outlined in the Cosmos whitepaper is a ‘peg-zone’, meaning a Cosmos blockchain that exists for the sole purpose of running the bridge to Ethereum. All tokens would then be moved to other more general purpose Cosmos chains via IBC.

This design is heavily reliant on IBC, not only for moving Ethereum tokens to where they will be used, but also to handle the stake for bridge operations. The validator set operating the bridge must have at least as much at stake as the value in the bridge. In the Peggy concept this would require some shared security system built on top of IBC.

Gravity is a simplified design for a bridge that relies directly on the stake of the Cosmos chain running the bridge. Bridges like IBC and Gravity are complex on their own, so by taking this strategy IBC and Gravity remain as distinct bridges operating on the same chain, rather than being tightly connected systems.

This is easier to both design and debug, and is ideal for high-value chains like the Hub.

WillB · June 1, 2021, 2:53pm

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.

DarkGhost7 · June 2, 2021, 3:20am

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?

ping · June 2, 2021, 3:46am

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

inonit · June 3, 2021, 5:00am

im in support of this proposal.

chris-chainflow · June 3, 2021, 3:52pm

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 unreasonable, I wouldn’t say it’s trivial, either. For example, Geth has come a long way over the years, yet can still be a bit finicky at times.

jkilpatr · June 3, 2021, 6:12pm

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.

Up to date source code for the Gravity bridge can be found here.

The current testnet is integrated into the Althea chain

During early testnets changes where being made so quickly it was hard to tell what version was ‘current’ in any real sense. With Gravity testnet2 I scheduled a chain upgrade before going public with the expectation that more fixes would have to be integrated.

Turns out that wasn’t the case. This is the git commit we’ve been using for testnet2 without issues

cosmos-gravity-bridge/commit/bca90b08f42fb2826d25569364cb8f07c7ed1719

As discussed in the proposal there are no slashing conditions for Ethereum oracle message submission. Meaning if a Geth client fails the validator faces no consequences. This does risk the bridge halting (new deposits and withdraws not processing) if validators don’t maintain their Eth nodes, but it means that the uptime of the chain or a validator is never related to the reliability of a Geth or Ethereum node. Which is essential for maintaining sovereignty.

Once the validators fix their Ethereum nodes the bridge would catch up and process all the waiting deposits and withdraws.

NjB · June 4, 2021, 2:57pm

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!

decentralizehk · June 7, 2021, 11:16am

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.

chris-chainflow · June 21, 2021, 1:53pm

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.

jkilpatr · June 21, 2021, 3:23pm

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.

Topic		Replies	Views
[PROPOSAL #51][ACCEPTED] Adopt the Gravity Dex on to the Cosmos Hub Software Upgrade	18	3538	July 12, 2021
[PROPOSAL #62][ACCEPTED] Signal Proposal: Migration of Gravity DEX to a Separate Cosmos Chain Signaling/Text	21	4636	April 14, 2022
[PROPOSAL #38][ACCEPTED] Proposal to Adopt the Liquidity Module onto the Cosmos Hub Signaling/Text	24	7287	February 27, 2021
[Signaling Proposal][Draft]Add Liquid Staking Module to the Cosmos Hub Hub Proposals draft	67	13680	April 26, 2023
[PROPOSAL #45][ACCEPTED] Community Fund Proposal for Gravity DeX Prize Budget Community Spend	11	4657	April 6, 2021