IBC Ecosystem notes brought lovingly by Chorus One
11 July 2019
Participants
- Christopher Goes, Zaki, Juwoon Yun, Andrew Zavgorodny, Chris Hibbert, Vit Parkhomenko, Jack Zampolin, Dean Tribble, Justin, Justin Drake, Gautier Marin, Ethan Frey
Administrative notes
- Decisions on ordering, acknowledgements, multihop support
- ICS 5 (Port Allocation) merged, reviews still welcome
- Cosmos SDK (Go) implementation status updates
Intros
- Vit: With the Everstake team. Just curious about what this is all about.
- Justin: I am with Althea. Working on starting a zone. Working with IBC.
- Justin Drake: Part of the Ethereum foundation. Working on Ethereum 2.0. Looking for opportunity to standardize with IBC. Also looking to learn the latest and greatest techniques for light clients.
- Hammad Tariq: Works at Binance. Binance evolution proposal for Binance. I have been in the email working group for a while.
General Information
- Zaki has a web3 slot to talk about Cosmos/Polkadot interoperability
- We are making good progress on IBC standardization towards IBC 1.0 which is a milestone
- IBC 1.0 will be feature complete. It will be proposed for deployment on the cosmos Hub.
- Few features are not slated for 1.0 will be there in 1.1, 1.5. One of these features is multi hop routing.
- ICS5 is the Port allocation system. Ports are places to bind modules to. Modules bind to ports. This change has been merged.
- Updates to channel ordering and acknowledgement in pull request 144.
- 2,3,4 and 23 ready for review. 2 also has courier client functions.
Specs for application level protocols
- Zaki: What should a specification for an application level protocol should look like? What should be it structure?
- It should contain the formats of the involved packets. Different kind of IBC packets that would constitute a different application level protocol.
- Include some specification of state machine logic to have the same semantics associated with packets.
- Example of shared security was taken:
- How should validator updates be relayed through IBC.
- How slashing instructions should be relayed via IBC.
- Should they write an application spec for token transfers? Yes, would be great as an example for others writing application specs.
Joon said a few things that I did not understand. If someone could input those, I would appreciate it.
Packet encodings
- Exact packet encodings. Have we defined wire encodings yet? Wire encodings for packet and wire encodings for data can be different.
- Dean: What encoding is the current prototype using? Answer: Amino codec.
- Zampolin: Probably don't want to use Amino codec. Ismail has made Amino fully Proto compatible over the wire. Let's make the encoding Proto.
- IBC packet data does not need to be human readable. It needs to be compact.
- Early in development, extreme verbose protocol is found useful. Afterwords, switch to a binary.
- Is there version encoding in IBC packets? The packets don't have version number. If use Proto3, then version info can be put in.
- Initial negotiation for a protocol should have a version number.
- There was a debate on whether version numbers should be present in connection origination or in all of the packets. (What was the decision here?)
- Add Proto3 schema files to all of the ICS specs.
- There is no a type field for every datagram. There is no type based routing - routing is only module based. Module can choose to further multiplex multiple types.
NFTs
- IBC format for NFTs. Billy working on NFT-IBC spec. NFT will follow after the token transfer.
- Current design: NFT will not carry metadata with them. Only have identity and chain ID.
- Right now the way it works in Ethereum, there is one field that is very short that can be resolved to get metadata. Billy is wondering whether to continue with that approach, or have the metadata on chain. The ability to update the metadata should live with the zone, rather than transfer over IBC. When you are transferring NFTs over IBC, you would only transfer the denomination - you know where the origin chain is, and you can go a query that chain for the metadata.
- Zaki: Being able to have a white list of multiple zones that are allowed to mutate the metadata is going to be valuable. Instead of saying, just transfer the ID, you can transfer the metadata along with a white list of zones that have the ability to change the metadata. Hub can enforce that only metadata updates from white listed chains are persistent.
- A use case for the above: Breeding crypto kitties example. If the metadata can only be changed by issuing chain, then need to return the kitty every time to make a change to it. A white list would allow other zones to also breed crypto kitties.
- NFT spaces being driven by gaming. Financial derivative NFTs should have a different spec. The same spec may not suit gaming and financial NFTs.
- Question 1 from Meher: How is the whitelist made In the case of NFT staking derivatives where the issuer is the protocol?
- Question 2 from Meher: If multiple genes can mutate the metadata of an NFT, and many of these mutations happen for the same NFT on different chains, won’t the trustworthiness of the final state of the NFT be dependent on these security of all of these chains? and this dependence would imply that it security is very low?
- Zaki: Small number of zones that can make changes to the NFT metadata. this is like a contract between Chains, where the issuing chain issues the right to mutate metadata to a few number of chains that are near it in the IBC graph. Issuing zone can effectively debase a NFT tokens, thus always keeping the power to recover from bad mutations.
- The issuing chain is pretty special and lots of things have to go back to that.
- There are also around ideas such that: Original issuance of NFTs can be someone other zone, but the hub ensures some kind of security properties of the NFTs.
- These designs leading to a world where there is an authoritative source, and other somewhat less authoritative sources. As a user you can figure out the relationship, and refer back to the authoritative Zone when needed. There may be some advantages of working with the less authoritative version, as it might have better transaction properties or better connectivity.
- Decision: Sum all this up on the NFT ICS issue.
IBC 1.0 spec review
- Dean asked about dates and review of 1.0 timing He has the challenge reading the deltas. End to end 1.0 spec review. That can be a web thing. It would help people align with what is actually there vis a vis what has been discussed in the past. It would be a precursor to any security review.
- That is a fantastic idea. 3-4 sessions over a week or two. Two or three ICS's per session. Invite a lot of participants from outside to watch.
- For dates, Chris: 3 weeks from now is the time to start this.
- When will 1.0 spec is done? Can start the in-depth review in three weeks. Last week of July or first week of August would be good for the first session.
- Pre-1.0 review. Week of July 29. v1.0-rc0 spec and v1.0-rc0 implementation review.
- It is also his plan to convert his specs on IBC 1.0 in paper format as a snapshot of the state of the protocol.
Facebook Libra plus IBC
- Does anyone know about Facebooks' plan for Libra IBC integration? They are thinking about IBC, because it is mentioned in a couple of places. Zaki has been talking to them about things unrelated to IBC.
- Their consensus architecture is very similar to tendermint. They have a thing that is almost like ABCI - where the execution VM can be swapped out. Integrate the Cosmos SDK with Facebook's consensus codebase.
- Implementing IBC on top of Libra looks very doable. It seems to be quite chaotic over there.
- It looks like decentralization is a new feeling for Facebook. (Chris Hibbert) But many large companies are multiple fiefdoms that communicate loosely.
- We are interested because from a cursory look at the docs, it looks like they have interesting representation of resources. Agoric ERTP layer would be a great way to manage trades among resources. Cross resource trading.
- Their security model is msg.sender security. So they have the same set of problems that Agoric would otherwise like to solve.
- Move is interesting but it seems really early. The idea of sticking Cosmos SDK on top of Libra is therefore interesting.
- ABCI-Hotstuff would be great, but it’s more upto Facebook than AIB to do that.
- They are waiting for some charter to be signed, before engaging with communities like us.
- The particular form of permission-lessness existing in IBC could be very attractive to Facebook, if we could explain it well to them.
Agoric + IBC
- Section went above my head, so the notes are incoherent. Someone, please add here and make it intelligible.
- The relayer has been coming up a lot in the last week. New repo for the relayer.
- Engineering planning inside Agoric - when messages need to be transferred from a chain to an individual machine, IBC is it required, and their relayers are needed. Signing messages to inject into the blockchain from Individual machines is equivalent to a transaction. Relayer plus Agoric execution engine achieve something (what?).
- Message going from chain to single machine need a party.that looks like a relayer. The other side looks like submitting a transaction.
- Solo machine will be running a single chain, correct?
- Solo machine is not generating blocks. It is just a source of authority for signed messages.
- Solo to chain is regular swing set module.
- Industrial relayer - like plans for a lot of chains, and sending messages across.
- Something about a SwingSet presentation.
- Doing a JS implementation in parallel with Jordan. Relayer spec as implementation ready as possible.
- A lot of these relayer implementation in different languages.
- (Whatever Jack said went over my head - Agoric and IBC concepts merged together)
On Executable specifications
- Justin: Is there an executable spec? What is the definition of an executable spec? There is pseudo-code in the IBC specification. The pseudocode cannot be executed. It will not prove any properties. What is Justin exactly looking for?
- Justin: looking to gauge the complexity of the spec. one of the advantages of an executable spec is that one can write unit tests for it. If there are two executable specs, then they can be compliance testing across the two specifications.
- Ethereum: The executable specs are in separate languages - One spec in Python and other in go. They speced out a state machine, and then they do differential fuzzing.
- IBC will do differential fuzzing were different reference implementations rather than two different executable specs.
- There is an in progress reference implementation in go. It should be possible to do differential fuzzing with that reference implementation.
- We could also have the actual specs be executable. Split up across a sequence of PRs.
- Is there a plan for automated fuzzing already for the implementation already? We plan to do it but there are no more specifics.
- (Discussion on testing via differential fuzzing, a tool called ClusterFuzz was mentioned)
And……. That’s it for this session of the IBC bi-weekly call.
27 June 2019
Participants
- Andrew Zavgorodny, Leonard Lys, Dean Tribble, Boris Petroc, Liviu Easy2Stake, Alistair, Mark, Chris Hibbert, Marek, Zaki Manian, Mark Miller,Boris Petrov, Zaki Manian, Meher Roy, Emmanuel Lange, Marouaneh
Recording
The call is being recorded by Mark in Quicktime. Recording link:
(I missed the first five minutes of the call; someone please populate the notes for the first five minutes)
Administrative notes
Question from Andrew Zavgorodny (Dgaming)
Is it possible to have a system where an IBC packet can trigger a change in the receiving chain and have some guarantees over the resulting state transition?
Idea: might be useful to send tokens to other chain, prove that they have been frozen on source chain, tell receiving chain to take some action on those tokens?
- Chris Goes: The IBC packet can be treated by the receiving chain anyway it wants. Users can inspect the receiving chain and figure out what would happen if a certain packet is received.
- It might make sense to have different specifications for the different actions. There could be a multi-message action specification. Multi-message IBC transactions can be made in a similar way to the transaction and message design used by the Cosmos Hub.
- Users will be able to verify if a receiving chain subscribes to the particular packet specification to be sure that receiving chain will process the packet in a particular way. Packet specifications due to my how the IBC raw data is interpreted to form higher-level objects like tokens and NFTs.
- AIB will make packet specifications for common objects like token transfers. IBC is ready enough for other people to write packet specifications for other applications.
Introductions
There were introductions from people who joined the call for the first time
- Mark from Shapeshift - building a decentralized Oracle as part of one of the features of the ShapeShift zone. There will be a data provider for Dapps, and will produce data for free for other decentralized applications in the Cosmos ecosystem.
- Leonard Lys is a Ph
- D researcher in interoperability. He wants to know more about IBC. Specifications, formal proof of the protocol areas of interest for him. He is working with IOV company.
- Marek is CTO of a mobile first cryptocurrency. We have a BFT system but not based on Tendermint. Big interest on IBC because the stable coin is backed by multiple assets. The more assets they can bridge, the more assets they can include in the reserve.
- Ray from Oasis Labs. At Oasis lab, they are building privacy preserving smart contracts that are compatible with the EVM. They have a new web assembly based smart contract contracting experience. They are giving high-level primitives for smart contract development - for privacy preserving identity, voting in a privacy preserving way etc. Excited to bring this technology to any number of use cases that might want that privacy preserving smart contracts.
- Alistair from the Web3 foundation. He is working on Polkadot, invited by Asmodat to join the call. He is working on ICMP, and also working on bridges.
- Marouaneh and Emmanuel Lange - interested in different functionalities and understanding how IBC works. We are partners associates and other projects. We are going through the whole code and it's really interesting.
DGaming IBC Hackatom entry - request for details
- What did they do in the Hackatom project?
- Relayer code: https://github.com/dgamingfoundation/hackatom-relayer
- Zone code: https://github.com/dgamingfoundation/hackatom-zone
- They were building a marketplace for NFTs. There was an application that could let users mint NFTs. Then NFTs could be moved to the hub, and sold there in a marketplace.
- They wrote a simple relayer, that looks for new IBC packets inside the application zone; reads packets from the zone. Then un-marshall the IBC packet into an NFT on receiving hub. Then send a transaction to the marketplace. Transaction was received, and then the NFT could be bought on the marketplace.
- While working on the project, they faced several issues with the code. Most of these issues can be fixed pretty easily.
- Chris Goes: Do not use the IBC code that exist currently in production.
- What's going to be the status of IBC for the Seoul Hackatom? Joon is polishing the existing implementation. Not quite reflect the final interface that v1 of IBC will have - those will be added later. Polished version will be available for the Seoul Hackatom.
Questions and information from Marouaneh / Emmanuel Lange, Mark (Shapeshift)
- They’re building a zone.
- What are the features of the zone you're planning to have?
- Ability to control other wallets in other zones or on cosmos Hub from a zone. Basically delegated account control. Spending a lot of time on Github trying to figure out how to implement that. Started only last week. They are more familiar with Solidity for building decentralized applications.
- Emmanuel - we are also interested in non-value message like voting or delegating. They are interested to transmit voting or delegating orders to the cosmos hub from a different zone. Is this kind of functionality possible?
- Chris Goes: From the perspective of the IBC protocol, the answer is yes. The IBC protocol is as generic as message calls on Ethereum. Receiving contract can choose to do what it wants with the receiving packet. The cosmos hub will need some code to process the receiving voting or delegating orders. But it's up to the validators to update the code of the hub, to enable such functionality.
- In the beginning, AIB is going to write code that enables simple token transfers.
- Mark from Shapeshift: They want to be able to provide oracle data as a subscription. Will IBC allow some kind of subscription functionality for data?
- Shapeshift will have its own zone.
- The query of data can originate from a different other zone. This zone can query the data, and verify via Merkle Proofs.
- In the future, there will be broadcast channels that will be very useful for a case like yours.
- Could Ethereum smart contracts reach out via IBC to Shapeshift zones, and query some data?
- If the contract itself is verifying the Merkle proof, that's a bit expensive. You might instead want to have the bridge zone do some of the processing in order to offset gas course on the Ethereum chain.
- IBC doesn’t itself specify any gas semantics on the receiving and sending chains.
- Chris does not know when broadcast channels will be implemented. We can add them in v2.
- A shim can be implemented with proof verifications logic.
- Dapp will work isolated on their own zone. Other chain asked for the data, and that's why they were asking the question. This is not a high priority functionality for the Shapeshift zone.
Discussion with Alastair from ICMP / Polkadot
- Zaki - what do you think of the channel abstraction? I'm curious to see if there is any dissent around having module to module message channels. It is the most opinionated part of IBC.
- Alistair thinks it is sensible.
- Channels vs connections - connections are single hop, whereas channels are end to end.
- Channels would be created in a module. Channels would be end to end, and their mechanisms to ensure the opening and closing of connections in service of the channel’s end to end functionality. Packets would be sent by one module, routing logic would be automated, and received by the other side.
- Sending and Receiving modules will need to think about the security of the intermediary chains.
- Chris Goes: I do not expect really complex topologies like the Internet protocol to emerge, because security is such an important consideration here. It is one of the reasons why IBC is expected not to be packet-switched.
- What do you think of IBC Alistair? Still reading the spec. It is very different from ICMP.
- In ICMP, there is a similar desire to have channels to communicate. They want to have the ability to communicate between the same module on different parachains as well.
- To Alastair from Meher: What you think of the main differences between ICMP and IBC.
- In that project we can assume more trust between two chains, then we can assume in Cosmos. The basic communication protocol can have more guarantees.
- Ordering needs to be done on a higher level for IBC. And ICMP, ordering happens for free. ICMP: There is also going to be some sort of synchrony bound guaranteeing messages are going to arrive if the other para-chain keeps going, it has got to receive the messages. The relay chain can impose such guarantees. The relay chain can force the receiving parachain to act on a certain set of messages that were sent by other chains.
- The other main differences is trust. In ICMP, parachains have the same security. There is no need to keep track of validator sets in the same way. We are also going to have this architecture to share code. IBC Application might need complications to deal with trust between chains.
- In version 2 of the multi-hop routing, there can be chains verifying what the other chains did. That would be similar to Polkadot.
- Zaki: One of the isomorphisms says - I expect you should be able to implement a chain on Polkadot that can send and receive IBC messages.
- There are plans already to work out how to build a bridge between Cosmos and Polkadot. It will be most efficient to have the cosmos side verify the relay chain, because the relay chain already has information about the parachains.
- Is there a place to read about ICMP?
- Page on differences between IBC / ICMP would be helpful.
- One of the interesting differences is around the synchrony assumption in ICMP. The para-chain can force a receiving chain to process a packet before a certain time. Do you have an example of an application that would use functionality like that?
- The message itself is going to be received in Polkadot. In your IBC protocol you do not need an acknowledgment that the message was received. Only more complicated acknowledgments will be needed in Polkadot. Only an application level ack is needed; protocol level ack is not needed.
- Consensus on all parachains is merged on a block by clock level.
- Shared security on Cosmos and/or sortition security on Cosmos can be used to replicate some of these features Polkadot has out of the box.
- Example: If the Ethereum Peg Zone (EPZ) shared the validator set with the Hub, then the Hub can send a packet to the EPZ, and ask for it to be processed. If the EPZ does not process the packet, the hub can slash the validator set. This is one way in which the Cosmos can start to have Polka like characteristics. Ofcourse, the Hub or EPZ don’t have control over Ethereum miners, so the whole loop end to end with state transition on Ethereum cannot be guaranteed.
- So it almost feels like one of the value propositions of shared security/interchain collateralization is the ability for one block chain to have some guarantees about the behavior of another chain with which it sharing security. Any application that needs guarantees like that probably needs like shared security as a lower level primitive. In Polkadot, you get that out of the box but in cosmos we will have to build it with these bilateral agreements between communities and things like that.
- You can have partial guarantees as well if the validator sets are partially shared. The downside there might be griefing factor if its partial shared security. Example: Part of the validator set of EPZ from the Hub. Hub sends a packet and will slash if not processed by EPZ. The validators of EPZ, that are distinct from those of the Hub, can force the packet to not get processed and grief the other validators of the EPZ.
- Also possible: Collateral is on Cosmos Hub, but validators are validating another chain. Collateral originates from the other chain, but is bonded on the Hub. Example: Neutrinos are the Kava zone internal coin. You can stake neutrinos on the hub and use that neutrinos take to secure the Kava chain. So essentially we can think of this as a sovereign chain with this big application. We can split this big application across two chains - the Hub and the other chain. Collateral and staking logic lies on the Hub, whereas the other parts of the application lie on the other chain.
Conclusion
- Perhaps by the next call, we will have enough to have most of the API changes as a result of the session with Agoric implemented in the MVP. Insecure end to end applications will be prototype able. Certainly they should be specified by the next call.
- It would make sense for Joon to polish this version, and make it easy for Seoul. Unordered channels will not be ready for Seoul.
- There will be prototype soon that people can start playing with!
And……. That’s it for this session of the IBC bi-weekly call.
30 May 2019
Participants
- Andrew Zavgorodny, Brian Warner, Vasiliy Shapovalov, Zaki Manian, Chris Hibbert, Christopher Goes, Ethan Frey, Dean Tribble, Jack Zampolin, Meher Roy
ICSs up for review
- ICS#4 (where is the link to this? Couldn’t find it)
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
Participants
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
- DIF and identity discussion
- Call for IBC application semantics designers: https://github.com/cosmos/ics/issues?q=is%3Aissue+is%3Aopen+label%3Acategory-ibc-app
- Plan/agenda for June IBC event
- 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
- 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
- This theme was covered only cursorily, because the person that put the topic in the agenda item was not present in the call
- Vasiliy explained the concept behind the DIF - Decentralised Identity Foundation. Decentralized Identity Foundation is a foundation and project with involvement from Microsoft and Sovrin (related to Evernym). The main idea is that identities are stored encrypted on a platform like IPFS. User can retrieve identity information, and then provide the data to other parties: need to know basis. There is the ability to have zero knowledge proofs to prove some small aspect of user identity like age, without revealing other parts of the identity information.
- Vasiliy is working on some kind of gaming integration with DIF that allows gamers to prove parts of their identity.
- Ethan Frey explain some aspect of the work being done by IOV. It was hard to understand what they were doing due to poor call quality.
- One idea specifically related to the Cosmos Internet of Chains, is that there could be some chain on which users store their identity related data. Then they able to create Identity claims using merkle proofs or zero knowledge proofs proving some aspect of their identity. The Identity proofs can then be sent over IBC, and a different chain can accept those proofs for a user's identity. Some application, or capability, on the destination chain can be opened up once a proof of user identity is received via IBC.
Call for IBC application semantics designers
- This section of the conversation was led mostly by Christopher Goes
- IBC most useful as a protocol if there are many different kinds of packet semantic standards for different applications.
- One can compare IBC packets to HTTPS packets or JSON packets for application requests. Blockchains need to agree on semantics and encodings of the packets sent to each other. For example, Cosmos and IRIS have to agree on a way to encode (at source) and decode (at destination) token denominations for token transfer in order to preserve token invariants. The two blockchains can only ascribe a certain meaning ( at the application layer) to the packets received if there’s some kind of agreement on the semantics of data contained inside the IBC packets.
- This kind of packet specification will need to exist for different application layer use cases of IBC. For example, if someone wants to build a new shared security model; a new packet semantic will need to be created that allows a chain like the Cosmos Hub to interpret receive packets as commands to slash a particular validated by a certain amount.
- Christopher Goes and Tendermint team want to open up the ICS repository as a centralized place where people can create packet semantics and packet encodings for IBC packets for different applications.
- This is where issues pertaining to package semantics should be created: https://github.com/cosmos/ics/issues?q=is%3Aissue+is%3Aopen+label%3Acategory-ibc-app
- IBC guarantees are well reasoned about even today. If you have an idea or want to start specifying a new packet semantic, IBC is ready enough for your input. There is a tag called IBC App in which you can start specifying packet semantics.
- AIB team will focus on building packet data structure and packet semantics for fungible tokens and non fungible tokens. All other applications are open for leadership from the wider community.
Plan/agenda for June Cosmos events
- Interchain Conversations, on 13/14 June is invite only.
- Hackathon will be public: 15/16 June.
- For the hackathon, we anticipate working implementation of IBC - channels, packets are implemented. Packets are implicitly assumed to be trusted. Verified algorithm is assumed to always return true.
- It is the packet verification algorithm that is still pending implementation.
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.
- Christopher recommended that Hackathon participants focus on the application, and application level semantics.
Discussion on warp jumps and root of trust registry for the Cosmos Internet of Blockchains
- This was a follow-up discussion to the issue created by Asmodat: https://github.com/cosmos/ics/issues/92. For details on this section, just read the description from Asmodat - it is pretty comprehensive!
- The key problem statement here is that multi-hop asset sends, where coins originate from one chain, and are then routed through two or more chains, and then reach a destination chain; end up trusting all of the intermediary chains. Failure of any of these intermediary chains could result in loss of funds for the participants of the original/recipient chain.
- Asmodat’s solution is the proposal to create a “root of trust registry”. This registry can be maintained on a very high security block chain like the Cosmos Hub. The registry contains data regarding the name, validator set, validity time etc. of a majority of chains in the Cosmos ecosystem. This data is the “root of trust” that will enable two remote chains to directly set up an IBC connection with each other for a short period of time. If two chains want to pair up with each other, they can receive root of trust data from the registry, and pair up to transfer assets between each other very quickly. A quick pair up of disparate chains using the root of trust registry is called a warp jump.
- Christopher Goes feedback was that it was going to be quite easy to set up IBC connections by exchanging roots of trust between chains. There was general agreement that the idea of a registry chain for roots of trust is a sound idea.
- The registry does not need to be implemented at the IBC core protocol level. This is some application level functionality, that allows the creation of a registry, which can be read by blockchains using IBC and set up IBC connections between each other.
How permissioned will connections be?
- The conversation around warp jumps led to a slightly different topic on how permissioned will IBC connections be?
- Meher’s question: was
- Whether the Cosmos Hub will be open to the creation of IBC connections with zones that have very little economic security, like sovereign zones backed by a token worth $50 million.The risk of connecting to a small zone is that they could be a compromise on the small zone, leading to manual repair efforts on the Cosmos Hub.
- The second question builds on the first. Assuming that it is hard for small zones to open up IBC connections with the hub; is there a value proposition for the small zone to borrow security from the hub via shared security; and therefore be positioned better to open up an IBC connection with the hub?
- The general answer from Christopher Goes (and Joon) was that IBC connections will be permission-less, and that the Hub is incentivized to open up connections with small zones as well.
- There is a certain risk in opening up many small zone connections, but it is up to the atoms holders not to send over a lot of assets to the small zone; and thereby contain the risk of Byzantine failures on the small zone.
- That said, there is enormous value proposition in the development of value rate limiting technology between Cosmos chains. Such technology would allow the hub to connect to a small zone via IBC but only allow a certain amount of atom value to go to that destination small zone per unit of time. Such a rate limiting can be used by the hub to reduce counterparty risk.
- Therefore, the value proposition of shared security is NOT to allow small zones to open up IBC connections with the Hub. This led to a conversation on the value proposition of shared security.
Benefits of shared security
- Christopher Goes said there are some ideas around shared security but no definitive protocol.
- One of the benefits of shared security is an easier transition from a test net phase to a main net phase.It is often difficult for a new project to get a team of validators to run the test networks and their early main networks.
- Shared security will be very useful in these early network applications.
- Ultimately, there will be the capability to transition from a “fully outsourced security” chain to a “hybrid security chain” to a “sovereign chain”. A hybrid security chain is one in which security is sourced both from the token holders of the chain, as well as the validator set of Cosmos Hub.This concept of transitioning between security models is called the phased sovereignty approach.
- Joon has a proposal on how hybrid security chains can be made (where?). Refer to that issue to understand better how phased sovereignty could work.
Decentralized validators
- Meher raised the concept of a decentralized validator, to ask whether such mechanisms would be admissible by the Cosmos Hub. (Chorus’ perception was that such mechanisms could end up weakening the security guarantees of the Cosmos Hub).
- The idea develops on the concept of delegated account control covered in the issue: https://github.com/cosmos/ics/issues/44
- Delegated account control can allow the validator set of a Cosmos zone to control an account key on the Cosmos Hub. This paves the path for a putative decentralized Chorus Zone to control the account key of the Chorus validator on the cosmos hub. Delegators would need to send their atoms to that particular account in order to start earning interest. Chorus Zone is able to use custody atoms as self bond, and delegate to a particular operator key. Operator key can itself be sharded over, and assigned to multiple infrastructure providers. Infrastructure providers sign on Cosmos Hub blocks, and their signatures are aggregated ( using some cryptographic signature aggregation scheme) to count as a decentralized validator signature on the Cosmos Hub. In principle, such a mechanism would allow the creation of a “decentralized validator”. (Some people on the call generally agreed that a mechanism like this is possible).
- The question is whether decentralized validators would weaken the security model of the Cosmos Hub because atoms are now dependent on the security of a smaller, potentially much weaker, zone.
- Christpher Goes’ reply was that this mechanism should not be seen as a weakening of the Cosmos Hub security model, as it is up to the delegator community not to entrust a lot of atoms to a particular zone. He wouldn’t favor some centralized mechanism that would prevent the creation of such decentralized validators. Freedom to send atoms over to different zones in a censorship resistant manner, is very much an ideal to strive for.
And……. That’s it for this session of the IBC bi-weekly call.