Lisk's Interoperability Solution: An Overview

One of the central topics at our recent Lisk.js 2021 event, and the one we are most proud of in the Research team, was the publication of the Lisk interoperability solution.

Since we announced that all the research up to blockchain interoperability was completed one year ago, the main focus of the team has been on the Lisk interoperability phase of the roadmap.

This phase started with an extensive state-of-the-art overview of the topic. With all the gathered information, we then determined the general direction of the interoperability solution.

Finally, it was all about specifying the details of the solution and performing internal reviews. The concrete LIPs were finally published during Lisk.js 2021. We now take great pride in the fact that we have proposed a scalable and decentralized interoperability solution for the Lisk ecosystem.

To easily comprehend the entire interoperability solution, we organized it around 8 roadmap objectives. Each roadmap objective defines one key aspect of our interoperability solution that is addressed by one or more LIPs. For these LIPs, we distinguish between interoperability core LIPs and supporting LIPs. The former ones, 12 LIPs in total, specify the core part of the Lisk interoperability solution.

The remaining ones, around 14 LIPs, are not strictly part of the interoperability solution, but they provide the necessary building blocks for it to happen. Some of these are already present in our research forum and the remainder will be published in the next few weeks. Let’s have a look at these 8 roadmap objectives and the specific LIPs that achieve them.

The 8 Roadmap Objectives

Define Cross-chain Messaging Protocol

The goal of this roadmap objective is to introduce the data structures and the transactions necessary to exchange messages between chains participating in the Lisk interoperability.

The LIP Properties, serialization, and initial values of the interoperability module specifies the new data structures that will be part of the interoperability module. Additionally, this LIP also provides a broad overview of the Lisk interoperability solution, motivating several design choices for the interoperability module.

The LIP introduces cross-chain update transactions to the interoperability module. Cross-chain update transactions are the carriers of the information transmitted between chains. By posting a cross-chain update, the receiving chain gets the information required about the advancement of the sending chain. The transaction can also include cross-chain messages and thus serves as an envelope for messages from one chain to another.

Figure 2: The cross-chain messages, CCM1, CCM2, and CCM3 are collected together with the certificate, Cert, from the sending chain and inserted into a cross-chain update transaction, CCU. Then CCU is included into the receiving chain.

The LIP Cross-chain messages define those cross-chain messages, their schema, their processing, and the base error handling. Defining a base cross-chain message allows all chains in the ecosystem to read and understand the base properties of messages. Any transaction triggering a cross-chain interaction should emit a cross-chain message to transfer the necessary information to the receiving chain.

Define Sidechain Registration and Lifecycle

This objective aims to define the lifecycle of a sidechain, starting from its connection to the Lisk ecosystem, realized by its registration on the mainchain, up to its potential termination including the recovery mechanisms from terminated chains.

The LIP Chain registration introduces the concept of chain registration in the Lisk ecosystem. This step is necessary to make a sidechain interoperable with the Lisk mainchain, in other words, to connect and become part of the ecosystem. Particularly, for the Lisk mainchain, this registration process is performed by the sidechain registration transaction, whereas for sidechains, it is done by the mainchain registration transaction. Once both transactions have been processed, the registration process of the sidechain is completed and it is ready to interoperate in the ecosystem.

In the Lisk ecosystem, the ability of a sidechain to interoperate with other chains can be revoked permanently, i.e., terminated, under certain conditions. Once a sidechain is terminated in the ecosystem, the users of the said chain cannot have any cross-chain interaction with it. This means they will no longer be able to send or receive any (fungible or non-fungible) token or message from or to the sidechain. For this reason, the LIP Sidechain recovery transactions specifies three transactions that can be used to recover messages, tokens and NFTs from terminated sidechains. These three new transactions are the message recovery transaction, the token recovery transaction, and the NFT recovery transaction.

Define State Model and State Root

The goal of this roadmap objective is to introduce a new state model and the concept of state root in the Lisk protocol.

The LIP Introduce sparse Merkle trees adds a new data structure to the Lisk protocol, the sparse Merkle tree, and the format for inclusion proofs. A sparse Merkle tree is an authenticated data structure that allows the validation of a key-value dataset with a single hash value, the Merkle root. It differs from a regular Merkle tree in that every element of the dataset occupies a fixed position in the tree, given by its key, and the resulting Merkle root depends only on the final dataset and not on the order of insertion.

The LIP State model and state root defines the state architecture of a chain in the Lisk ecosystem. In particular, a sparse Merkle tree, namely the state tree, is built on top of the generic key-value stores defined by each module of the chain. The whole state is therefore authenticated by the tree Merkle root, the state root.

Figure 3: The state tree of a generic blockchain following the specifications in the LIP "State model and state root"Introduce Token Standards for the Lisk Ecosystem

