Technical Solution

Our interoperability solution is based on the paradigm of cross-chain certification introduced in detail in the previous research blog post "Introduction to Blockchain Interoperability". Basically, cross-chain certification means that information from one chain is submitted to another chain utilizing a signed object called a certificate. Let us see more specifically how this will work in the Lisk ecosystem.

Cross-Chain Update Transactions

We will now consider the simplified case of two interoperable chains, where one is the sending chain and the other one the receiving chain. To send information from the sending chain to the receiving chain, the first step is to include a transaction on the sending chain. This transaction then emits one or more cross-chain messages which carry the relevant information that is supposed to be sent to the receiving chain. The cross-chain messages are then transferred to the receiving chain. However, we do not send a cross-chain message to the receiving chain right after the corresponding transaction was included. Instead, several cross-chain messages, possibly from multiple blocks or even rounds, are collected together and are put into a cross-chain update transaction, which is then posted on the receiving chain. This concept is also illustrated below in Figure 1. Cross-chain update transactions are in fact the main transactions facilitating interoperability in the Lisk ecosystem and our realization of cross-chain certification. Therefore, we also called the general technique “cross-chain update” instead of “cross-chain certification” for simplicity in the online presentation given in the "First Glimpse at Lisk Interoperability".

Figure 1: The transactions t1 to t3 are included in the sending chain over the course of some blocks, where each one emits one cross-chain message, denoted by m1, m2, and m3. The cross-chain messages are put into one cross-chain update transaction, denoted by CCU, that is posted and included in the receiving chain.

The Lisk ecosystem will, of course, consist of more than just two chains. Therefore, the solution is also slightly more sophisticated than previously explained. That means, for example, that a cross-chain update transaction may contain several cross-chain messages that target different chains. This will be further explained in the sections below.

Note that there is no rule on how many messages must be collected before a cross-chain update transaction is created or for how many blocks one must collect messages before creating one. There is full flexibility, and any user could create a cross-chain update transaction whenever they want by taking all cross-chain messages that were not put into a cross-chain update transaction before.

Content of Cross-Chain Update Transaction

Cross-chain update transactions consist of the following three major parts:

• The cross-chain messages.
• A certificate.
• Information about the current validator set of the sending chain.

We already described the first part, the cross-chain messages, above.

A certificate is an object containing information from a finalized block header that is signed by a large portion of validators from the sending chain and thus authenticates a finalized state of that chain. An authenticated finalized state is a requirement for accepting cross-chain messages on the receiving chain. That means a cross-chain message is applied on the receiving chain only if it was attested that the corresponding transaction on the sending chain belongs to a finalized state.

With the information about the current validator set of the sending chain, the receiving chain knows which validator set is eligible to sign the next certificate.

Cross-Chain Update Transactions originating from the Lisk Mainchain

Let us first consider the case where the sending chain is the mainchain. There will be several sidechains connected to the mainchain. Therefore, the cross-chain messages created on the mainchain will also target different sidechains. To submit cross-chain messages from the mainchain to a specific sidechain, all cross-chain messages targeting this sidechain are put into a cross-chain update transaction, omitting the cross-chain messages targeting other chains. This transaction is then posted on the sidechain. This is also illustrated in Figure 2 below, where cross-chain messages targeting two different sidechains are put into separate cross-chain update transactions.

Figure 2: There are four transactions, t1 to t4, included in the mainchain, where each one emits one cross-chain message, denoted by m1 to m4. Cross-chain messages are displayed as rectangles, transactions as rectangles with rounded corners. The color of a transaction or cross-chain message is always the one of the receiving chain, except for a cross-chain update transaction whose color is the one of the sending chain. The cross-chain update transaction CCU1 containing m1 and m3 is included in sidechain 1. The cross-chain update transaction CCU2 containing m2 and m4 is included in sidechain 2.

Cross-Chain Update Transactions Originating from Sidechains

Now, we consider the case where the sending chain is a sidechain. In this case, all cross-chain messages are put into a cross-chain update transaction that will be posted on the mainchain. This includes cross-chain messages targeting the mainchain as well as cross-chain messages targeting other sidechains. When the cross-chain update transaction is included in the mainchain, the cross-chain messages are treated differently depending on their target chain.

If a cross-chain message is targeting the mainchain, it is processed on the mainchain. If a cross-chain message is targeting another sidechain, say sidechain 2, then the cross-chain message is forwarded to sidechain 2. That means the cross-chain message is included in an upcoming cross-chain update transaction from the mainchain to sidechain 2. In other words, cross-chain messages from one sidechain to another sidechain are routed via the mainchain. The processing on the mainchain is very fast because the mainchain does not perform the full validation nor does it apply the cross-chain message.Both cases are depicted below in Figure 3.

