informalsystems/ibc-rs

Rust implementation of the Inter-Blockchain Communication (IBC) protocol

This project comprises primarily four crates:

ibc-rs

.

  • The ibc crate defines the main data structures and on-chain logic for the IBC protocol.
  • The ibc-relayer crate provides an implementation of an IBC relayer, as a library.
  • The ibc-relayer-cli crate is a CLI (a wrapper over the ibc-relayer library), comprising the hermes binary.
  • The ibc-proto crate is a library with Rust types generated from .proto definitions necessary for interacting with Cosmos SDK and its IBC structs.
  • The ibc-telemetry crate is a library for use in the hermes CLI, for gathering telemetry data and exposing that in a Prometheus endpoint.

See the table below for more details.

Includes TLA+ specifications.

Crate name Type Version Docs
ibc (modules) lib
ibc-relayer lib
ibc-relayer-cli bin: hermes
ibc-proto lib
ibc-telemetry lib

Requirements

Developed with the latest stable version of Rust: 1.53.0. (May work with older versions.)

Hermes Guide

The relayer CLI binary, called hermes, has a comprehensive guide at hermes.informal.systems.

Contributing

IBC is specified in English in the cosmos/ibc repo. Any protocol changes or clarifications should be contributed there.

This repo contains the TLA+ specification and Rust implementation for the IBC modules and relayer. If you're interested in contributing, please comment on an issue or open a new one!

See also CONTRIBUTING.md.

Versioning

We follow Semantic Versioning, though APIs are still under active development.

Resources

  • IBC Website
  • IBC Specification
  • IBC Modules in Go
  • IBC Relayer in Typescript
  • IBC Relayer in Go

License

Copyright © 2021 Informal Systems Inc. and ibc-rs authors.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use the files in this repository except in compliance with the License. You may obtain a copy of the License at

https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Issues

Collection of the latest Issues

hu55a1n1

hu55a1n1

bug
Comment Icon0

Crate

ibc

Summary of Bug

We must check if a packet has already been relayed on ordered channels and return a PacketAlreadyReceived error. We also need to treat this as a no-op at the dispatch level and emit the right events (note that events are missing in both un-/ordered cases).

Version

master


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
seanchen1991

seanchen1991

code-hygiene
Comment Icon0

Crate

ibc-relayer

Summary

The ConnectionEnd::versions getter method clones the versions vector. I think it would make more sense to have this method not allocate and return a &’a [Versions] instead.

Problem Definition

Getter methods in Rust typically return a reference. It’s not explicit in the ConnectionEnd::versions method that it is allocating, so these calls are more expensive than they might seem.

Proposal

It looks like it would be pretty straightforward to change the method to return a slice, as well as convert any downstream calls to the method to accept a &'a [Version] instead. Some call sites will require a .to_vec to get back an owned vector, but I think it makes more sense to do that than to have the versions getter method return an owned vector.

Acceptance Criteria

ConnectionEnd::versions returns a &’a [Versions] and any code calling this method is revised to accept this type as input.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
adizere

adizere

bug
Comment Icon0

Crate

ibc-relayer ibc-relayer-cli

Summary of Bug

This is a bug reported by a relayer operator.

The symptom reported is as follows

when a client is "too old", hermes enter in an infinite loop and don't care of the other chains

Logs below

I get an infinite loop of the "refresh" message after this.

The fix was

I have removed the DIG chain from our config and it's back in operation

Version

Steps to Reproduce

Unclear. We would need to somehow prune a chain's state.

Acceptance Criteria


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
adizere

adizere

admin
Comment Icon0

Release IBC-RS v.0.12.0

TODOs:

The usual:

  • Create a new release in the changelog, using unclog.
  • Bump all crate versions to the new version.
  • Reassign unfinished issues of previous milestone to the next milestone.
  • Update Cargo.lock file (if re-publishing ibc-relayer-cli)
adizere

adizere

dependencies
Comment Icon0

Supporting cosmwasm environment for ibc-proto


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
lyqingye

lyqingye

bug
Comment Icon3

Crate

hermes

Summary of Bug

log analysis:

  1. latest height = 1435560, clearing pending packet height = latest height - 1 = 1435559
  2. query unprocessed events at height = 1435559
  3. build packet proof at height = 1435559
  4. build update client at height = 1435560

There seems to be no problem with the logic. Proof height + 1 = client state height < latest height But the error log looks strange

