30 May 2019


- Andrew Zavgorodny, Brian Warner, Vasiliy Shapovalov, Zaki Manian, Chris Hibbert, Christopher Goes, Ethan Frey, Dean Tribble, Jack Zampolin, Meher Roy

ICSs up for review
IBC code

- Spec first approach for IBC. Therefore, most of the attention has been on spec development rather than coding until this point.

- This branch will contain the code for the IBC implementation: https://github.com/cosmos/cosmos-sdk/tree/joon/ics-implementation

- There will be a close to final version of the interfaces by the hackathon.

- Connection is now being written with initial handshake process.Packet format is not implemented.

- There is no point in trying to play with this code at this moment. Expect a lot of breaking changes.

- Working on core IBC logics with channels and connections. We will have a way to receive and relay packets.

Differences between IBC and ICMP

- ICMP is the InterChain Messaging Protocol from Polkadot: https://wiki.polkadot.network/en/latest/polkadot/learn/interchain/

- ICMP is a message passing system between parachains. All messages passed through the relay chain. There is a singular relay chain with large validator set. . A sending Parachain stores the messages that need to be sent to a different parachain. Sending Parachain header will commit to a set of outgoing messages. The Relay chain will canonicalise the block of a parachain. Parachain headers are notarised into the relay chain. Validator set of the receiving parachain will then scan for incoming messages for that particular parachain, and process those messages in a later block.

- The main difference: Polkadot assumes that the different parachains don't fail. Cosmos assumes that the different zones / blockchains fail. This basic difference translates into different designs for ICMP and IBC. In IBC, since its running on another chain. Each client is deciding whether to trust the other chain.

- Ethan Frey found response messages were missing in ICMP. IBC has response messages. Machine A simple instruction to Machine B to issue 5 pegged BTC. Machine B can refuse to carry out the instruction. Therefore, there needs to be a response message from Machine B to Machine A indicating that the instruction was not carried out. This kind of response message was not seen in ICMP. Hence, we suppose that ICMP error handling may not be as full as IBC (to be verified?).

- (Zaki) One difference between IBC and ICMP is that there is no introduction mechanism between the different parachains to start communicating with each other. This is unlike IBC where roots of trust need to be established between two chains to start message passing between the chains.

- Another difference is that ICMP does not require parachains to track each other's consensus, while IBC does. This imposes a higher verification cost for all of the participating chains with IBC. In the polkadot ecosystem, one can probably do away with some of the verification cost.

- IBC has a channel establishing mechanism that links a module on one chain to another module on a different chain. ICMP does not seem to have such a channel establishing mechanism.

- This led to a question: Should there be any capabilities difference for interchain logic between Cosmos and Polkadot? Is it the case that one will be able to implement any Polkadot cross-chain logic on Cosmos as well? Or will the Cosmos IBC model not admit some kinds of interactions that Polkadot can.

- According to Zaki, there should be some capabilities difference between the two models simply because Polkadot has a stronger interchain trust assumption. That stronger trust assumption should translate into some capabilities in Polkadot, that are harder to match in Cosmos. However, an example could not be presented immediately.

- In Polkadot, this kind of system might be imaginable: There is an escrow agent on some parachain. All of the other parachains can fully trust this escrow agent, and send over assets to this escrow agent. It might be that there is only a single escrow agent for a particular purpose in the Polkadot ecosystem. There is no point implementing another escrow agent with the same functionality on a different parachain.

- On the other hand, in Cosmos: A particular chain can implement an escrow agent. But not all other chains will trust that same escrow agent. Different chains can choose to trust a (not overlapping) subset of escrow agents. Before using a particular escrow agent, there is always an implicit (human) verification cost about the trustworthiness of that particular agent. Cosmos is more arm's-length than Polkadot. However, once a process on a chain trust a particular escrow agent on a different chain; then there can be assurances of the soundness of that escrow agent provided the chain remains secure. That kind of functionality can be built with IBC.

- Ask someone working on ICMP to appear on one of the bi-weekly IBC calls, so that this question can be discussed further.

- Also, it's possible that when a Parachain sends a message in Polkadot, it can assume that the state transition will take place on the other parachain. A Cosmos zone cannot carry the same assumption regarding the behavior of a different chain.

- There is an ongoing pull request in the Web3 foundation Wiki. This page will carry comparisons between the two protocols, but is incomplete: https://wiki.polkadot.network/en/latest/polkadot/learn/interchain/

Updates to Cosmos Whitepaper

- The Cosmos white paper is really outdated when it concerns IBC. It contains the notion that IBC is simply about the transfer of tokens between chains, whereas it has evolved to be a generalized protocol for message passing between BFT chains. Should the white paper be updated to account for the current IBC?

- There is a preference for keeping the white paper as an immutable artifact.

- There could be version 2  of Cosmos white paper. (No decisions were taken here on that account - this may or may not happen).

On whether short term communication isolation (with Ethereum) provides defensibility to Cosmos DeFi protocols

- DeFi is succeeding on Ethereum (eye-popping growth charts), and most of these protocols rely on the aggregation of assets at the base layer. Some functionality is built atop the asset aggregation - whether it might be lending, or stable coin.

- The main question here is how quickly we expect Ethereum IBC integration to come online. If the integration comes online the same time as integrations between Cosmos chains, say Terra and the Hub, there it is quite likely that the dominant Ethereum DeFi protocols will aggregate most of the Cosmos assets, and went over as the DeFi protocols for the Cosmos ecosystem. On the other hand, if there is a time lag between Tendermint chain IBC integration, and the IBC bridge to Ethereum; Cosmos DeFI protocols could have the chance to develop scale in Cosmos first; and then be able to compete with the Ethereum protocols.