Figure 3: On sidechain 1, three transactions are included, where each one emits one cross-chain message, denoted by m1, m2, and m3. The color of a transaction or cross-chain message is always the one of the receiving chain, except for a cross-chain update transaction whose color is the one of the sending chain. All three cross-chain messages are delivered in one cross-chain update transaction, CCU1, to the mainchain, where m1 and m3 are processed, but not m2. Later on, m2 is delivered to sidechain 2 by a cross-chain update transaction, CCU2, from the mainchain to sidechain 2. This cross-chain update transaction contains an additional cross-chain message, m4, emitted by the transaction t4 included in the mainchain.

Cross-Chain Messages

We have already talked extensively about cross-chain messages without really explaining what they are.

Cross-chain messages are very similar to transactions in that they both induce a state transition when included in a chain ledger. The main difference is that every cross-chain message has the additional properties sendingChainID and receivingChainID. The receivingChainID property allows, for example, the routing that the mainchain performs.

Cross-chain messages can be emitted by a transaction included in the sending chain. For example, when you want to transfer some tokens from one chain to another, you submit a cross-chain token transfer transaction on the sending chain which then emits a cross-chain token transfer message. The cross-chain token transfer transaction will cause a state change on the sending chain, namely, debiting the sender account. The cross-chain tokens transfer message will cause a state change on the receiving chain, namely, crediting the receiving account. Figure 4 below shows an example in which Alice sends some LSK tokens from her account on the sending chain to Bob’s account on the receiving chain.

Figure 4: Alice performs a cross-chain token transfer from her account on the sending chain to Bob’s account on the receiving chain. For 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 an asset property. Therefore, when building a blockchain application with the Lisk SDK, you can create custom cross-chain messages by defining the content of the asset property as needed. For example, you could create a custom cross-chain message that contains some authenticated information from an oracle chain in its asset property. This flexibility implies the general cross-chain messages capabilities mentioned in the blog post "Introduction to Blockchain Interoperability".

Example of Interoperability Usage

Let’s look at an example to get a better impression of the capabilities of our interoperability solution. All the following steps described here can also be seen in Figure 4 below. Assume we have an exchange chain, a prediction market chain, and an oracle chain connected to the mainchain. Then, a user story could look like this: Assume a user has some LSK tokens on the mainchain, and they would like to bet on the prediction market chain, but this chain requires a special token for betting. Therefore the following actions would apply:

1. The user sends some of their LSK tokens to the exchange chain via a cross-chain token transfer message.
2. The LSK tokens are then swapped for the betting tokens.
3. Subsequently, the betting tokens are then sent from the exchange chain to the prediction market chain via a cross-chain token transfer message.
4. On the prediction market chain, the user bets on the winner of the Nobel Prize in Physics.
5. After the announcement of the Nobel prize winner, the oracle chain sends the result to the prediction market chain via a custom cross-chain message.
6. The user then receives their winnings as they made the correct guess.

Figure 5: Example of interoperability between the Lisk mainchain and three sidechains. The steps 2), 4), and 6) are transactions performed within a single chain. The steps 1), 3), and 5) are cross-chain messages. The cross-chain messages 3) and 5) are sidechain-to-sidechain cross-chain messages which are routed via the mainchain. The cross-chain message 1) is a mainchain-to-sidechain cross-chain token transfer message.

The Role of the Mainchain

The mainchain has a key role in the Lisk ecosystem. Firstly, all sidechains need to register on the mainchain in order to interoperate with other chains. Once a sidechain is registered, the mainchain maintains the relevant information about the sidechain, such as the number of cross-chain messages sent to it and the current list of sidechain validators.

As already described above, the mainchain also serves as a router for cross-chain messages from one sidechain to the other. Note again that the processing of these messages on the mainchain is very fast as these messages are only forwarded. This means for instance, that custom cross-chain messages whose full validation or application is very expensive do not affect the mainchain.

The mainchain only supports the LSK token. Furthermore, since it is the native chain of the LSK token, it keeps track of the distribution of LSK tokens in the whole ecosystem.

Customization of Sidechains

There are almost no constraints on the applications that you can implement on a sidechain using the Lisk SDK. Next to the large flexibility regarding application logic, there are several settings regarding the blockchain protocol that can be customized, such as the validator selection mechanism. The initial version of the Lisk SDK that implements the Lisk interoperability solution will support Delegated Proof-of-Stake as well as a Proof-of-Authority. Furthermore, the block rewards can be customized: sidechain developers will be able to choose to have no block rewards at all or to have block rewards in sidechain tokens. Constants like round length, block time, and block size limit can be adapted as well. Finally, sidechain developers can choose which tokens to support. This can include tokens native to this chain but also sidechain tokens from other sidechains. Notice that to be part of the Lisk ecosystem, a sidechain will need to support the LSK token.

The Role of the LSK Token

The LSK token is the only token that can be transferred to every chain within the Lisk ecosystem. It will be the default token for transaction fees on sidechains, but it will be possible to configure a sidechain token for the transaction fees. As the LSK token is listed on several exchanges, it will in most cases be the initial token that a user acquires within the Lisk ecosystem. Once a user possesses some LSK tokens, they can exchange them for other sidechain tokens, e.g., on a decentralized exchange sidechain.

