Skip to main content

High-level Overview of Lisk Interoperabilit




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.

Comments

Post a Comment

Popular posts from this blog

What is iDice?

iDice is a dice betting Dapp fueled by the use of the Ethereum organize. eg. iDice lets in players do several things and having such an innovative new token on the ETHEREUM Platform, we had to write an article about this new project. Guess on the space by the use of keeping up iDice tokens and best of all 100% of all benefit iDice acquires is dispersed among token holders, related to the amount of tokens they dangle. iDice amusement code is decentralized and changeless. Such gigantic building fees highlight a rising requirement for experienced, fair and cast Dapps. iDice iDice is an control which gives a provably affordable and simple, virtual Ethereum dice betting Dapp. The house edge will be set intensely and token holders have an atypical esteem that is dependably equiva- loaned to the house edge. iDice has a fully simple provide code accessible at etherscan.io. The payout of recreations is many times speedy. Provably Fair iDice uses open provide blockchain...
Post a Comment
Read more

Spanish Banks Form New Blockchain Consortium

A group of Spanish banks has formed the country's first blockchain consortium. Wholesale bank Cecabank announced the effort today, partnering with professional services firm Grant Thornton. Who's involved: In its announcement, Cecabank doesn't say which other institutions are taking part, stating that it "comprises 33% of the Spanish banking sector". However, according to Spanish newspaper El Pais, the group's membership includes Abanca, Bankia, CaixaBank, Kutxabank, Ibercaja, Liberbank and Unicaja. It represents the first major foray into blockchain for these companies, as other Spanish banks, including Banco Santander and BBVA, have been working with the tech for some time. What they're saying: Thus far, only Cecabank has commented publicly on the consortium effort, describing it as a way for its employees to get a top-down understanding of the tech – as well as possible insight into how the bank might actually go about using it. "Employees of all o...
Post a Comment
Read more

Ethereum Smart Contract Issues Frustrate Developers with Fatal Bugs

Only weeks after the execution of a hard fork to mitigate various DoS (denial-of-service) attacks, the Ethereum network and its developers are struggling to deal with yet another major flaw. This time, major issues in regards to smart contracts have emerged, which have rendered the efforts of decentralized applications in the Ethereum network purposeless. On November 1, the Ethereum development team and the founder of Solidity warned users and developers against a bug that allowed variables to be overwritten in storage. Variables in a smart contract are agreements made between two or more parties. Thus, if an attacker can gain access to the storage and alters the variables, crucial agreements in decentralized applications can be affected and funds may be extracted, which may pressure developers to discard previous smart contract-based projects to recompile contracts. Ethereum developers including Ansel Lindner stated that the development of an Ethereum application is failing to opera...
Post a Comment
Read more