Blockchain Interoperability: The Lifecycle of a Sidechain

@liskLisk

We empower developers with a software development kit for blockchain applications written in JavaScript.

This is the next edition of the blog post series covering the details of the Lisk interoperability solution. In the previous story we discussed the main foundational blocks: sparse Merkle trees and the state model of interoperable blockchains. Here, we cover the lifecycle of a sidechain in the Lisk ecosystem.

Before delving into the topic itself, we should refresh a couple of concepts which are central to the Lisk interoperability solution. These concepts were first introduced in a earlier blog post, together with a high level overview of the entire solution. Although they will be the focus of the next editions of this blog post series, for now we just need to know their general definition:

• 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 Lisk ecosystem.
• Cross-Chain Update Transactions: Abbreviated as CCUs, cross-chain update transactions are the carriers of the information transmitted between chains in the Lisk ecosystem. They carry information about state changes from the sending chain to the receiving chain. In particular, they contain a certificate from the sending chain. CCUs can also include cross-chain messages, and hence serve as an envelope for messages from one chain to another.
• Cross-Chain Messages: Abbreviated as CCMs, cross-chain messages are the standard method for cross-chain communication among users in the Lisk ecosystem. They are emitted as a result of the processing of certain transactions and then included inside a CCU. 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 Three Stages in the Lifecycle of the Sidechain

From its inception to its potential termination, a sidechain may go through three stages, corresponding to three states, in the context of the interoperability within the Lisk ecosystem. These are as follows:

• Connection to the ecosystem: The sidechain registration process. The sidechain has the status “registered”.
• The active phase: The actual interoperability phase, where the sidechain is able to exchange information with other chains in the ecosystem. Here, the sidechain status is “active”.
• Disconnection from the ecosystem: The termination of the sidechain when the status of the sidechain is updated to “terminated”.

In the following subsections, we cover each of these stages and learn about the conditions for a sidechain to progress in its lifecycle. It is worth mentioning that before entering the first stage, we assume that the sidechain has already undergone its development phase. More specifically, the genesis block of this sidechain is already created, and a certain set of validators settled and fixed. These validators are the sidechain initial validators.

At this point these sidechain initial validators can start already adding blocks on top of the genesis block. Sidechains have the flexibility to connect to the Lisk ecosystem from any point onwards. Hence, it is totally fine if the sidechain has been already running independently for months. In principle, a sidechain may never connect to the ecosystem and run as an isolated project, but in this case it will not qualify as a sidechain, just a simple blockchain.

Connection to the Ecosystem

Once the genesis block is created and the initial validators are set, the sidechain is ready to connect to the Lisk ecosystem. The connection is a two step process. Firstly the sidechain has to be registered on the Lisk mainchain, and secondly the Lisk mainchain has to be registered on the sidechain.

Sidechain Registration Process

The sidechain is registered on the mainchain by submitting a sidechain registration transaction on the Lisk mainchain. This transaction contains basic information about the sidechain and any user can submit it. To be precise, it contains the following information:

• Name of the sidechain: Every chain in the Lisk ecosystem has a name, which has to be unique. With it, chains can be easily identifiable by users.
• ID of the sidechain genesis block: The ID of the sidechain genesis block. The network identifier of the sidechain is computed using this data.
• Initial validators: The initial set of validators of the sidechain. This information is used to validate the first CCU from the sidechain.

When this transaction is processed, a sidechain account is created in the mainchain state. Effectively, this sidechain account is a collection of key-value pairs in the state store of the mainchain containing all the information required to interoperate with the newly registered sidechain. We will cover how the sidechain account allows the validation and processing of cross-chain transactions and messages in the next editions of the interoperability blog posts series. For now, let’s see some of the main defining aspects.

Figure 1: The sidechain registration transaction T is included in the mainchain. As a result, the sidechain account is created in the mainchain state with its status set to “registered”.

Chain ID

