We already revealed that the Lisk interoperability solution aims to enable general cross-chain messages. In this blog post, we now explain how this is achieved by providing a high-level overview of the Lisk interoperability solution similar to the online presentation given in the "First Glimpse at Lisk Interoperability" at the Lisk Updates from the Lisk Center, Berlin event from November 2020. Moreover, we can now unveil our updated roadmap that contains all the objectives of the blockchain interoperability phase.
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".
Cross-chain update transactions
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.
