2/ Like everything we build in Cosmos, IBC is a general purpose, extensible, layered protocol, in this case for packet streaming between blockchains.

There are four layers:
- Clients
- Connections
- Channels
- Packets
3/ The first layer is Clients. These are light client verifiers for other blockchains. They allow one chain to verify signed headers and Merkle proofs from another chain with the same security as that chain's light client.
4/ IBC defines a general Client interface, which can be implemented for each different blockchain consensus. We currently have a Tendermint Client, but Clients for Polkadot, Celo, and others are in the works.
5/ IBC also defines a "Solo Machine" Client, which allows a single pubkey or multisig to act like a blockchain connecting over IBC. @fekunze wrote a great thread about Solo Machines: https://twitter.com/fekunze/status/1351212533064093707
6/ For IBC to work at all, Clients on one chain must be continuously updated with transactions containing the headers and validator signatures (or equivalent) from the other chain. Clients also handle evidence of misbehaviour.
7/ The next, and simplest, layer is Connections. A Connection is a persistent relationship between Clients on two different chains. When two chains want to connect, they each install a client for the other chain, and then perform a Connection handshake to agree on versions/id.
8/ The next layer is Channels. Channels are where packet transmission and reception happens. Many channels may be multiplexed on a single connection, each with its own packet stream. Client updates on a single Connection amortize the overhead of many Channels.
9/ Each end of the channel is associated with a "Port" and each port is expected to have an owner, in the form of a Cosmos-SDK module or smart contract on the relevant blockchain. A channel is thus a packet stream between two modules or contracts on different blockchains!
10/ IBC supports both ordered and unordered channels. They are largely analogous to TCP and UDP. Packets sent on channels can timeout and can be acknowledged. Channels can ultimately be extended to support partial ordering, and other communication semantics.
11/ Today, channels can only be "1-hop", meaning the ends of the channel must be on blockchains with a direct Connection between themselves. But IBC will be extended to support "multi-hop" channels, which will require a routing infrastructure, to be anchored in the Cosmos Hub.
12/ The final layer is Packets. Packets are the objects sent on channels. Packets carry the actual application level data and the packet handlers trigger the application logic.
13/ The only packet type complete today is Fungible Token Transfer, which allows tokens to flow from one chain to another. Tokens are locked/unlocked in escrow on the one chain, and "vouchers" are minted/burned on the other. @fekunze again with details: https://twitter.com/fekunze/status/1351988932364349441
But packets are highly flexible, and many more types are under development. IBC is effectively an extensible distributed systems programming environment, with packet types and their handlers as the basic API for application developers.
What's an IBC app dev you ask? Did you really think @cosmos would roll out a new protocol and have it *not* be a kick-ass app dev platform? Fungible Token Transfers is just the beginning. Work has already begun on IBC-native NFTs, Interchain Accounts, and Cross-Chain Validation.
Interchain Accounts let you send arbitrary txs on one chain from an account on another, over IBC. You don't have to move coins first, or worry about other wallets - a wallet on the Cosmos Hub becomes Universal: https://twitter.com/billyrennekamp/status/1353041896097140737
We're also working on Cross-Chain Validation, again implemented as a packet protocol on IBC. This will provide a generalized form of "shared security" and "sharding" that will allow validators on the Hub to opt-in to validating on other chains. https://github.com/informalsystems/cross-chain-validation
Cross-chain validation provides a simpler path for new chains to launch, and to leverage the security of the staked ATOMs on the Cosmos Hub. But cross-chain validation is just an IBC extension, so we can define different flavours and run sharding experiments!
We're also working with @lazyledger_org on how IBC and optimistic rollup tech can augment each other to bring the best of decentralized scalability to the internet of blockchains!
We expect to see a whole repertoire of distributed systems primitives built out on IBC: locks, semaphores, leader election, even consensus itself, operating across multiple blockchains. IBC truly ushers in a new form of blockchain composability.
@agoric and @confio_tech are leading the charge on IBC-compatible smart contracts, in secure versions of Javascript and WASM, respectively. Expect some amazing new DeFi developments over IBC from them!
The final piece of IBC is the relayer. The actual off-chain process responsible for relaying txs between chains.

There are early working versions in Go and Rust:
- https://github.com/cosmos/relayer 
- https://github.com/informalsystems/ibc-rs

Anyone can run a relayer!
So the Client interface is ICS02, Connections are ICS03, ordered and unordered Channels are ICS04, Fungible Token Transfer is ICS20, Tendermint Client is ICS07, Polkadot's GRANDPA client is ICS10, and so on.
We also have formal specifications of pretty much the whole IBC protocol in TLA+: https://github.com/informalsystems/ibc-rs/tree/master/docs/spec

This helps us reason clearly about the protocol. But we can also use @ApalacheTLA to auto-generate tests for the code from the formal spec!
Formally verifying IBC's properties with the @ApalacheTLA model checker is ongoing!

In the meantime, @informalinc conducted an audit of the protocol and Go code in the Stargate release, which you can read about here: https://twitter.com/informalinc/status/1351940252617814017
IBC has been a huge collaborative effort, primarily among @interchain_io, @informalinc, @agoric, and @iqlusioninc with lots of help from @tendermint_team, @confio_tech, @jack_zampolin and many more. Special thanks especially to @cwgoes who led the project over the last ~2 years!
We're excited to see what others will build on IBC and what the connected internet of blockchains will enable. But this is just the beginning! Next up is evolving the Cosmos Hub to serve as an interchain anchor, a port city, if you will, in this emerging ecosystem.
If you're interested in working on IBC in Go and/or Rust, apply to work with us at http://interchain.berlin/  or https://informal.systems/team/  !
You can follow @buchmanster.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.