Klayr Interoperability
On this page, we discuss the Klayr interoperability protocol. Specifically, you’ll learn about the following:
-
How Klayr facilitates communication across chains?
-
General terminology related to interoperability across chains.
-
What is a mainchain?
-
What is a sidechain?
Overview
A comprehensive playlist of all the videos presenting the entire Klayr Interoperability solution can be found on the Klayr youtube channel. |
The Klayr interoperability solution allows blockchain to blockchain communication by using the paradigm of cross-chain certification.
Cross-chain certificates are a scalable and efficient solution that facilitates the transfer of all kinds of information between chains.
Basically, cross-chain certification means that information from one chain is authenticated and included in another chain utilizing a signed object called a certificate. This information is transmitted across chains by issuing a Cross-Chain Update transaction, aka CCU.
The CCU includes the certificate and the cross-chain messages coming from the sending chain. Cross-chain messages contain cross-chain commands which are executed on the receiving chain. This can mutate the state of the receiving chain in response to state changes that occurred on the sending chain.
![cc transfer example](../../_images/understand-blockchain/interop/cc-transfer-example.png)
In the diagram above, Alice performs a cross-chain token transfer from her account on the sending chain to Bob’s account on the receiving chain.
To achieve this, she sends a cross-chain token transfer transaction, t
, on the sending chain.
When this transaction is included, her account on the sending chain is debited.
Simultaneously, a corresponding cross-chain token transfer message, m
, containing all the relevant information is emitted.
This message is included in a cross-chain update transaction (CCU), which is sent to the receiving chain.
When the transaction is included, Bob’s account is credited.
Cross-chain messages are, however, not limited to token transfers.
Similar to transactions, cross-chain messages have a params
property.
Therefore, when building a Klayr application with the Klayr SDK, you can create custom cross-chain messages by defining the content of the params
property as needed.
For example, you could create a custom cross-chain message that contains some authenticated information from an oracle chain in its params
property.
Terminology summary
- Cross-chain transaction (CCT)
-
Transaction generating one or more cross-chain messages.
- Cross-chain message (CCM)
-
An envelope object for a cross-chain command.
- Cross-chain update (CCU)
-
A CCU, aka "Cross-chain update transaction" is a special transaction containing cross-chain messages, certified by validators. It is used to transfer CCMs from one chain to another.
- Command[2]
-
Trigger of a state transition in the same chain.
- Cross-chain command (CCC)
-
Trigger of a state transition coming from another chain.
- Certificates
-
Certificates contain information from finalized block headers that are signed by a large portion of validators from a certain chain, and thus authenticate a finalized state of that chain. They are the fundamental components of the cross-chain certification paradigm for the Klayr ecosystem.
Cross-chain network topology
The cross-chain network topology is organized as a star topology and describes arrangements of blockchains within the Klayr ecosystem.[3]
![cross chain topology](../../_images/understand-blockchain/interop/cross-chain-topology.png)
As shown by the image above, a Klayr blockchain can become interoperable with any other blockchain in the Klayr ecosystem including the Klayr Mainchain, simply by registering itself on the mainchain. All communication to other sidechains is routed through the mainchain.
What is the maximum number of connected sidechains to the Klayr Mainchain?
The maximum number of sidechains that can be registered in the Klayr ecosystem is only capped by the maximum number of CCU transactions that the Klayr Mainchain can process. In this sense, it is practically unlimited. |
Mainchain & sidechains
As explained in section Cross-chain network topology above, the Klayr blockchain network is structured in two types of network participants:
-
The Klayr Mainchain: Follows the Klayr Mainchain protocol and cannot be modified by a blockchain application developer, and
-
Sidechains: Blockchains built with the Klayr SDK. To become part of the Klayr blockchain ecosystem, a sidechain needs to include the Klayr Interoperability module. All additional parts of the sidechain protocol are defined by the sidechain developer.
In the Klayr ecosystem, sidechains are connected to each other via the mainchain. Because sidechains communicate through the mainchain with other sidechains, they only need to maintain one connection to the mainchain, which will significantly reduce both the complexity and the point-of-failure.
To become a sidechain in the Klayr ecosystem, a blockchain needs to perform the following two simple steps:
-
Register on the mainchain.
-
Register the mainchain on the sidechain.
The mainchain forwards all cross-chain communication happening between registered sidechains in the network.
The Role of the KLY Token
The token used on the mainchain, KLY, has a special role in the ecosystem:
KLY is used to pay transaction fees on the mainchain, where all CCUs from the sidechains have to be posted. Additionally, all transaction fees in sidechains are paid in KLY by default (however, it is possible to configure a sidechain token for the transaction fees).
The KLY token is the only token that can be transferred to every chain within the Klayr ecosystem. As the KLY token is listed on several exchanges and there are fiat on-ramps available, it will in most cases be the initial token that a user acquires within the Klayr ecosystem. Once a user possesses some KLY tokens, they can exchange them for other sidechain tokens, e.g., on a decentralized exchange (DEX) sidechain.
Cross-chain communication
Due to the topology of the network, there are two different ways for cross-chain communication:
- Sidechain-to-Mainchain (& vice versa)
-
Involves the creation of one CCU on the sending chain, that is posted to the receiving chain.
- Sidechain-to-Sidechain
-
Involves the creation of two CCUs:
-
CCU from sending chain to mainchain
-
CCU from mainchain to receiving chain
-
![s2s](../../_images/understand-blockchain/interop/s2s.png)
-
On
sidechain X
, three transactions are included, where each one emits one cross-chain message, denoted byCCM1
,CCM2
, andCCM3
. -
All three cross-chain messages are delivered in one cross-chain update transaction,
CCU1
, to the mainchain, whereCCM1
andCCM3
are processed, but notCCM2
. -
Later on,
CCM2
is delivered tosidechain Y
by a cross-chain update transaction,CCU2
, from the mainchain tosidechain Y
. -
This cross-chain update transaction contains an additional cross-chain message,
CCM4
, emitted by the transactionCCT4
included in the mainchain.
Chain Identifiers
A unique identifier for a specific chain.
Chain IDs serve two purposes:
-
They are prepended to the input of the signing function of every transaction, block, or message of the chain to avoid transaction replays between different chains in the ecosystem.
-
They uniquely identify a chain in the Klayr ecosystem.
In the Interoperability module, it serves a similar purpose for chains as addresses do for user accounts, as it is used to identify the chain account in the Interoperability module store.
Furthermore, the chain ID has to be stated in every cross-chain interaction.
For example, it has to be specified in the receivingChainID
property of a CCM to a sidechain and in the sendingChainId
property of a cross-chain update command from a sidechain.
Chain identifiers are 4-byte values that follow a specific format:
-
The network-specific prefix: The first byte is used to identify the mainchain and its corresponding network of blockchains to which the chain wishes to connect. It is included explicitly to ensure that a chain does not use the same chain identifier in the test network as in the mainnet.
-
The chain-specific suffix: The other 3 bytes identify the chain within the network. Must be unique within the network.
By checking the chain ID, users can easily verify that they are signing a transaction for the correct blockchain. |
The chain ID is defined directly in the config.json file of the blockchain client.
Network | Name | Type | ChainID Prefix |
---|---|---|---|
Mainnet |
|
|
|
Testnet |
|
|
|
Further details regarding the chain ID can be found in the LIP 43.
Example of interoperability usage
Let’s look at an example to illustrate the capabilities of the Klayr interoperability solution, and how sidechains can interact together.
In this case we are going to use an example with two functioning applications, and the steps of how interoperability can be achieved using this example are depicted in the illustration below.
Firstly, the Muzikie App is a decentralized music streaming platform that allows users to listen to music and podcasts from an ever-expanding list of audio files, whilst simultaneously supporting the artists with access to a fair and transparent economy. The Muzikie App is connected to the Klayr mainchain, and in order to function as a sidechain, the Muzikie App also has its own set of applications consisting of auditable, democratic, and futuristic solutions developed to manage music and its associated data. Furthermore, also connected to the Klayr mainchain is the Enevti App, a decentralized social media platform that enables users to create, manage, and trade their own NFTs.
In order to connect the Muzikie and Enevti sidechains, we can use a Cross-chain communication protocol that allows them to exchange data and transactions. For example, a user holding KLY tokens may decide to create an audio NFT on the Muzikie app, transfer it from the sidechain through the Klayr mainchain to the Enevti app, and then sell this NFT for ENVT tokens. Finally, that same user could then sell/convert their ENVT tokens back to KLY tokens. Conversely, it is also possible for KLY tokens to be converted/sold to ENVT tokens.
So to perform this action, the user would first have to sell/convert their KLY tokens to MZK tokens, then create an audio NFT. This would be followed by initiating the transaction on the Muzikie App, whereby the user defines the specifications/details of the audio file such as the name, description, genre, and more, including paying a network fee. Once the transaction is confirmed on the Muzikie sidechain, the audio NFT will be created and accessible for streaming to users with a valid subscription.
The owner may decide to sell their audio NFT on an NFT market. A good example would be the Enevti App. In order to achieve this, the user would have to specify the destination address, namely the user’s address on the Enevti sidechain, and the amount of KLY tokens required, including any transaction fees. Once confirmed, the NFT would be transferred to the Enevti App sidechain. The user could then list the NFT for sale on the Enevti App’s marketplace, and state the asking price in ENVT tokens. Once a buyer agrees and purchases the NFT and the sale is completed, the agreed amount of ENVT tokens would be transferred to the user’s Enevti wallet. Finally, the user could then convert/sell the ENVT tokens back to KLY tokens, at the current market price, which, for example in the future, could be achieved using a DEX application, and then transferred back to the Klayr wallet.
![sidechain interoperability example](../../_images/understand-blockchain/interop/sidechain-interoperability-example.png)
Example of interoperability between the Klayr mainchain and sidechains.