The official repository of the Gravity Bridge Blockchain

Overview

Gravity Bridge

Gravity bridge is Cosmos <-> Ethereum bridge designed to run on the Cosmos SDK blockchains like the Cosmos Hub focused on maximum design simplicity and efficiency.

Gravity is currently can transfer ERC20 assets originating on Cosmos or Ethereum to and from Ethereum, as well as move Cosmos assets to Ethereum as ERC20 representations.

Documentation

High level documentation

To understand Gravity at a high level, read this blog post. It is accessible and more concise than the rest of these docs, but does not cover every detail.

Code documentation

This documentation lives with the code it references and helps to understand the functions and data structures involved. This is useful if you are reviewing or working on the code.

Solidity Ethereum contract documentation

Go Cosmos module documentation

Specs

These specs cover specific areas of the bridge that a lot of thought went into. They explore the tradeoffs involved and decisions made.

slashing-spec

batch-creation-spec

valset-creation-spec

Design docs

These are mid-level docs which go into the most detail on various topics relating to the bridge.

design overview

Bootstrapping the bridge

Minting and locking tokens in Gravity

Oracle design

Ethereum signing

Messages

Parameters

Incentives

arbitrary logic

relaying semantics

Developer Guide

To contribute to Gravity, refer to these guides.

Development environment setup

Code structure

Adding integration tests

Security hotspots

Status

Gravity bridge is under development and will be undergoing audits soon. Instructions for deployment and use are provided in the hope that they will be useful.

It is your responsibility to understand the financial, legal, and other risks of using this software. There is no guarantee of functionality or safety. You use Gravity bridge entirely at your own risk.

You can keep up with the latest development by watching our public standups feel free to join yourself and ask questions.

  • Solidity Contract
    • Multiple ERC20 support
    • Tested with 100+ validators
    • Unit tests for every throw condition
    • Audit for assets originating on Ethereum
    • Support for issuing Cosmos assets on Ethereum
  • Cosmos Module
    • Basic validator set syncing
    • Basic transaction batch generation
    • Ethereum -> Cosmos Token issuing
    • Cosmos -> Ethereum Token issuing
    • Bootstrapping
    • Genesis file save/load
    • Validator set syncing edge cases
    • Slashing
    • Relaying edge cases
    • Transaction batch edge cases
    • Support for issuing Cosmos assets on Ethereum
    • Audit
  • Orchestrator / Relayer
    • Validator set update relaying
    • Ethereum -> Cosmos Oracle
    • Transaction batch relaying
    • Tendermint KMS support
    • Audit

The design of Gravity Bridge

  • Trust in the integrity of the Gravity bridge is anchored on the Cosmos side. The signing of fraudulent validator set updates and transaction batches meant for the Ethereum contract is punished by slashing on the Cosmos chain. If you trust the Cosmos chain, you can trust the Gravity bridge operated by it, as long as it is operated within certain parameters.
  • It is mandatory for peg zone validators to maintain a trusted Ethereum node. This removes all trust and game theory implications that usually arise from independent relayers, once again dramatically simplifying the design.

Key design Components

  • A highly efficient way of mirroring Cosmos validator voting onto Ethereum. The Gravity solidity contract has validator set updates costing ~500,000 gas ($2 @ 20gwei), tested on a snapshot of the Cosmos Hub validator set with 125 validators. Verifying the votes of the validator set is the most expensive on chain operation Gravity has to perform. Our highly optimized Solidity code provides enormous cost savings. Existing bridges incur more than double the gas costs for signature sets as small as 8 signers.
  • Transactions from Cosmos to ethereum are batched, batches have a base cost of ~500,000 gas ($2 @ 20gwei). Batches may contain arbitrary numbers of transactions within the limits of ERC20 sends per block, allowing for costs to be heavily amortized on high volume bridges.

Operational parameters ensuring security

  • There must be a validator set update made on the Ethereum contract by calling the updateValset method at least once every Cosmos unbonding period (usually 2 weeks). This is because if there has not been an update for longer than the unbonding period, the validator set stored by the Ethereum contract could contain validators who cannot be slashed for misbehavior.
  • Cosmos full nodes do not verify events coming from Ethereum. These events are accepted into the Cosmos state based purely on the signatures of the current validator set. It is possible for the validators with >2/3 of the stake to put events into the Cosmos state which never happened on Ethereum. In this case observers of both chains will need to "raise the alarm". We have built this functionality into the relayer.
