Overview

A terminated sidechain cannot send or receive cross-chain messages anymore. Effectively, the sidechain is disconnected from the rest of the ecosystem, and assets (like tokens) cannot be moved to and from it anymore. In particular, this means that users can not send the assets they were holding on the sidechain back to the original native chain (the chain where the asset was created).

The recovery mechanism addresses this problem. Using dedicated commands that are part of the Interoperability module, users can recover their assets directly on the native chain. Furthermore, pending messages that were stuck unprocessed in the outbox of the terminated chain can be recovered as well, and their effect reverted on the sending chain.

Glossary

Terminating a chain: When a sidechain is terminated, no cross-chain messages can be exchanged with it anymore. A terminated state account is created in the state, allowing users to recover assets.
Terminated state account: Data structure holding the state root of the terminated sidechain. It is initialized with the information contained in the last sidechain certificate posted on the mainchain.
Terminated outbox account: Data structure holding the outbox root along with the mainchain inbox size from the terminated sidechain, indicating the number of messages that were processed on it.
Sidechain terminated message: Message created on the mainchain when a message should be routed to a terminated or inactive chain. This message is sent to the original sending chain, allowing it to create a terminated state account.

Causes of Termination

A sidechain can be terminated for violating the liveness requirement (only on the mainchain) or for a violation of a module protocol, as explained in the following sections.

Liveness Requirement

The Lisk ecosystem consists of a collection of blockchains following the Lisk protocol. The mainchain is the most important part of the ecosystem, being the central point that connects chains together and allows them to exchange cross-chain messages. Sidechains have to regularly post cross-chain updates to the mainchain (at least once every 30 days) to indicate that they are still live and functioning. This "liveness requirement" ensures that users will be able to eventually reclaim funds that were sent to a sidechain even if this stops working. In the case where this requirement is not fulfilled, the sidechain is terminated, and the recovery process can start.

Violation of Token-Module Protocol

When tokens are transferred across the ecosystem, the native chain of the token keeps track of their location in an escrow account. When tokens come back from a chain, the amount stored in the escrowed account is reduced, ensuring that no extra tokens were minted in the other chain (see the section "Maintaining the Token Total Supply" in the blogpost "A new token module").

However, if a cross-chain message tries to transfer back an amount of tokens greater than the one stored in the escrow account, the sending chain is terminated and a terminated state account is created. If the native chain is the mainchain (hence, the token is the LSK token), the terminated state account stores the state root of the sidechain; otherwise it stores the root of the mainchain, which can then be used to initialize the recovery with a state recovery initialization command.

Violation of Custom-Module Protocol

Sidechains can be terminated if they violate the protocol of a custom module. This is done by calling the terminateChain API of the Interoperability module. Notice that a sidechain terminated for this reason is not terminated in the whole ecosystem, i.e. it could very well still be active and exchange messages with other chains. However, communication with the sidechain that terminated it is interrupted.

Recovery Commands

The Interoperability module defines the following 4 recovery commands, described in this section. These commands use inclusion proofs against the root of a Merkle tree. For a reminder on how this works, check out the two previous blogposts: "Introducing Lisk Tree" and "Sparse Merkle Trees and the New State Model".

State Recovery Initialization

This command has two purposes. It can be used to set the state root of a terminated state account on a sidechain or to terminate another sidechain directly.

In the first case, the command contains an inclusion proof against the mainchain state root stored in the terminated state account, proving the value of the state root of the terminated sidechain.

In the second case, the command contains an inclusion proof against the mainchain state root, proving that another sidechain is either terminated (the status in the chain account is set to 'terminated') or the liveness condition is violated (as the timestamp of the last certificate is too old).

In both cases, the command sets the sidechain state root in the terminated state account, so that state recovery commands can be issued.

Message Recovery Initialization

Once a terminated state account has been created on the mainchain, users can send this command to initialize the corresponding terminated outbox account. This command contains the channel account of the mainchain stored in the state of the terminated sidechain and an inclusion proof for it against the state root stored in the corresponding terminated state account. The mainchain channel data is needed to get the number of messages that were processed in the terminated sidechain (corresponding to the inbox size of the channel).

The command sets the outbox root and the inbox size in the terminated outbox account, so that message recovery commands can be issued.

State Recovery

This command is used to recover assets (for example fungible and non-fungible tokens) from a terminated sidechain. The user proves the existence of an entry in the terminated sidechain state with an inclusion proof against the state root stored in the sidechain terminated account. The recovery of the state is then handled by the relevant module (for example, the token module would refund the user) and the state root is updated.