validTime = 1644781101580283164 currentTimestamp = 1644781099180419908 currentTimestamp < validTime

UpdateclientMsg and RecvPacketMsg are executed in the same transaction. under normal circumstances(delayTimePeriod = 0), ProcessedTime should be equal to CurrentTimestamp

Version

0.10.0

Steps to Reproduce

unable to reproduce

Acceptance Criteria


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
yito88

yito88

Comment Icon3

Crate

ibc

Summary

max_expected_time_per_block should return Result<u64, Ics04Error> in ChannelReader

Problem Definition

Getting the parameter could fail in some implementation

Proposal

max_expected_time_per_block and block_delay return Result

Acceptance Criteria

max_expected_time_per_block and block_delay return Result


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
dhogaivannan

dhogaivannan

P-high
Comment Icon14

Crate

ibc-rs (Hermes)

Summary of Bug

Creating channels between Band Protocol and another chain from it's oracle port for fetching prices, it throws could not resolve channel and port is invalid.

Version

hermes - release - v0.11.1

Steps to Reproduce

ibc-0 = Band Protocol (band-laozi-testnet4) ibc-1 = Any chain with oracle port*

* = https://github.com/comdex-official/comdex/tree/oracle-liquidation (This binary and branch contains bandoracle port for fetching prices)

hermes create channel test-1 band-laozi-testnet4 --port-a bandoracle --port-b oracle

Logs:

Acceptance Criteria

Port from Band or Comdex getting detected for channel creation.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
soareschen

soareschen

no-std
Comment Icon1

Crate

ibc, ibc-proto

Summary

With #1846 merged, the ibc and ibc-proto crates on master branch now fully support no_std. There are just two dependencies that need to be patched for no_std to fully work:

As of now, developers who need full no_std support can include the following section in their project Cargo.toml:

Acceptance Criteria

This issue will be closed when new version of ibc-rs is released, and no_std us supported without requiring the [patch.crates-io] section.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
livelybug

livelybug

modules
Comment Icon1

Hello,

When implementing Beefy protocol, based on Grandpa consensus, there are 3 kinds of verifications in a hierarchical structure.

  • The top tier verification is MMR root verification, by collecting sufficient validators' valid signatures.
  • Based on a valid MMR root, the 2nd tier is block header verification.
  • Based on a valid block header, the 3rd tier is on-chain storage verification, which calculates the correct on-chain storage by the state root, the storage proof, and the storage key. A successful verification needs the state root and storage proof to be from the same block. However, as the height is increased by one when composing proofs of connection, channel, and packet, the corresponding state root always belong to the header of block height N + 1, while the storage proof belongs to block height N, resulting in a failed verification

Understand the height.increment() may be for Tendermint consensus, is it possible to compose a trait for it, and allow consensus-specific implementation?

Thank you

adizere

adizere

relayer
Comment Icon0

Summary

In preparation for extensive use in production, we would like to test that the Hermes connection delay functionality works as expected. This is a meta-issue to track the efforts on that front

Acceptance Criteria

Sub-issues:

  • #1772
  • #1773
  • write an automated test to exercise and assert the correctness of packet delays on a connection that has non-zero delay.

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
adizere

adizere

question
Comment Icon2

Summary

In preparation for releasing ICA on the hub, we would like to do some testing that channel ordering works as expected in Hermes.

Proposal

  • set up ordered channels between 2 chains
  • provoke out-of-order packet relaying by either manually instrumenting the relayer code to drop the first event out of a batch, or by evicting transactions from thee node's mempool before they commit to the blockchain

Stretch goal:

  • benchmark the scalability properties of Hermes by deploying it on a server similar to real-world operator use, and assess how many channels can Hermes relay gracefully on such a machine
    • the bottleneck will likely be the chain software, not Hermes: confirm that by isolating the networks on machines separate from the one where Hermes is running.

Acceptance Criteria

  • capture a packet ordering corner-case in an automated test using the Rust framework
    • ensure that Hermes enforces ordering by looking at packet sequence numbers on an ordered channel

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
seanchen1991

seanchen1991

relayer
Comment Icon0

Crate

ibc_rs::relayer

Summary

In #1705, pagination of queries was used to reduce some redundant network calls. We should look at other ways in which query pagination can be used to limit unnecessary network calls.

Problem Definition

This should help to improve relayer performance. At the moment we are also simply not taking advantage of query pagination.

Proposal