The chain ID uniquely identifies a chain in the Lisk ecosystem. It serves a similar purpose for chains as addresses do for user accounts, identifying the sending chain and the receiving chain in every cross-chain interaction. The chain ID for a sidechain is assigned as an incremental integer, similar to transaction nonces. For example, if there are 41 chains already registered in the Lisk ecosystem (the mainchain and 40 sidechains), the next registered sidechain will have a chain ID equal to 42.

The format of chain IDs provides an efficient and compact way to uniquely identify chains in the ecosystem. Users can easily remember the chain ID of their favorite blockchain applications.

Network Identifier

The network identifier is a byte sequence unique to a chain that has to be prepended to the input of the signing function of every transaction, block, or generic message of the chain. It is necessary to avoid transaction replays between different chains in the ecosystem. In the Lisk ecosystem, the network Identifier of a sidechain is computed as the hash digest of the ID of its genesis block and the address of the user account sending the registration transaction. This way it can be pre-computed before the actual sidechain registration if necessary.

Name

The name of the sidechain as stated in the sidechain registration transaction.

Status

A sidechain can be in one of three status modes: “registered”, “active”, and “terminated”. These correspond to the three stages of the lifecycle. The sidechain account is automatically set to “registered” when it is created.

Last Certified State Root

The last certified state root contains the root of the state tree of the sidechain set by the last CCU posted on the mainchain. As explained in the previous blog post, the state root is used during the processing of CCUs to authenticate the CCMs from the sidechain.

Last Certified Height

The last certified height contains the height of the certificate in the last CCU posted from the sidechain.

Last Certified Timestamp

The last certified timestamp is the timestamp of the last CCU posted from the sidechain. It is used to check that the partner chain fulfills the liveness requirement that will be discussed below.

Validators

The set of the current sidechain validators which are those expected to sign the certificate contained in the next CCU from the sidechain. Initially, this property contains the initial validators from the registration transaction.

Inbox and Outbox

The inbox and outbox structures are used to keep track of incoming and outgoing CCMs exchanged with the sidechain. To achieve this, CCMs are inserted in regular Merkle trees, which make it possible to efficiently prove that a certain CCM was received (in the inbox), or sent (in the outbox).

Mainchain Registration Process

Once the sidechain is registered on the mainchain, an analogous process is done on the sidechain to register the mainchain, using the mainchain registration transaction. Unlike the sidechain registration, which can be sent and signed by anyone, this transaction has to be signed by a large majority of the currently active sidechain validators. In other words, this transaction requires the approval of the sidechain validators and they have to agree on the information inserted in it. It contains the following properties:

Sidechain own name: The name assigned to this sidechain by the sidechain registration transaction.

Sidechain own chain ID: The chain ID assigned to this sidechain by the sidechain registration transaction.

Mainchain validators: Similar to “initial validators” above, these validators are expected to sign the certificate contained in the next CCU from the mainchain.

The effect of processing this transaction is similar to the one introduced above. On one hand, the sidechain “becomes aware” of the name and the chain ID that it was assigned on the mainchain. This is especially important for the chain ID, since the sidechain needs to know about its own chain ID to be able to correctly process the CCUs and CCMs targeting this sidechain.   

On the other hand, the mainchain account is created in the sidechain state. The structure and properties are the same as for the previous case but the information refers to the Lisk mainchain. In particular, the validators property is set to the mainchain validators set in the transaction. This way the sidechain is ready to receive the first CCU from the mainchain.

The Active Phase

At the end of the sidechain registration process, the sidechain has “registered” status. Although it is already part of the Lisk ecosystem, users cannot yet exchange CCMs with this sidechain from other chains. For this it is necessary to activate the sidechain, which will effectively happen when the first CCU is posted on the mainchain. Anyone can post this CCU, which will contain a certificate signed by the set of initial sidechain validators. Afterwards, a CCU containing a certificate signed by the mainchain validators (set in the mainchain registration transaction), has to be posted on the sidechain to activate the mainchain account.

Figure 2: The first CCU, signed by the sidechain initial validators, is included on the mainchain and sets the status of the sidechain account to “active”. From this moment on, users can exchange CCMs with the sidechain.