Issues
  • panic when withdrawing rewards or commission from validator

    panic when withdrawing rewards or commission from validator

    On the current testnet (gravity-bridge-test{1..4}), my validator is not able to withdraw rewards or commission, but is able to successfully send other transactions like transferring tokens.

    withdrawing:

    ./gravity tx distribution withdraw-rewards gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9 --commission --from validator --keyring-backend pass
    {"body":{"messages":[{"@type":"/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward","delegator_address":"gravity156n6x0hvfd2zxq5vhehp2e20mz6tdskhxtlf33","validator_address":"gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9"},{"@type":"/cosmos.distribution.v1beta1.MsgWithdrawValidatorCommission","validator_address":"gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9"}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}
    
    confirm transaction before signing and broadcasting [y/N]: y
    {"height":"29485","txhash":"A612BAF0FB4B6A46D4DF51ADE93C746BF35366408A75A5CA2E0AEB2653F75180","codespace":"undefined","code":111222,"data":"","raw_log":"panic message redacted to hide potentially sensitive system info: panic","logs":[],"info":"","gas_wanted":"200000","gas_used":"97657","tx":null,"timestamp":""}
    

    transferring:

    ./gravity tx bank send validator gravity15lpnf70ycjxyhhjysmlkm6k4uf0sm220ftqy79  1000000ugraviton --keyring-backend pass
    {"body":{"messages":[{"@type":"/cosmos.bank.v1beta1.MsgSend","from_address":"gravity156n6x0hvfd2zxq5vhehp2e20mz6tdskhxtlf33","to_address":"gravity15lpnf70ycjxyhhjysmlkm6k4uf0sm220ftqy79","amount":[{"denom":"ugraviton","amount":"1000000"}]}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}
    
    confirm transaction before signing and broadcasting [y/N]: y
    {"height":"14131","txhash":"64FD8BDD953639CA0CB15CFBCF6A61B3028279F4A552ABBC075221F0E0D68563","codespace":"","code":0,"data":"0A1E0A1C2F636F736D6F732E62616E6B2E763162657461312E4D736753656E64"...
    

    I was able to change my commission and withdraw once (maybe during gravity-bridge-test1 or gravity-bridge-test2), but something happened and I'm not able to anymore.

    I am able to withdraw as a different delegator to my validator:

    ./gravity tx distribution withdraw-rewards gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9 --from mine --keyring-backend pass
    Default sign-mode 'direct' not supported by Ledger, using sign-mode 'amino-json'.
    {"body":{"messages":[{"@type":"/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward","delegator_address":"gravity1pqk05hdkyhlvj07tept96cwa3fj7axasq8cg0h","validator_address":"gravityvaloper156n6x0hvfd2zxq5vhehp2e20mz6tdskhhqxhm9"}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}
    
    confirm transaction before signing and broadcasting [y/N]: y
    {"height":"35806","txhash":"65A5654C7D0F79AE6FB67DBE4D8F0B5226E71A81BFBB3C7A972AA50EE65E6381","codespace":"","code":0,"data":"0A390A372F636F736D6F732E646973747269627574696F6E2E763162657461312E4D7367576974686472617744656C656761746F72526577617264",
    
    opened by boz 19
  • feat: Use geth address instead of string

    feat: Use geth address instead of string

    This PR changes the underlying object for EthAddress from string to geth's Address. It also contains the necessary migrations to use the address' bytes instead of the hex representation in keys.

    Closes #85

    opened by facundomedica 15
  • fix: accept confirms only from bonded or unbonding validators

    fix: accept confirms only from bonded or unbonding validators

    This PR addresses 2 issues:

    ~- ETH addresses are now required to be checksummed (these means all ETH addresses). This might be an issue for already running chains if relayers don't send all of the addresses in the compliant format.~

    [email protected] this might be a change too drastic if there are any eth addresses in the store that aren't well-formatted, I think we are good on Umee's side because we use geth's common package for addresses. This might also break some of your shell tests~

    • Accept confirms only from bonded or unbonding validators

    • Don't panic when prepping the confirms for slashing if it can't find a validator

    These last 2 are in the first 2 commits if you want to check them with less background noise.

    EDIT: Removed Eth address related changes to make a better fix in a separate PR

    opened by facundomedica 13
  • Attestation order

    Attestation order

    The change in this PR solves the problem of submitting claims with unordered event nonce. This can happen if the last_checked_event on the orchestrator side is set to 'n' and in the next iteration when check_for_events is called, there is event with the nonce 'n+1' that should be submitted but in the meantime the governance vote reset the last event nonce by the validator to 'n-1' on the chain side. check_for_events will try to submit event with nonce 'n+1' to the chain where last submitted nonce is set to 'n-1' and that will fail. Before this fix there was no recovery from this scenario because the last_checked_block was reset only if check_for_events returns successful result and the last event nonce on orchestrator was greater than the last event nonce on the chain side. This check if last_checked_block should be adapted in order to replay old events is now moved before check_for_events.

    opened by stana-ethernal 7
  • WIP: Design PR for ECR721 Transfer

    WIP: Design PR for ECR721 Transfer

    I started working on the ERC 721 transfer PR here, at this stage I just set up a skeleton structure that I will override when I know more clearly what to update.

    As far as I understand right now, we essentially just need to take the send_to_cosmos and change it from this:

    	function sendToCosmos(
    		address _tokenContract,
    		string calldata _destination,
    		uint256 _amount
    	) 
    

    to this:

    	function sendToCosmos(
    		address _tokenContract,
    		string calldata _destination,
    		uint256 tokenId
    	) 
    

    And then in the code, use ERC721 instead of ERC20 wherever we are interacting with ETH.

    opened by humanalgorithm 6
  • Fix Mac M1 build

    Fix Mac M1 build

    Problem: Running bash tests/all-up-test.sh on a Mac with Apple M1 Max processor. Getting error message that eth image can not be found and then failing setup.

    qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
    

    Solution: There are 3 bash scripts that need to be updated:

    • tests/all-up-test.sh
    • tests/build-container.sh
    • tests/start-chains.sh

    In each of these scripts I put an if branch on if Mac OS and M1 processor then append --platform=linux/amd64 to docker run. Linux users should see no change with this PR

    Additional findings: There is a "Docker not found" error when running ./start-chains.sh

    /usr/bin/which: no docker in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/go/bin:/usr/local/go/bin)
    

    It seems like the script still runs to success, however if we want to additionally fix this we can add the following to container-scripts/reload-code.sh before the Make command:

    sudo dnf -y install dnf-plugins-core
    sudo dnf -y config-manager \
        --add-repo \
        https://download.docker.com/linux/fedora/docker-ce.repo
    sudo dnf -y install docker-ce docker-ce-cli containerd.io
    
    opened by humanalgorithm 6
  • Transactions with blacklisted eth receivers are included in a batch profitability comparison

    Transactions with blacklisted eth receivers are included in a batch profitability comparison

    When building a batch, transactions are first collected from the outgoing transaction pool in order to calculate the total bridge fee and check if a more profitable batch of the same token type already exists in the pool. When doing this, there is no check if the translation’s destination address is included in the blacklist or not. Later, when transactions are collected to be included in the batch, additional blacklist filtering is applied. This can cause potential creation of the less profitable batch than the one of the same token type with the biggest nonce already in the pool. Also, the double retrieval of the calculations seems unnecessary.

    bug 
    opened by stana-ethernal 5
  • Properly tag and version the module sub-module

    Properly tag and version the module sub-module

    If a user/app wants to use the gravity bridge (module) as a dependency, they currently have to rely on a git hash. e.g. https://github.com/umee-network/umee/pull/369/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6

    I believe the top-level/root package needs to include a go.mod and that go.mod needs to include the sub-module. e.g. https://github.com/PeggyJV/gravity-bridge/blob/main/go.mod

    This way, users can import the module via the semantic version đź‘Ť

    enhancement 
    opened by alexanderbez 5
  • Migrate keys from strings to hashed strings

    Migrate keys from strings to hashed strings

    This PR includes the following changes:

    1. Store key prefixes are changed from strings to hashed strings (e.g. "ValsetRequestKey" -> HashFunc("ValsetRequestKey")). Methods for creating keys in key.go now use and return []byte, thus avoiding unnecessary string[]byte conversions. Some keys were not used anywhere, so we removed them.
    2. Method ConvertByteArrToString() is no longer used in key creation, except in one place. This method produces bad results in cases when the highest bit in any of input bytes is set to 1. This results in one byte sometimes being converted into two bytes when casting back to bytes to create the key (e.g. []byte(ConvertByteArrToString(inputBytes)). Also, []byte can be directly casted into string so the method is redundant. The only place we had to keep this method is for the PastEthSignatureCheckpointKey, since the key was constructed from the prefix concatenated with ConvertByteArrToString(checkpoint). Since the checkpoint is 32 bytes long, if any of bytes had the highest bit set to 1 it would be converted to two bytes so the key length could be len(PastEthSignatureCheckpointKey) plus 32 to 64 bytes depending on the checkpoint content. Converting variable number of bytes back to correct 32 bytes isn't possible because we can't know which bytes are "real" and which ones are added as a result of running ConvertByteArrToString(). And since the value stored under the key is 0 or 1 we couldn't reconstruct the key from the value during store migrations, so we had to keep the method, but we made it unexported and added comment that it shouldn't be used anywhere except in this case.
    3. Store migrations are written to migrate all keys from strings to hashed strings, while keeping the old values. Keys created with unused prefixes will be removed from the store during migration, if such values existed at all.
    4. Chain upgrade handler is added in app.go. We named this initial upgrade handler "v1.5" since Justin mentioned that the next release of Gravity Bridge will be 1.5. Is this OK to you?
    opened by dusan-ethernal 4
  • refator: improve GetAttestations

    refator: improve GetAttestations

    Allows users a bit more filtering control over getting attestations. Such possible queries include:

    • query_attestations
    • query_attestations?limit=100
    • query_attestations?limit=100&order_by=asc|desc
    • query_attestations?claim_type=foo&limit=100&order_by=asc|desc
    • query_attestations?nonce=40
    • query_attestations?height=999

    Also fixes IterateAttestaions typo

    closes: #102

    opened by alexanderbez 4
  • fix: refactor gRPC service query URLs

    fix: refactor gRPC service query URLs

    • Updates the following batch related gRPC service URLs so they don't clobber with the other batch related URLs:
      • /gravity/v1beta/batch/{address} -> /gravity/v1beta/batch/last_pending_request_by_addr
      • /gravity/v1beta/batch/{nonce} -> /gravity/v1beta/batch/request_by_nonce
    • Just a tad bit of linting cleanup :)

    closes: #94

    opened by alexanderbez 4
  • Add support for multiple EVM chains

    Add support for multiple EVM chains

    This is Part 1 of Adding support for multiple EVM chains (issue #117)

    Changes in this PR include:

    • Added chain prefix for keys and method calls
    • Store changes to support data for multiple EVM chains
    • Store migrations
    • Import/Export of genesis to include multiple EVM chains
    • Modifying tests
    opened by sasa-ethernal 0
  • Error handling in SetOrchestratorAddress

    Error handling in SetOrchestratorAddress

    I have found some issues in the error handling of a few funtions.

    1. In SetOrchestratorAddress ValidateBasic is returning return nil, sdkerrors.Wrap(err, "Key not valid") where it should just return nil, err as ValidateBasic function itself is sending back a wrapped message. See here

    2. Similarly, below code blocks seem to do exactly the same function:

    val, e1 := sdk.ValAddressFromBech32(msg.Validator)
    orch, e2 := sdk.AccAddressFromBech32(msg.Orchestrator)
    addr, e3 := types.NewEthAddress(msg.EthAddress)
    if e1 != nil || e2 != nil || e3 != nil {
    	return nil, sdkerrors.Wrap(err, "Key not valid")
    }
    
    // ValidateBasic performs stateless checks
    func (msg *MsgSetOrchestratorAddress) ValidateBasic() (err error) {
            if _, err = sdk.ValAddressFromBech32(msg.Validator); err != nil {
    		return sdkerrors.Wrap(sdkerrors.ErrInvalidAddress, msg.Validator)
    	}
    	if _, err = sdk.AccAddressFromBech32(msg.Orchestrator); err != nil {
    		return sdkerrors.Wrap(sdkerrors.ErrInvalidAddress, msg.Orchestrator)
    	}
    	if err := ValidateEthAddress(msg.EthAddress); err != nil {
    		return sdkerrors.Wrap(err, "ethereum address")
    	}
    	return nil
    }
    
    1. If we go further, notice that in entire function err is used to return (which is actually coming from ValidateBasic and would be giving you wrong error) while types.ErrType should be used, for example return nil, sdkerrors.Wrap(err, "Duplicate Ethereum Key") should be return nil, sdkerrors.Wrap(types.ErrDuplicate, "Duplicate Ethereum Key")
    opened by hammadtq 0
  • Validator Contributions

    Validator Contributions

    We have many validators. And it would be great to create a branch, or leave this branch with information about what exactly the validator did for the project.

    We have different validators with different abilities. There are validators who are interested in the long term and are doing something for the project. (Development, marketing, promotion in social networks). I think that such validators need to be encouraged somehow. The best encouragement is an additional delegation to the validator who has done something for the project.

    I suggest this format: Validator name (link)

    1. Contribution (link)
    2. Contribution (link)
    opened by PavelMoneyin 0
Releases(v1.5.3)
Owner
Gravity Bridge Foundation
Gravity Bridge Foundation
Our aim is to expand the capabilities of blockchain and make a secure way for transferring NFT between RMRK and MOVR blockchain.

remov Inspiration Our aim is to expand the capabilities of blockchain and make a secure way for transferring NFT between RMRK and MOVR blockchain. The

RMRK Team 4 Jan 10, 2022
A Matrix-iMessage puppeting bridge

A Matrix-iMessage puppeting bridge. The bridge runs on a Mac or jailbroken iPhone (soon™). A websocket proxy is required to receive appservice events from the homeserver.

Tulir Asokan 130 Jun 29, 2022
vks is a Vulkan bridge for Go.

vks vks is a Vulkan bridge for Go. The header generator folder contains the code that is used to generate the vulkan bindings. It woks similar to c-fo

Jason Watson 6 Apr 21, 2022
Bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API

bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)

Wim 5k Jun 28, 2022
Bridge facebook messenger with any service supported by matterbridge

fbridge fbridge bridges facebook messenger with any service supported by matterbridge trough the API interface. fbridge is using fbchat to connect to

null 25 Mar 17, 2022
Facebook bridge used with matterbridge

fbridge-asyncio This repo is a fork of fbridge. If you log in to your facebook account from a browser, after you do, it's a good idea to restart fbrid

null 9 Jun 12, 2022
An inline buildpack for deploying a mattermost-irc bridge

Matterbridge-Heroku An inline buildpack for hosting Matterbridge on Heroku. Heroku is a platform for easily deploying applications. A buildpack provid

Christopher DeCairos 11 May 17, 2022
Grpc bridge to various mediabank related systems

Mediabank bridge This internal tool enables authenticated gRPC based endpoint for securely communicating with systems like: Telestream Vantage Workflo

BCC Code 0 Jan 7, 2022
Bridge REMOV will allow you to safely transfer NFT from RMRK to MOVR and backwards

remov Inspiration Our aim is to expand the capabilities of blockchain and make a secure way for transferring NFT between RMRK and MOVR blockchain. The

null 1 Dec 5, 2021
Celestia -> EVM bridge

Peggo Peggo is a Go implementation of the Peggy (Gravity Bridge) Orchestrator originally implemented by Injective Labs. Peggo itself is a fork of the

Celestia 45 Jun 23, 2022
A REST API for the DN42 registry, written in Go, to provide a bridge between interactive applications and the registry.

dn42regsrv A REST API for the DN42 registry, written in Go, to provide a bridge between interactive applications and registry data. A public instance

Simon Marsh 0 Apr 21, 2022
A bridge from the Stellar network to other blockchains

Creating equitable access to the global financial system Starbridge Starbridge is software that facilitates bridge builders who are connecting the Ste

Stellar 28 Jun 23, 2022
RuuviBridge - Utility to bridge RuuviTag data between various sources and consumers

RuuviBridge RuuviBridge is designed to act as a "data bridge" between various so

Scrin 7 Jul 1, 2022
🧙 High-performance PHP-to-Golang IPC/RPC bridge

High-performance PHP-to-Golang IPC bridge Goridge is high performance PHP-to-Golang codec library which works over native PHP sockets and Golang net/r

RoadRunner 1.1k Jun 24, 2022
Official IVPN Desktop app

IVPN for Desktop (Windows/macOS/Linux) IVPN for Desktop is the official IVPN app for desktop platforms. Some of the features include: multiple protoco

IVPN 130 Jul 1, 2022
Notion Official API Go Client.

go-notion Go SDK for Notion Official API. go get github.com/sorcererxw/go-notion Overview Getting Started Pagination Error Handling Reverse Proxy OAut

QianyuPan 14 Aug 4, 2021
Official Go implementation of the Fixcoin protocol

XFSGO Official Go implementation of the XFS protocol. Usage To learn more about the available xfsgo commands, use xfsgo help or type a command followe

XFS Network 0 May 18, 2022
Official Go Client for OpenSearch

OpenSearch Go Client Welcome! Project Resources Code of Conduct License Copyright Welcome! opensearch-go is a community-driven, open source fork of go

null 65 Jun 30, 2022
A simple non-official client for qvapay service with go, for our comunity

qvapay-go A simple non-official client for qvapay service with go, for our comunity Setup You can install this package by using the go get tool and in

Kenrique Ortega 8 Dec 26, 2021