Message Recovery

This command is used to recover pending messages from the outbox of a terminated sidechain. The user proves with an inclusion proof validated against the outbox root stored in the terminated outbox account that the message is in the terminated sidechain outbox. The message nonce is compared to the size of the inbox (also stored in the terminated outbox account) to check that the message had not been processed yet. The recovered message is then bounced back to the original sending chain or processed directly if the sending chain is the mainchain.

Workflow of Recoveries

We have now all the pieces to go over the complete workflow for recoveries. The process is slightly different on the mainchain and the sidechains as explained below.

On the mainchain (see figure 1, below):

1. The sidechain is terminated for violating the liveness requirement or the token-module protocol.
   
   1. A terminated state account containing the sidechain last certified state root is created in the state.
   2. Users can start recovering assets with a state recovery command.
2. A message recovery initialization command is sent. This command contains the inbox size of the mainchain stored on the terminated sidechain, which indicates how many cross-chain messages were processed.
   
   1. A terminated outbox account is created in the state. It contains the outbox root of the terminated sidechain channel and the inbox size provided with the message recovery initialization command.
   2. Users can recover pending messages with a message recovery command.

Figure 1: A sketch of the recovery process workflow on the mainchain.

On a sidechain, the workflow can proceed in three ways (see figure 2, below):

1. The sidechain is terminated for violating the protocol of the token module or of a custom module.
   
   1. A terminated state account containing the mainchain last certified state root is created in the sidechain state.
   2. A state recovery initialization command is sent. This command contains the last certified state root (on the mainchain) of the terminated sidechain and an inclusion proof against the mainchain state root stored in the terminated state account.
   3. Users can recover assets native to the sidechain with a state recovery command.
2. The sidechain receives a sidechain terminated message from the mainchain, indicating that a cross-chain message could not be delivered because the receiving chain was terminated. This message contains the last certified state root (on the mainchain) of the terminated sidechain.
   
   1. A terminated state account containing the sidechain’s last certified state root is created in the state. Notice that in this case, the terminated sidechain state root is set immediately, and there is no need for a state recovery initialization command.
   2. Users can recover assets native to the sidechain with a state recovery command.
3. The sidechain is terminated on the mainchain.
   
   1. A state recovery initialization command is sent. This command contains the last certified state root (on the mainchain) of the terminated sidechain and an inclusion proof against the last certified mainchain state root, proving the termination.
   2. A terminated state account containing the sidechain’s last certified state root is created in the state.
   3. Users can recover assets native to the sidechain with a state recovery command.

Figure 2: A sketch of the recovery process workflow on a sidechain.

Example: Recovering LSK Tokens

It is helpful to summarize the recovery process with a concrete example: recovering LSK tokens from the state of a terminated sidechain.

1. A sidechain is terminated on the mainchain because of inactivity.
2. The last certified state root, i.e. the state root contained in the last certificate received from the sidechain is stored in the terminated state account of the sidechain.
3. Users can recover the LSK tokens by sending a state recovery command. This command contains an inclusion proof, proving the user balance on the sidechain against the state root stored in the terminated state account.
4. The funds are credited to the user's account on the mainchain.
5. The state root of the terminated sidechain is updated accordingly.

Recovery-as-a-Service

As explained above, there are certain data-availability requirements necessary to prepare a recovery transaction:

Message recovery commands:

• Access to the cross-chain messages in the sidechain outbox.
• The entire tree of the sidechain outbox to be able to provide the inclusion proof.

State recovery commands:

• Access to the specific asset to recover from the sidechain
• The entire state tree authenticated by the last certified state root to be able to provide the inclusion proof.

Furthermore, this information has to be kept updated every time a recovery command is processed. Due to this fact, third-party services could offer to recover assets and messages on behalf of users. These services will run a mainchain and sidechain node to provide the data availability, possibly in exchange for a small fee.

Conclusion and Next Topic

This blog post explained how users can recover assets and pending messages from a terminated sidechain. We also discussed the causes of termination and how these recoveries could be handled by third-party service providers.

If you wish to delve deeper and read a more technical presentation, please see the “Introduce sidechain recovery mechanism” LIP. In particular, the rationale section summarizes in a more technical and precise way many points touched upon in this blogpost. Finally, we look forward to receiving your feedback on the Lisk interoperability solution in the Lisk Research forum.

The next blogpost will discuss Lisk-BFT and the certificate generation mechanism necessary for interoperability. Stay tuned!