#ibc #blockchain #cosmos #consensus #tendermint #data-structures

ibc-relayer-types

Implementation of the Inter-Blockchain Communication Protocol (IBC). This crate comprises the main data structures and on-chain logic

25 releases

new 0.29.5 Dec 13, 2024
0.29.4 Nov 20, 2024
0.29.3 Sep 2, 2024
0.29.1 Jul 23, 2024
0.20.0 Oct 28, 2022

#746 in Magic Beans

Download history 456/week @ 2024-08-27 1705/week @ 2024-09-03 1038/week @ 2024-09-10 998/week @ 2024-09-17 1180/week @ 2024-09-24 988/week @ 2024-10-01 1269/week @ 2024-10-08 1240/week @ 2024-10-15 1078/week @ 2024-10-22 961/week @ 2024-10-29 700/week @ 2024-11-05 1065/week @ 2024-11-12 1404/week @ 2024-11-19 1314/week @ 2024-11-26 797/week @ 2024-12-03 1300/week @ 2024-12-10

5,270 downloads per month
Used in 38 crates (26 directly)

Apache-2.0

650KB
16K SLoC

IBC module

Crate Docs Build Status End to End testing Apache 2.0 Licensed Rust Stable Rust 1.51+

See the ibc-rs repo root for more detailed information on how this crate can be used.

Implementation of the Inter-Blockchain Communication Protocol (IBC) module.

Documentation

See documentation on docs.rs.

Divergence from the Interchain Standards (ICS)

This crate diverges from the ICS specification in a number of ways. See below for more details.

Module system: no support for untrusted modules

ICS 24 (Host Requirements) gives the following requirement about the module system that the host state machine must support:

The host state machine must support a module system, whereby self-contained, potentially mutually distrusted packages of code can safely execute on the same ledger [...].

This crate currently does not support mutually distrusted packages. That is, modules on the host state machine are assumed to be fully trusted. In practice, this means that every module has either been written by the host state machine developers, or fully vetted by them.

Port system: No object capability system

ICS 5 (Port Allocation) requires the host system to support either object-capability reference or source authentication for modules.

In the former object-capability case, the IBC handler must have the ability to generate object-capabilities, unique, opaque references which can be passed to a module and will not be duplicable by other modules. [...] In the latter source authentication case, the IBC handler must have the ability to securely read the source identifier of the calling module, a unique string for each module in the host state machine, which cannot be altered by the module or faked by another module.

This crate currently requires neither of the host system. Since modules are assumed to be trusted, there is no need for this object capability system that protects resources for potentially malicious modules.

For more background on this, see this issue.

Port system: transferring and releasing a port

ICS 5 (Port Allocation) requires the IBC handler to permit transferring ownership of a port and releasing a port.

We currently support neither.

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.

Dependencies

~19–29MB
~516K SLoC