The goal of this roadmap objective is to introduce the data structures and transactions to be used to handle tokens in the Lisk ecosystem.

The LIP Introduce an interoperable token module introduces a module to be used in the Lisk ecosystem for minting, burning, and transferring tokens. This module allows any chain in the ecosystem to handle and transfer tokens in a coherent, secure, and controlled manner. In this LIP, the tokens handled are fungible. Furthermore, this proposal defines the storage and transactions for the LSK token.

The LIP Introduce a non-fungible token module introduces a module to be used in the Lisk ecosystem for creating, destroying, and transferring NFTs. NFTs are uniquely identified assets, in contrast to fungible tokens which are indistinguishable. They can be created, destroyed, and transferred similarly to fungible tokens, however their unique identifiers can never be modified. In this module, NFTs also carry a list of attributes that are used to store information specific to the NFT.

Update Lisk-BFT for Interoperability

Lisk-BFT is the new consensus protocol introduced as part of Lisk Core 3.0. It defines a protocol for validators to finalize blocks using two rounds of voting on blocks. In order to support the new Proof-of-Authority mechanism and cross-chain certification for interoperability, the Lisk-BFT protocol requires some modifications that are encompassed by this roadmap objective.

The LIP Add weights to Lisk-BFT consensus protocol defines how to generalize the Lisk-BFT consensus protocol by allowing for different finality weights of the validators participating in the consensus protocol. A finality weight defines the amount with which the corresponding validator contributes to finalizing blocks. Additionally, the LIP specifies how these weights, as well as the weight threshold for considering a block final, can change over time.

In the Lisk interoperability solution, certificates are the key object for transferring information about the state of one chain, such as cross-chain messages and validator changes, to another chain in a secure manner. The LIP Introduce a certificate generation mechanism defines the schema of certificates, how they can be computed from blocks and how they are signed using BLS signatures. It further specifies commit messages, which are messages containing BLS signatures of certificates. These messages are used to share certificate signatures via the P2P network. This way, validators can aggregate all signatures of a certificate into one signature, which is subsequently included in a block. The mechanism ensures that all certificate data, including the signature, is available on-chain and anyone can use it for creating a valid cross-chain update transaction.

Finally, the LIP Introduce unlocking condition for incentivizing certificate generation specifies a new condition to unlock tokens in DPoS blockchains. Currently, if delegates or normal users unvote, they are subjected to a time-based locking period (around 6 hours for users and 30 days for delegates), before being able to access their funds. In addition, this LIP will require that a certificate for a block after the unvote is generated before delegates or normal users can unlock their tokens. This condition incentivizes delegates to sign certificates. It also prevents a large number of delegates from unlocking their funds without signing any further certificates and thereby halting the certificate generation process.

Update Block Header Format

The block header schema was touched in several other LIPs, including the LIP State model and state root or the LIP Introduce a certificate generation mechanism. This roadmap objective aims to cover all changes to the block header schema in one place, which is achieved by the LIP New block header schema.

Introduce Alternative Validator Selection Mechanism for Sidechains

Currently, the SDK offers DPoS as the only validator selection mechanism by default for new blockchains. This objective aims to provide alternative mechanisms for future sidechains so that they can adapt for a wider range of use cases and applications.

In particular, the LIP Proof-of-Authority validator selection mechanism introduces the Lisk Proof-of-Authority (PoA) mechanism for the selection of validators to generate blocks. In PoA blockchains only a pre-defined set of validators, called the authorities, can propose blocks and they are selected based on off-chain information such as their reputation or identity. This system trades the decentralization of the network (arbitrarily selected authorities), for efficiency and performance.

That is why a PoA blockchain is especially attractive for small projects or blockchain applications where the project owners are expected to run the network nodes. Due to the simplicity of its validator selection algorithm, it is also suitable for applications where a high transaction per second throughput is important.

Enhance Signature Scheme

This roadmap objective has two main goals. The first one is to enable compact aggregate multisignatures. Without them, the certificates contained in a cross-chain update transaction would be significantly larger. The second one is to remove any security risk of signature re-purposing and signature replays that may occur once new data structures are signed within the Lisk ecosystem.

The first goal is achieved by the LIP BLS signatures which introduces BLS signatures to the Lisk ecosystem. More precisely, it specifies which variant of the BLS signature scheme to use and how to apply it in Lisk blockchains.

The LIP BLS signatures is complemented by the LIP Add BLS and forging public key to validator accounts. This one serves two purposes. The first one is to provide a BLS public key to a validator account which is a necessity to make use of aggregate BLS signatures for certificates. The second one introduces a separate EdDSA forging key pair for validators. This allows validators the possibility to not store the (encrypted) secret key or passphrase used for transaction signatures on a remote server. This purpose is strictly speaking not required for the interoperability solution. However, as this LIP is touching the key pairs of validators, it was seen as a chance to easily introduce this security measure for validators without additional conflicts.