Currently any query where pagination can be toggled on merely utilizes pagination::all(). We can search for all of these spots and evaluate whether it makes sense to limit the number of results returned from the query.

Acceptance Criteria

Evaluate and update all appropriate queries being performed in the relayer to take advantage of query pagination.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
adizere

adizere

bug
Comment Icon0

Context

This was a debugging session with a relayer operator. We logged here our findings from running the Hermes dev feature from PR #1705. The problems documented below are, however, not related to this PR. The symptom the operator was reporting is that Hermes is not relaying anything. This was a red herring, however.

Takeaway

The important problem signaled in this issue is that Hermes misinterpret SDK error 13 (empty operator wallet).

Log remarks

Estimated gas higher than max gas

This is a misconfiguration.

  • 1080 Jan 20 17:11:51 Imperator-Relayer hermes[1854166]: 2022-01-20T17:11:51.399192Z DEBUG ThreadId(49) send_tx_check{id=EYIMu5yhL8}:send_tx{id=panacea-3}: send_tx: estimated gas is higher than max gas id=panacea-3 estimated=1074310 max=700000

  • this error appears more than once, eg
  • 3562 Jan 20 17:49:29 Imperator-Relayer hermes[1854166]: 2022-01-20T17:49:29.580983Z DEBUG ThreadId(49) send_tx_check{id=JzxT5jQzws}:send_tx{id=panacea-3}: send_tx: estimated gas is higher than max gas id=panacea-3 estimated=1045902 max=700000 3563 Jan 20 17:49:29 Imperator-Relayer hermes[1854166]: 2022-01-20T17:49:29.581497Z ERROR ThreadId(79) packet_cmd{src_chain=osmosis-1 src_port=transfer src_channel=channel-82 dst_chain=panacea-3}: will retry: schedule execution encountered error: failed with underlying error: pana cea-3 gas estimate 1045902 from simulated Tx exceeds the maximum configured 700000 retry_index=1

Potential fix: The relayer operator should set max_msg_num = 25 for Panacea chain to a smaller value, eg 10. Alternatively: increase the max_gas for that chain to above 1 Million.

Empty wallet on hub-4

This is a Hermes bug, but also a misconfiguration (i.e., the wallet was empty)

  • 1131 Jan 20 17:11:56 Imperator-Relayer hermes[1854166]: 2022-01-20T17:11:56.794857Z ERROR ThreadId(42) send_tx_check{id=LbwPkAfBIu}:send_tx{id=cosmoshub-4}: broadcast_tx_sync: Response { code: Err(13), data: Data([]), log: Log("insufficient fees; got: 461uatom required: 11512uatom : insufficient fee"), hash: transaction::Hash(C74CC256F26AA388B54742360A534E10CB8E553D766D226F31449DE553DAA5EA) }: diagnostic: unknown SDK error: 13 1132 Jan 20 17:11:56 Imperator-Relayer hermes[1854166]: 2022-01-20T17:11:56.795017Z INFO ThreadId(59) packet_cmd{src_chain=osmosis-1 src_port=transfer src_channel=channel-0 dst_chain=cosmoshub-4}:relay{odata=LbwPkAfBIu ->Destination @1-2876533; len=1}: [Async~>cosmoshub-4] respon se(s): 1; Err(13):C74CC256F26AA388B54742360A534E10CB8E553D766D226F31449DE553DAA5EA 1133 Jan 20 17:11:56 Imperator-Relayer hermes[1854166]: 2022-01-20T17:11:56.795099Z INFO ThreadId(59) packet_cmd{src_chain=osmosis-1 src_port=transfer src_channel=channel-0 dst_chain=cosmoshub-4}:relay{odata=LbwPkAfBIu ->Destination @1-2876533; len=1}: success

  • The problem here is that Hermes does not catch the "SDK error: 13" and instead interprets this as a "success".

Fix: At the very least, we should improve logs and treat "SDK error: 13" as an non-recoverable error. Fix: Add more uatom to the wallet of chain cosmoshub-4

Version

#1705

Acceptance criteria

  • improve logs and treat "SDK error: 13" as an non-recoverable error.

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
adizere

adizere

proto
Comment Icon0

Summary

We want to upgrade the proto files that ibc modules & Hermes uses to match the latest available interfaces from the Cosmos SDK and ibc-go library.

Acceptance Criteria

Note that #1168 depends on the present issue.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
adizere

adizere

cli
Comment Icon0

