Interblockchain communication protocol (IBC) implementation in Golang.

Related tags

Cryptography ibc-go
Overview

ibc-go

Interblockchain communication protocol (IBC) implementation in Golang built as a SDK module.

Components

Core

The core/ directory contains the SDK IBC module that SDK based chains must integrate in order to utilize this implementation of IBC. It handles the core components of IBC including clients, connection, channels, packets, acknowledgements, and timeouts.

Applications

Applications can be built as modules to utilize core IBC by fulfilling a set of callbacks. Fungible Token Transfers is currently the only supported application module.

IBC Light Clients

IBC light clients are on-chain implementations of an off-chain light clients. This repository currently supports tendermint and solo-machine light clients. The localhost client is currently non-functional.

Docs

Please see our documentation for more information.

Issues
  • Support Big Int IBC Transfer Amounts

    Support Big Int IBC Transfer Amounts

    Summary

    Support a larger amount field on FungibleTokenPacketData instead of uint64. This would make it's support in line with what MsgTransfer.Amount supports.

    The SDK currently panics when trying to convert a large MsgTransfer.Amount to the underlying FungibleTokenPacketData.Amount.

    Problem Definition

    Transferring tokens with 18 decimal places, like many Ethereum tokens for instance, are limited to insignificant amounts (< $1).

    Transferring these tokens by splitting the transfer into multiple smaller transfers would require several hundred or thousands messages.

    The fees increase significantly to an uneconomical state when needing to split a transfer to this degree.

    Keprl also does not handle this well in the UI, as this many messages shouldn't really be a use case.

    Some relayers also don't handle these large transactions well.

    Proposal

    Introduce a larger amount field (i.e string) on FungibleTokenPacketData proto message, to replace the current amount field.


    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    opened by timlind 23
  • Modify CheckHeaderAndUpdateState to set client state/consensus states in IBC light client implementations

    Modify CheckHeaderAndUpdateState to set client state/consensus states in IBC light client implementations

    Summary

    02-client should not set client states and consensus states as generalizing IBC client implementations is difficult. Better to give IBC clients more control and flexibility. This will already be useful for solo machines which don't need to store consensus states for each update height

    This design is already specified in ICS, our implementation didn't follow those changes. See comment


    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    core improvement 02-client 
    opened by colin-axner 21
  • Channel capability not found after chain_id change

    Channel capability not found after chain_id change

    Summary of Bug

    After I do an ibv-upgrade with changed chain_id to rev 2 and starting height from block 1, I get the following error:

    {
        "height": "27",
        "txhash": "F3C47BDE2CFFF22E3FF9CC782F74E7CEABE4B570FDE7E36BAC88063088B032A7",
        "codespace": "channel",
        "code": 9,
        "data": "",
        "raw_log": "failed to execute message; message index: 0: module does not own channel capability: channel capability not found",
        "logs": [],
        "info": "",
        "gas_wanted": "200000",
        "gas_used": "43092",
        "tx": null,
        "timestamp": ""
    }
    

    I found a simmilar issue here.

    In my case though, creating a new channel and transferring over it works fine.

    Version

    Cosmos sdk v0.44.3, Ibc-go v1.1, Hermes relayer v0.9

    Steps to Reproduce

    1. Get 2 chains and a relayer up.
    2. Create clients and channel between them.
    3. Make an ibc-upgrade proposal, with client state that is exported from chain b and has the following fields edited:
    • chain_id to rev 2
    • trusting_period set to 0
    • frozen_height revision_height to 1 block before the upgrade block
    • latest_height revision_number to 2 and revision_height to 1
    1. Vote and pass the upgrade
    2. When chain a halts, upgrade client from the Hermes relayer
    3. Replace chain a binary with one that has a basic upgrade handler for the upgrade:
    	app.UpgradeKeeper.SetUpgradeHandler("val", func(ctx sdk.Context, plan upgradetypes.Plan, a module.VersionMap) (module.VersionMap, error) {
    		return a, nil
    	})
    
    1. Export the genesis, change the chain_id and starting-height and replace the old one with it.
    2. unsafe-reset-all and start chain a
    3. Try to send token transfer from chain a to chain b over the existing channel.

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    opened by V-Staykov 14
  • manually test IBC cli cmds

    manually test IBC cli cmds

    Summary

    The IBC cli is not being used or tested. It should be refactored to support more dynamic usage.

    Problem Definition

    While working through 03-connection I noticed the cmd for the OpenTry handshake passed in proofInit to the proofConsensus field. Any attempt at using this command successfully should fail showing that no one has attempted to use this command (which is essential to doing anything IBC).

    The iqlusioninc relayer, one of the more widely used relayers, does not rely on these commands and instead has its own custom cli commands. There should be at least a few usable commands it could import instead of implementing all of its own. This should be true for any relayer.

    Proposal

    Refactor and test the IBC cli/rest commands with usability in mind. Currently proofs are passed in directly or by json file. There should be an option to pass in a connection endpoint to the counterparty chain to query and parse the proofs directly. Perhaps there should also be commands to query and store proofs (if there isn't already)

    This should probably be punted until after the gRPC refactor across the sdk codebase.


    A concrete list of things that need to be done to close this issue:

    manually test the following cmds:

    • [x] create client
    • [x] update client
    • [x] client misbehaviour
    • [ ] upgrade client
    • [x] transfer tx cmd
    • [ ] transfer query demon trace
    • [ ] transfer query denom traces
    • [x] query client state
    • [x] query client states
    • [x] query consensus state
    • [x] query consensus states
    • [ ] query header
    • [x] query node consensus state
    • [x] query connection
    • [x] query connections
    • [x] query client connections
    • [x] query channel
    • [x] query channels
    • [x] query connection channels
    • [x] query channel client state
    • [x] query packet commitment
    • [x] query packet commitments
    • [ ] query unreceived packets
    • [ ] query unrelayed acks
    • [x] query next sequence recv

    cmds to add and test:

    • [ ] relay packet
    • [ ] relay acknowledgement

    Also consider applying the original proposal of this issue, allowing an endpoint to be passed/queried for counterparty proofs. Maybe this can be opened in a separate issue and implemented if users request the same feature

    opened by colin-axner 14
  • Add a gRPC endpoint for fetching consensus state heights

    Add a gRPC endpoint for fetching consensus state heights

    Summary

    The ibc-rs codebase would benefit from a gRPC endpoint that only fetches consensus state heights for a given client.

    Problem Definition

    At the moment, height information is extracted after querying for all consensus states via the QueryConsensusStatesRequest query, which is suboptimal. It would be nice to be able to query just for consensus state heights so that the extra step of extracting all of the heights can be eliminated.

    Proposal

    Add a gRPC endpoint (perhaps something like QueryConsensusHeightsRequest) that returns all consensus state heights for a given client.


    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    client-UX feature 02-client 
    opened by seanchen1991 12
  • deps: update cosmos-sdk to 0.45

    deps: update cosmos-sdk to 0.45

    Summary

    Bump Cosmos SDK to 0.45.

    I propose ~~to release this together with #539 and~~ to release first v1 and v2. Once we cut the final release of v3.0.0, then we cut a new minor release of v3.


    For Admin Use

    • [x] Not duplicate issue
    • [x] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    dependencies 
    opened by crodriguezvega 12
  • feat: middleware support for ICS20

    feat: middleware support for ICS20

    Description

    Based on interchains-account implementation (https://github.com/cosmos/ibc-go/pull/417/files)

    closes: #347


    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by thomas-nguy 12
  • Create AnteDecorator to reject rendundant relayer messages

    Create AnteDecorator to reject rendundant relayer messages

    By creating an antedecorator that rejects redundant relayer messages, we can prevent relayers from wasting fees on trying to relay packets that have been relayed by another relayer.

    This antedecorator can be chained to the app's Antehandler.

    This is a non-breaking change.

    cc: @dtribble

    opened by AdityaSripal 12
  • Allow Relayers to overwrite payee address

    Allow Relayers to overwrite payee address

    ~~crypto dot com has a usecase involving paying the fees for relayer incentivization into a module account and then doing distribution from there. This can be supported if we have some method on the incentivizing chain that allows the payee address to be overwritten, so that we pay relayer fees to that address instead of the address we get from msg.sender or forward_relayer in the ack.~~

    ^This was based on an incorrect understanding.

    The intended use case is that relayers can set a different payout address for ack/timeout that is different than msg.Sender.

    We can either release this with 1.0 or add as a non-breaking feature addition

    cc: @crodriguezvega @damiannolan

    29-fee 
    opened by AdityaSripal 10
  • deps: upgrade of SDK to 0.46 and tendermint to 0.35

    deps: upgrade of SDK to 0.46 and tendermint to 0.35

    Description

    Upgrade of SDK to 0.46-alpha3 and Tendermint to 0.35.

    This PR is based on the excellent work done by @faddat on his PR. This PR is basically a subset of all the changes included in #949 (i.e. it adds only the changes strictly necessary for the upgrade of SDK and Tendermint) to narrow the scope and make the review easier.

    TODO:

    • Add changelog entry.
    • Add migration docs.

    closes: #909 #539


    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [x] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [x] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by crodriguezvega 10
  • Host chain doesn't account for multiple controller chains using overlapping namespace

    Host chain doesn't account for multiple controller chains using overlapping namespace

    Summary

    The host chain currently assumes that the controller port ID is unique amongst all its connected chains. This is immediately evident when viewing its setting of the interchain account. It uses only the controller port as the key. Thus two controller chains using the same format to generate the port address will collide. This seems highly probable as chains will likely reuse the same ICA auth modules.

    Previously the connection sequences were included in the portID thus making this assumption okay since a chains binded ports must be unique. Thus, there would never be two ownerA ports on connection 0. But there may be ownerA on connection 0 and ownerA on connection 1.

    Problem Definition

    The interchain account mapping on the host chain uses the controller port as the key. Controller ports are a prefix and account owner address. There is no uniqueness properties in the controller ports anymore.

    Proposal

    We should use either the connection sequence or channel sequence in the key for the interchain account address mapping. Since we still have the active channel mapping, I think it makes sense to use the connection sequence, otherwise you'd need to migrate the mapping when opening a new active channel. You'd also need to account for the channelID in ICA address generation. It is possible a channel is created on the controller chain which will never become an active channel (but the current controller handshake code might create an interchain account anyways). I don't think we need the controller chain connection sequence?

    Action items (separate pr's):

    • [ ] use the host chain connection sequence in the ica address mapping (key is now connectionSeq/controllerPort) + test cases
    • [ ] use host chain connection sequence when generating ica address + test cases

    For Admin Use

    • [ ] Not duplicate issue
    • [ ] Appropriate labels applied
    • [ ] Appropriate contributors tagged/assigned
    bug 27-interchain-accounts 
    opened by colin-axner 10
  • chore: add module name to incentivized packet events

    chore: add module name to incentivized packet events

    Description

    Most, if not all events include the module name. Updating incentivized_ibc_packet event to include module name

    closes: #XXXX


    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by damiannolan 1
  • docs: adding End Users section to ics29 docs

    docs: adding End Users section to ics29 docs

    Description

    partially closes: #1408


    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by seantking 1
  • docs: adding events to fee middleware docs

    docs: adding events to fee middleware docs

    Description

    • Adding an events.md to fee middleware, similarly to transfer

    closes: #XXXX


    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by damiannolan 0
  • docs: payee registration and fee distribution for relayer operators

    docs: payee registration and fee distribution for relayer operators

    Description

    • About fees and pay out semantics
    • How to register payee addresses for reverse/timeout relayer fee distribution
    • How to register counterparty addresses for forward relayer fee distribution
    • Message defs, validity of fields and example CLIs

    ref: #1408


    Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why.

    • [ ] Targeted PR against correct branch (see CONTRIBUTING.md)
    • [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
    • [ ] Code follows the module structure standards.
    • [ ] Wrote unit and integration tests
    • [ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
    • [ ] Added relevant godoc comments.
    • [ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
    • [ ] Re-reviewed Files changed in the Github PR explorer
    • [ ] Review Codecov Report in the comment section below once CI passes
    opened by damiannolan 0
  • `Height` semantics inconsistent with ICS 7

    `Height` semantics inconsistent with ICS 7

    ICS-7 Height definition doesn't treat 0 as a special case; in fact, it mentions "resetting the height to 0". However, ibc-go treats 0 as a special case throughout the codebase: it is rejected in, say, ClientState height validation.

    This causes problems for other implementations (notably in Rust): we can either copy ibc-go's semantics, or follow the standard and be incompatible with ibc-go.

    It is unclear to me whether the standard or the implementation should change, so I'm posting this here to start.

    opened by plafer 0
  • build(deps): bump github.com/stretchr/testify from 1.7.4 to 1.7.5

    build(deps): bump github.com/stretchr/testify from 1.7.4 to 1.7.5

    Bumps github.com/stretchr/testify from 1.7.4 to 1.7.5.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 1
Releases(v3.1.0)
Owner
COSMOS
The Internet of Blockchains
COSMOS
Simple, fast and safe cross-platform linear binary stream communication protocol. AES key exchange based on ecc secp256k1

FFAX Protocol 2 dev įŽ€äŊ“中文 Welcome to FFAX Protocol v2 Quick start go get github.com/RealFax/FFAX func example() { listener, err := net.Listen("tcp",

Realfax Messenger 15 Mar 21, 2022
Go language implementation of a blockchain based on the BDLS BFT protocol. The implementation was adapted from Ethereum and Sperax implementation

BDLS protocol based PoS Blockchain Most functionalities of this client is similar to the Ethereum golang implementation. If you do not find your quest

Yongge Wang 0 Jan 1, 2022
An out-of-the-box cryptographic message communication.

An out-of-the-box cryptographic message communication.

Dr. Takeyuki Ueda 0 Feb 8, 2022
Eunomia is a distributed application framework that support Gossip protocol, QuorumNWR algorithm, PBFT algorithm, PoW algorithm, and ZAB protocol and so on.

Introduction Eunomia is a distributed application framework that facilitates developers to quickly develop distributed applications and supports distr

Cong 2 Sep 28, 2021
Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

StarWORKS Global 0 Nov 24, 2021
RepoETH - Official Golang implementation of the Ethereum protocol

HANNAGAN ALEXANDRE Powershell Go Ethereum Official Golang implementation of the

Alexandre Hannagan 0 Jan 3, 2022
Go-ethereum - Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated b

i06 0 Jan 4, 2022
Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

Covalent 13 May 29, 2022
Koisan-chain - Official Golang implementation of the Koisan protocol

Go Ethereum Official Golang implementation of the Koisan protocol. Building the

null 0 Feb 6, 2022
Ethereum go-ethereum - Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated b

null 6 Feb 17, 2022
Terra client in golang with multiple protocol implementation (anchor, astroport, prism, ...)

Terra A terra client with some protocol partial implementations (anchor, prism, terraswap type routers, ...) To be able to compile, you need to add th

null 3 Apr 11, 2022
Implementation of the Filecoin protocol, written in Go

Project Lotus - 莲 Lotus is an implementation of the Filecoin Distributed Storage Network. For more details about Filecoin, check out the Filecoin Spec

Filecoin 2.3k Jun 30, 2022
Go Implementation of the Spacemesh protocol full node. 💾⏰đŸ’Ē

A Programmable Cryptocurrency go-spacemesh ?? ⏰ ?? Thanks for your interest in this open source project. This repo is the go implementation of the Spa

Spacemesh 577 Jun 28, 2022
Security research and open source implementation of the Apple 'Wireless Accessory Configuration' (WAC) protocol

Apple 'Wireless Accessory Configuration' (WAC) research Introduction This repository contains some research on how the WAC protocol works. I was mostl

Bertold Van den Bergh 6 Mar 13, 2022
Official Go implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

null 38.1k Jun 29, 2022
Dxc - Go implementation of DxChain3.0 protocol

DxChain 3.0 The Ecosystem Powered by DxChain 3.0 Smart Contract Platform While c

DxChain Network 2 Jan 10, 2022
This is a close to decentralized RSS3 Network implementation of RSS3 protocol v0.4.0 with full indexing function in Go

This is a close to decentralized RSS3 Network implementation of RSS3 protocol v0.4.0 with full indexing function in Go

Natural Selection Labs 40 Jun 25, 2022
DERO Homomorphic Encryption Blockchain Protocol

Homomorphic encryption is a form of encryption allowing one to perform calculations on encrypted data without decrypting it first. The result of the computation is in an encrypted form, when decrypted the output is the same as if the operations had been performed on the unencrypted data.

null 93 Jun 29, 2022
Monorepo implementing the Optimistic Ethereum protocol

The Optimism Monorepo TL;DR This is the primary place where Optimism works on stuff related to Optimistic Ethereum. Documentation Extensive documentat

OMG Network 37 Jun 13, 2022