Chain Reaction #3 - Cosmos SDK IBC demo
Chain Reaction #3 - Cosmos SDK IBC demo
Orbital Communications is a bi-weekly Cosmos community update that gives token holders, validators, and all levels of stakeholders a look inside what’s being developed for the Cosmos Network.
The Cosmos Network is a secure and scalable blockchain ecosystem where thousands of decentralized applications interoperate to create the foundation for a new token economy.
Cosmos solves some of the hardest blockchain problems — scalability, usability and interoperability, allowing blockchain application developers to focus on business logic. The Cosmos SDK is a user-friendly, modular framework that allows developers to fully customize their dApp to best suit their needs, powered by Tendermint Core’s BFT Proof of Stake protocol.
Here are the key takeaways from the Chain Reaction #3: Cosmos SDK IBC demo where Jack Zampolin and Joon Yun discuss the recently released IBC demo.
Key Takeaways:
[1:36] Start of IBC demo which is currently present in pull request #172 in the gaia repository. Created two ibc chains with two different ports on a local machine to exchange tokens from one chain to another. Created light client of ibc0 on ibc1 and vice versa which are routes of trust and monitor each other. Routes of trust are headers which have information regarding the current state and need to be updated periodically.
[6:04] Created and queried a connection between the chains which is a handshake that allows creation of channels for transmitting application packets. Channel has an abstraction of what format of data is travelling on top of it. Each connection can have multiple channels but each channel is specific to each application protocol. Channels have proofs embedded within them, which ensures a specific state of the chain can be proven outside the chain.
[12:53] Sending of tokens from one chain to another. Send transaction is initiated from the account on sending chain which provides a block height. In the receiving chain, receive transaction is initiated in which timeout is specified as thousand plus the block height given by the send transaction. Account in the receiving chain is queried for its balance to confirm the balance has been credited to the account.
[17:01] Start of Q&A.
Q1. Who pays for the handshake transactions for a pairwise connection?
A:- A user only has to worry about the transactions involving send and receive. Validators or relayers, will be responsible for creating and maintaining the channels. Relayers will be paying for the transaction fees for creating and maintaining the channels, users will be paying the normal transaction fees associated with sending and receiving tokens on the chain.
Q2. What security assumptions are made? If a person uses IBC, whom does he trust?
A:- Security assumptions are based on validators and relayers behaviour. If 2/3rd validators are malicious, they can modify the state maliciously and submit it. But if the number of malicious validators is under 2/3rd of total, misbehaviour proof can be submitted when they equivocate a header.
Q3. What exactly is a relayer?
A:- An actor that can make HTTP requests required to create connection handshakes and for sending and receiving tokens. Eventually there will be two types of relayers. One type will be server side, it will be able to keep track of a large number of chains and will constantly send automatic transactions to and from the chains on behalf of a validator on a chain. This will have a lot of features like whitelisting, blacklisting etc. and will be targeted towards infrastructure users. Another type of relayer will be like a javascript relayer which lives in the browser like Metamask. It will handle the transactions seamlessly once trusted routes to other chains are specified for better end user experience.
Q4. Will the users be able to pick the relayers that fits them?
A:- Yes, users will be able to pick the relayers best suited for them just like how currently they are able to pick their validators.
Q5. In time frame wise, how soon will there be proper incentivization for the relayers?
A:- Relayer incentivization will be focussed on after a year. Now the focus will be more on increasing the number of production implementations of IBC and increasing the robustness of the implementation along with growing the adoption and monitoring the network usage.
Q6. It was mentioned that IBC connection wouldn’t need to be updated with every packet sent. What is meant by an update & when would they need to be made?
A:- Packet is queued inside the state which persists over the block. When the header is pushed into the client, it can be used to prove the validity of every packet before that. If we think about concepts like unbonding period and validator sets, these can change over time so it’s important to periodically update these routes of trust or headers within the counter party chains.
Q7. Who can develop application protocols? Do you need Tendermint’s permission to develop them?
A:- This is an open source project, all of the code is public. Everyone is more than welcome to look at the ICS specifications of what defines an application protocol. There are currently three implementation of application protocols. There are a number of implementations out there. If someone is looking to develop something, they don’t need any permission from anyone. IBC is a permissionless protocol, we encourage you to pick it up and give it a try.
Q8. Was anyone playing around with the IBC demo at the hackathon?
A:- There were more than a few projects that worked with IBC. There was a team which was utilizing IBC in order to communicate on the substrate chains instead of implementing IBC on cosmos-sdk. This highlights the flexibility of the IBC protocol and shows that it can be used on a different underlying chains.
Q9. What are the next steps to getting IBC ready for game of zones?
A:- At this time, we need to set up a few testnets internally and test creating testnets because the demos have been conducted locally and not much testing has been done where multiple independent parties are running them. There will be some refactoring of code and addition of features to the spec. Sometime over the next month we should start seeing IBC testnets.
Q10. Will it be difficult to implement IBC if you dont have prior knowledge about cosmos-sdk?
A:- Let’s say you’re a DBA and you’ve got a lot of experience with databases, digging into tendermint first and building an understanding from there would probably be best. If you’re a networking guy and understand handshakes very well, starting at the IBC layer might make the most sense and then you can dig into the underlying primitives around proofs and headers and start to grow your understanding from there. But this is a huge stack and some prior understanding of blockchains and distributed system databases will help you understand this better.
Q11. Do you see difficulties in synchronizing between chains that advance at different speeds?
A:- Within the protocol there’s the concept of timeouts ie. how long a given route of trust is good for and how long you have before the packet times out and you can’t receive it anymore. Adjusting the timeouts for the speed of the individual chains is how we deal with the protocol. When the packet is not delivered within the specified block height it will be reverted. The channel handshake connection is not affected by the different block synchronization period because they are perfectly working in sequence so there is no way that asynchronous communication can affect the handshake process.
Q12. Will the protocol be backwards compatible?
A:- Because the chains are independent actors, you can’t force any updates on any chain. We have thought about that, we don’t really have a concrete answer for it but we have embedded data within the protocol that will make it easier for us to automate some parts of it potentially. It is possible to run multiple versions of IBC on a single chain. So even if backwards compatibility breaks, previously compatible versions of IBC can communicate with each other.
Q13. Can existing Bitcoin and Ethereum blockchains be integrated to Cosmos?
A:- We’re talking about IBC being a layered connection protocol, it requires finality. So we are planning on having peg zones that assume the custodial risk of transferring assets between probabilistic finality and complete finality chains.
Watch the full video here: : https://www.youtube.com/watch?v=DeMhlEck3E0