Would it make sense to have hermes use the right derivation path (by default) based on the chain config address_type = { derivation = 'evmos', ...? For eg. m/44'/118'/0'/0/0 for cosmos and m/44'/60'/0'/0/0 for evmos?

Originally posted by @hu55a1n1 in https://github.com/informalsystems/ibc-rs/pull/1794#discussion_r788628858

For instance, Hermes could automatically infer that it should use derivation path m/44'/118'/0'/0/0 for cosmos and m/44'/60'/0'/0/0 for Ethermint keys.

adizere

adizere

bug
Comment Icon1

Crate

ibc-relayer

Summary of Bug

When Hermes observes that a transaction hash remains unconfirmed, if tx_confirmation = true it proceed to re-submitting that transaction.

The resubmit step hapens here:

https://github.com/informalsystems/ibc-rs/blob/37d54d4d851d3d7af394845e05b17b4d0e66afd7/relayer/src/link/pending.rs#L158-L165

Which simply calls the relay_from_operational_data method:

https://github.com/informalsystems/ibc-rs/blob/2757031e029c5456f7cfe483bcca0e34ba2d5ef4/relayer/src/link/relay_path.rs#L1279

This is problematic, however, because method relay_from_operational_data blindly takes the messages that Hermes originally generated and calls broadcast_tx_sync with them, but these messages may comprise PacketRecv that are no longer relevant (because they might have timed-out in the meantime). If Hermes fails to resubmit succesfully, it retries indefinitely.

Version

v0.10

Steps to Reproduce

Unclear how to reproduce this, the main source of this bug report is a log h/t @faddat -- https://gist.github.com/adizere/e49c5083b3a3bae2d4a03735e5a8196a

As these logs reveal, the timeout in the confirmation logic triggers, and then Hermes tries to resubmit, but then it fails because the packets are timed-out. The relevant snippet is this one:

Acceptance Criteria

There are two separate problems here:

  1. Hermes should not retry indefinitely to resubmit messages that are no longer relevant (eg timed-out packets), and should just drop them instead of calling push_back in the pending queue.
  2. Hermes should not blindly resubmit messages that may be stale, but should use the original events in the operational data to regenerate (potentially new) messages that it can subsequently use to broadcast_tx_sync.

I think solving (2) will imply solving (1), but not 100% sure.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
ivan-gavran

ivan-gavran

documentation
Comment Icon2

Crate

ibc

Summary of Bug

Following the README file of the Integration test suite, I tried to build the docs by running cargo doc -p ibc-integration-test --open. This fails with three bugs:

  • no item named tendermint_light_client in scope
  • modules/src/applications/mod.rs:12:9 : this URL is not a hyperlink
  • modules/src/core/ics23_commitment/merkle.rs:43:10 : this URL is not a hyperlink

Version

0.10.0

Steps to Reproduce

  • navigate to ibc-rs/tools/integration-test
  • run cargo doc -p ibc-integration-test --open

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate milestone (priority) applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
Versions

Find the latest versions by id

v0.0.1 - Jul 01, 2020

This is the initial prototype release of an IBC relayer and TLA+ specifications.

Information - Updated Feb 17, 2022

Stars: 173
Forks: 82
Issues: 137

Wagyu Etherum blockchain ledger and wallet in Rust

Cross platform ether wallet generator that makes automated creation of crypto wallets easy

Wagyu Etherum blockchain ledger and wallet in Rust

Reference implementation of the Stacks blockchain in Rust

Reference implementation of the Proof of Transfer (PoX) mining that anchors to Bitcoin security

Reference implementation of the Stacks blockchain in Rust

Blockchain Commons torgap-sig-cli-rust

torgap-sig-cli-rust is a fork of Minisign, with support for

Blockchain Commons torgap-sig-cli-rust

A Blockchain implementation in Rust

MIT (c) Doublify Technologies

A Blockchain implementation in Rust

A simple blockchain example written in Rust:

Defines data structures to model a minimum blockchain

A simple blockchain example written in Rust:

A Blockchain implementation in pure Rust

Below find an example usage of the library:

A Blockchain implementation in pure Rust

Reference implementation of the Stacks blockchain in Rust

Reference implementation of the Proof of Transfer (PoX) mining that anchors to Bitcoin security

Reference implementation of the Stacks blockchain in Rust

Katniane REST Service

Rust-based REST service for the Katniane blockchain

Katniane REST Service
Facebook Instagram Twitter GitHub Dribbble
Privacy