Properties of our Interoperability Solution

When designing the interoperability solution for the Lisk ecosystem, we had several goals in mind that we think are realized in our solution: First of all, it is scalable. That means, there are no bounds on the number of sidechains that can be connected to the mainchain.

It is also very flexible in the sense that cross-chain update transactions can be transmitted whenever it is desired. One could transmit a cross-chain update transaction every 10 seconds or just once in a month. One can transmit them more frequently in busy times, and less frequently in quiet times. Due to this flexibility, it is also fast: If a user would like to have a cross-chain message transmitted as soon as possible they could just create and post a cross-chain update transaction that contains the cross-chain message by themselves. Creating and sending cross-chain update transactions is not restricted to validators or any other roles. Any user can do this.

It is secure because certificates need to be signed by a large portion of validators from the sending chain and all cross-chain messages are authenticated by the certificates. Since the receiving chains keep track of the sending chain’s validator set, it is easy for a receiving chain to see if the signatures of a certificate were created by the legitimate validators. In fact, the receiving chain will be able to detect and reject malicious cross-chain update transactions as long as the security assumption on the sending chain holds. Nevertheless, there will even be additional security measures, including some that ensure that problems due to failed security assumptions on sidechains are confined to that chain and cannot propagate outside.

Last but not least, the solution is efficient. Although all sidechain-to-sidechain cross-chain messages are routed via the mainchain, this is not really a burden for the mainchain as it only relays the messages without any expensive processing.

The New Roadmap

We are organizing our research of the interoperability solution and the LIPs that we are preparing around eight roadmap objectives. Each roadmap objective encompasses one key aspect of our interoperability solution that will be addressed by one or more LIPs. For these LIPs, we distinguish between interoperability core LIPs and supporting LIPs. The former ones specify the core part of the Lisk interoperability solution and will be published at Lisk.js 2021 event in May. The latter ones are not strictly part of the interoperability solution, but are nevertheless necessary to define the interoperability solution. They will already be published before Lisk.js.

We have updated our roadmap to include these eight objectives for the Blockchain Interoperability phase. You can find the full list of objectives together with a description of each of them below:

1. Define cross-chain messaging protocol. This objective encompasses the definition of cross-chain messages and cross-chain update transactions described above. This includes their validity rules, the message routing, etc.
2. Define sidechain registration and lifecycle. Here, the goal is to define the whole lifecycle of a sidechain, starting from its registration on the mainchain up to its potential termination including token recovery from terminated chains.
3. Define state model and state root. As part of this objective, we plan to introduce a state root that allows us to cryptographically authenticate the whole state of a chain with a single hash, using inclusion proofs.
4. Introduce token standards for the Lisk ecosystem. We plan to define some standards regarding fungible tokens and non-fungible tokens. These standards should make it straightforward to create sidechain tokens on sidechains. This also includes the corresponding cross-chain token transfer messages described in the example above.
5. Update Lisk-BFT for interoperability. The goal is to make the Lisk-BFT protocol more flexible. For example, it should be allowed to set different validator weights for finalizing blocks and allowing these finality weights to change over time. Different weights may, in particular, be desired for sidechains that use the Proof-of-Authority mechanism. Moreover, Lisk-BFT should generate certificates that can be used in cross-chain update transactions to authenticate cross-chain messages and validator changes.
6. Update block header format. The format of block headers and genesis blocks needs to be updated to account for the changes listed above.
7. Introduce alternative validator selection mechanism for sidechains. This objective aims at specifying the new Proof-of-Authority validator selection mechanism.
8. Enhance signature scheme. We plan some enhancements for the signatures used in Lisk. The most important one is to introduce compact aggregate multisignatures, which are highly beneficial to limit the size of the certificates contained in cross-chain update transactions.

Conclusion

The Lisk interoperability solution is based on the paradigm of cross-chain certification. Any kind of information can be exchanged between chains using general cross-chain messages. The Lisk mainchain plays the key role in the whole ecosystem since all cross-chain messages between sidechains are routed via the mainchain. Sidechains can further be customized, not just regarding the application logic, but also with regard to the general blockchain logic, such as the consensus algorithm. The LSK token can be moved to any chain, and it will be the default token for transaction fees in the ecosystem. Moreover, creating sidechain tokens on a sidechain and transferring them to other chains will be straightforward using the new token standards.

The updated research roadmap gives an overview of how we divide the interoperability solution into eight key research objectives. More details about these objectives and the LIPs addressing them will be revealed at the next Lisk.js event on May 21st-22nd, 2021.

For additional questions and comments on the topic, we will host an AMA on Lisk.chat with Andreas Kendziorra and Jan Hackfeld on Wednesday, April 7th at 4pm CEST. We also invite all community members to go to the Lisk Research forum, where we are always happy to hear your feedback and to participate in discussions on research topics for the Lisk ecosystem.