Konstellation’s Highlights from Cosmos Game of Zones (& IBC Protocol)!✨💫

The team has participated in Game of Zones to learn more about Cosmos Network’s IBC protocol and how we can apply it to The Konstellation Network. See below for some key learnings from our developers. Great learnings for our mainnet development! ✨😎

The Konstellation Network will utilize Cosmos IBC and shares learning below from Game of Zones!

Though the time in Game ofs Zones was brief due to delays and other priorities, we have received interesting insights and gained some knowledge that will help us during the development of Konstellation Network.

1. We have successfully connected with Cosmos community and are continuing to build our network of supporters. Took active approach in testnet QA.

2. Development team became more familiar with IBC protocol and Cosmos terminology, which will assist in next steps as we complete phase two of testnet.

3. Confirm development strategy including a solid understanding of what modules should be included in Konstellation Network.

4. Discovered a more effective approach for Cosmos-hub connection using a new CLI (command line interface), called a relayer. It creates paths between different chains, initiates lite clients of other networks and establishes connection. This will be useful for Konstellation networks needs to disseminate key information.

Below you can see a quick overview on the primitives that make up IBC. There are four major ones that we note below:

1. Clients

2. Connections

3. Channels

4. Packets

• In IBC, a “Client” is an instance of a lite client for another chain that is committed to state. This piece is fundamental to the function of IBC. All other primitives rely on clients to prove their data was included in the counterparty chain.
• Once we have a client to prove data, we create a “Connection”. This requires 4 transactions, 2 on each chain. The clients are updated throughout to prove the newly committed state on both chains.
• Once this authorization has been completed, we create a “Channel”. This contains the specifics of which module in the chain to send the data (the “Port”) as well as ordering semantics and application protocol versioning.

The first three primitives make up a persistent link between chains that can be endlessly reused to send “Packets” which hold application data. But, the clients on each chain need to be updated at least once every un-bonding period (approximately ~3 weeks), or we can no longer trust it.

• Sending a “Packet” requires at least two transactions, one on the sending chain and one on the receiving chain. The IBC spec also contains ack (“acknowledgement” confirming receipt and processing) and timeout packets.
• During the sending of a packet, the receiving client gets updated so it can prove that the sending chain actually made the required state transitions, so links that are active will be frequently updated.

More updates to come on testnet phase 2 and next steps for Mainnet development!

To keep up with Konstellation please follow us on:

Twitter | Facebook | LinkedIn | Telegram (Official) | Telegram (Announcements)

Reddit | Medium | Discord | Kakao | or visit us on https://konstellation.tech