From this point onwards, the sidechain will be active in the ecosystem and will be able to exchange CCMs with any other active chain in the ecosystem. The details of how this works will be the subject of the next blog posts in this series.

Disconnection from the Ecosystem

Under normal circumstances, a sidechain will permanently remain in the active phase. However certain projects may be abandoned or deployed with critical flaws that will make them unusable (this is no cause for concern as the other chains in the Lisk ecosystem will not be affected. In cross-chain certification, the security and liveness of a chain is independent from the others). To address this situation, a sidechain can be terminated. This process effectively disconnects the sidechain from the Lisk ecosystem and activates certain mechanisms that allow users to recover their funds from the sidechain.

Figure 3: The mainchain has not received any CCU from the sidechain in the last 30 days. As a consequence, the sidechain account status is set to “terminated” and the sidechain is effectively disconnected from the Lisk ecosystem.

The main condition for a sidechain to remain active is the liveness requirement: Sidechains have to post CCUs on the mainchain at least once every 30 days. If a sidechain breaks the liveness requirement, i.e., it has not posted a CCU in the last 30 days, its account status on mainchain will be updated to “terminated” and from this point onwards every CCU and CCM from or to this sidechain will be rejected.

Let’s assume now that a sidechain containing some LSK and many other tokens and NFTs from other sidechains is terminated. We previously stated that a terminated sidechain cannot be reached anymore from any chain in the Lisk ecosystem. Then, how do the owners of all these funds and collectibles regain access to their assets? It would be unfair to them to simply lose control of the assets since they were not responsible for the sidechain termination. This situation is where the sidechain recovery transactions come into play. These transactions allow users to claim back their tokens, NFTs, or in general any asset that was sent to the sidechain before its termination.

There are two recovery transactions, message recovery transactions and state recovery transactions. The main use cases provided by these transactions are as follows:

On the Lisk mainchain:

• Users can recover a pending CCM from the outbox of the sidechain account by submitting a message recovery transaction. Pending CCMs are those CCMs that have not been included in the receiving sidechain yet.
• Users can recover LSK tokens they had on a terminated sidechain by submitting a state recovery transaction.

On SideChains

• Users can recover any token they had on a terminated sidechain by submitting a state recovery transaction.
• Users can recover any NFT they had on a terminated sidechain by submitting a state recovery transaction.
• Certain custom modules allow users to recover arbitrary data stored in the terminated sidechain by submitting a state recovery transaction. In this sense, recover means that a certain protocol logic is triggered in the sidechain.

These transactions can be sent by any user and they do not require any trust in other network participants. Basically, the main working principle for both transactions is to prove that a certain piece of information (e.g., a user’s token balance, a CCM, a NFT, etc.), was part of the sidechain outbox tree or the sidechain state tree. In a future blog post we will cover in detail how these transactions work and what the requirements are for a successful recovery.

Conclusion and Next Steps

In this blogpost we have covered the three stages in the lifecycle of a sidechain. These stages determine the processes and conditions for a sidechain to connect to the Lisk ecosystem, to become interoperable and remain interoperable continuously. However, we did not discuss in detail the Lisk’s cross-chain communication framework or any of its features. This will be the main subject of the incoming issues of this blog post series. If you want to know more about cross-chain certification, how CCMs can transfer tokens and NFTs, or how recovery transactions actually work, we highly recommend you not to miss them.

The technical specifications of the topic covered in this blog post can be found in our Lisk Research forum. In particular, the LIPs “Properties, serialization, and initial values of the interoperability module”, “Chain Registration”, and “Sidechain recovery transactions” define the main concepts around the lifecycle of a sidechain. These LIPs, together with another 10 LIPs describing the interoperability solution were recently published and proposed for the Lisk protocol. Cross-chain communication between blockchains is still a novel and open area of research, thus we are happy to receive technical feedback, suggestions, or questions about our approach in the Lisk Research forum.

by Lisk @lisk. We empower developers with a software development kit for blockchain applications written in JavaScript.Visit us

Related Stories

Tags

Join Hacker Noon

Create your free account to unlock your custom reading experience.