The second goal of the road map objective is achieved by the LIP Use message tags and network identifiers for signatures. This LIP ensures that a signature for one message cannot be a valid signature for another message that serializes to the same binary message. This is of key importance, as in the future there won’t be only transaction and block signatures, but also signatures for other data structures such as certificates or certain data structures defined in some sidechain protocols. Moreover, we generalize the usage of the network identifiers, which are currently used for transaction and block header signatures, to arbitrary signatures. This will prevent replay attacks for arbitrary messages.

What is Next For Lisk Research

If you watched Lisk.js 2021, then you are surely aware that the Research team's work is far from over. With the publication of the entire amount of interoperability and supporting LIPs, the team will first focus on an improvement phase for the interoperability solution. During this phase, we will work on topics such as reducing the time for finality in the consensus mechanism, or providing a sound incentivization for the role of the relayer in the interoperability solution. We will also collaborate with our colleagues in UI to ensure that the accessibility for end-users to the Lisk ecosystem is as seamless and secure as possible. In general terms, with the completion of this phase, the Lisk ecosystem will reach a higher level of future-proofness.

Looking further ahead, one of the key features to be added to the Lisk ecosystem is the capability to interoperate with other existing ecosystems. This will be the goal of the blockchain interoperability phase crystalized in the concept of Lisk bridges. Once this roadmap objective is completed, the Lisk ecosystem will not only be a solid autonomous blockchain application platform but also a universally interoperable blockchain solution.

Figure 4: With the milestone 4 completed, the Research team will start working on the milestone 5 of the Lisk interoperability phase, followed by the blockchain interoperability phase.

In the meantime, we encourage the entire Lisk community, and particularly those with a technical focus, to discover every detail of our interoperability solution in the Research forum and give feedback about it.

Lisk’s Roadmap to Ecosystem Interoperability

Revealed at Lisk.js 2021 on May 21st, the new Lisk roadmap introduces names of different gems for all our roadmap phases. The roadmap outlines the network’s transformation from Quartz to Diamond and describes the increase in capabilities as the technology advances through 6 unique roadmap phases. Currently, in its fourth phase, Emerald, which symbolizes a new beginning and good health, the Lisk network will now transition into its Sapphire phase, bringing full interoperability to the Lisk blockchain application platform. Below is a chronological list of the phases outlined in the Lisk roadmap.

Quartz - This phase represents the creation and emergence of Lisk, born from the word Obelisk, namely the shape of Quartz. This gem is well known to display the properties of pure light and energy which contains the entire spectrum of colors. Due to its shape and meaning, the first roadmap phase is called Quartz. This phase was achieved on 24th May 2016 and represented Lisk Core v0, the MVP, and the launch of the Lisk network.

Amber - This phase represents the addition of new changes and updates like creating the minimal wallet Lisk Nano, a command-line wallet Lisk Commander, a suite of useful blockchain libraries, Lisk Elements, and drastic improvements in stability and security of Lisk Core resulting in a stable Lisk network. This phase was achieved on 16th August 2018, Lisk Core v1, creating a stable network with limited functionality.

Ruby - The ruby gem is associated with an inner fire within the soul, revealing its presence and inspiring great success. This phase mirrors the successful development of the Lisk SDK and resulted in the creation of a new flexible, resilient, and modular architecture. This phase was achieved on 23rd July 2019, Lisk Core v2 was built with the newly introduced Lisk SDK.

Emerald - Emerald refers to both health and renewed life, being the intuitive stone associated with the revelation of future events. Emerald is the current phase Lisk is in and it is in perfect alignment with our foresight towards the future by developing new protocol enhancements. This phase will be achieved this fall with Lisk Core v3, built with the Lisk SDK v5, featuring multiple protocol improvements like a new fee system, new address system, and new consensus algorithm.

Sapphire - The Sapphire phase is known for its communication properties and transformative energy which corresponds to our interoperability journey by developing our protocols towards achieving communication between different Lisk blockchains. This phase introduces Lisk’s interoperability, its implementation begins immediately from May 21st, 2021.

Diamond - The diamond is known for being the ultimate pure gem with absolute beauty. Diamonds promote imagination and creativity, accomplishing the most complicated ideas. This resonates perfectly with the complex ongoing work right at the cutting-edge of technology. This phase expands the interoperability protocol to third-party blockchains for full blockchain interoperability, which will be achieved through ‘Lisk bridges’. Possible candidates include Ethereum and Polkadot, enhancing the scalability and usability of the entire industry.

While blockchain networks differ in security, privacy, and throughput, interoperability will allow cross-communication between varying networks, circumnavigating the hindrances associated with different blockchain networks. Continued expansion and innovation in the space of blockchain interoperability will lead to greater accessibility, allowing for wide-scale use and mass adoption.