- This question wasn't answered conclusively. It's not a well framed question, and the answer (probably) depends on return of different factors.

- (Christopher Goes) Connecting to Ethereum sooner, rather than later, is useful

- Squish labs (someone correct this name) has gotten a grant for one way peg, then two way peg. then full IBC bridge. It is likely that the first functionality to come is the ability for Ether to be transferred over to the Cosmos ecosystem. The second stage would be for Cosmos assets to be able to migrate over to the Ethereum ecosystem. The third stage would be full-blown IBC connection where processes running on Cosmos zones should be able to call out to smart contracts; and vice versa. This might be further out because it is complex to do full-blown IBC with PoW chains.

- One way token bridge between Ethereum and Cosmos might be available from the start.

- {Zaki} I expect Ethereum and Cosmos interop to emerge over the next 18 months - primarily driven by systems with custodians that are bonded and can be punished for misbehavior. These custodians would escrow assets and rehypothecate them somehow. Unlikely that logic interaction between the two ecosystems is the first thing to emerge.

- Cosmos/peggy is the project to follow.

- Finality chains could be easier to integrate with IBC, compared to PoW Ethereum. An example of finality chain is Algorand. (Even though, Algorand is not considered a great protocol because it is not asynchronously safe. Correct Zaki?)

- If Algorand chain wanted to integrate with IBC, they will need to write an IBC Handler.

- Cosmos and Polkadot being connected sooner than Cosmos-Ethereum on is quite likely.

- Polkadot + Cosmos vs Ethereum in DeFi land - that could be a story :).

Bitcoin Peg Zone

- Ethan asked whether there was any more information about a Bitcoin Peg Zone? Is Nomic the only effort in town?

- Cross chain collateralisation is the bigger blocker for Bitcoin Peg Zone than Schnorr signatures.

- There is a need to slash misbehaving custodians of the Bitcoin Peg Zone. For example, if a bunch of custodians signed a bitcoin transaction without receiving the corresponding IBC packet authorizing their signature, that set of custodians would need to be punished. It is best to punish these custodians on the Cosmos Hub. Hence, a cosmos hub module is required for interchain staking. Bitcoin Peg would be made easier by the existence of such a module. Flashing could also be done via governance.

- Summa, James Preswitch's project could also lead to Bitcoin arriving in the Cosmos ecosystem.

- Zaki: He made a proposal to the foundation. The way Summa works is is that it is less like moving an asset wholesale. It's more like an if then statement. If events occur on the bitcoin chain, and a proof is submitted to a different blockchain, something else can be done on the other chain. Biggest thing that can be done with his construct is ICOs like. It is not a bidirectional peg. There is no notion of vouchers.

- Dean Tribble: It's a lot closer to what we want in general than the above. According to him, there is some system of voucher issuance on both sides.

Interdependence between state dump restart chain upgrades and IBC

- The major upgrade path for the Cosmos Hub today is stop chain, dump the state and restart an upgraded chain from Genesis with block zero. How would IBC handle such an upgrade path?

- IBC should require continuity of chains on both sides. If there are breaking changes in the consensus model verification, or the chain itself asserts to hard fork, how would that work with IBC?

- In the moment, yes these two mechanisms are incompatible and don't work together. In IBC there is no way to distinguish between a regular state transition and a hard fork. There needs to be a fix to Tendermint so that only chain ID changes for hard fork. That will make it easy for IBC to track hard forks. There are multiple ways to solve the problem referenced.

- Have a new IBC packet that can keep the existing connection, but can just upgrade chain ID. The old validator set of the upgrading signs a header and the header has a field for the next chain ID. This header is sent over via IBC to the non-upgrading chain. The non-upgrading chain upgrades the connection to the new chain ID. Needs a mechanism for the upgraded chain to restart from height H+1, rather than height zero.

- There should be in the ICF connection spec a packet that defines an irregular state update that can go through if approved by all of the validators of a non-upgrading chain. If you have enough signatures from the known trusted set for one of these upgrades, it should be possible to update the corresponding connection.

- Another idea is that such upgrades can also be handled by code in the light client.

- Ethan: It would be nice to talk more deeply on this. This is essential to barrier to connect different chains in a production setting.

And……. That’s it for this session of the IBC bi-weekly call.

16 May 2019


Andrei, Christopher Goes, Brian Warner, V

asiliy Shapovalov, Timothy Chen, Joon, Mark Tynes, Dean , Sean, Ethan Frey, Asmodat, Liviu Easy2Stake, Gautier Marin, Mark Miller, Ismail Khoffi, Meher Roy

There is no video for this IBC call.

Main Topics

  1. DIF and identity discussion
  2. Call for IBC application semantics designers: https://github.com/cosmos/ics/issues?q=is%3Aissue+is%3Aopen+label%3Acategory-ibc-app
  3. Plan/agenda for June IBC event
  4. Discussion on warp jumps and root of trust registry for the Cosmos Internet of Blockchains
  5. How permissioned will connections be?
  6. Benefits of shared security
  7. Decentralized validators
  8. IBC Timeout strategy was part of the agenda, but was not covered.This is the Github issue corresponding to timeout strategy: https://github.com/cosmos/ics/issues/86

DIF and identity discussion

Call for IBC application semantics designers

Plan/agenda for June Cosmos events

IBC MVP in Golang will be available for the participants.

Hackathon participants will connect their chains to one another, provided that they are fine assuming that their partner chain will only send correct packets.

Discussion on warp jumps and root of trust registry for the Cosmos Internet of Blockchains

How permissioned will connections be?

Benefits of shared security

Decentralized validators

And……. That’s it for this session of the IBC bi-weekly call.