Lisk sidechains and DEX overview

I recently published some guides related to the lisk-dex community project:

• How to run a custom Lisk sidechain node
• How to setup a DEX to allow users to trade a custom sidechain token for LSK
• How to trade on a DEX using only Lisk Desktop (Lisk Hub)

However, these guides don’t describe how the sidechain or DEX work at a high level so this article aims to provide an overview.

How ‘Lisk Interchain’ sidechains work

Running a sidechain requires a plugin called lisk-interchain. This plugin extends the features of the Lisk Network module to provide an additional layer of peer selection and routing logic which allows nodes to form subnets within the Lisk network based on what features (or custom modules) these nodes have in common.

With this approach, a sidechain is packaged as a module which can be installed on regular Lisk nodes. This enables the node to sync with and maintain its own copy of both the sidechain and the Lisk mainchain. This means that in addition to providing capacity for the sidechain itself, these nodes also add capacity to the Lisk network.

The lisk-interchain plugin handles peer selection and routing to ensure that packets which belong to one sidechain do not reach nodes which belong to a different sidechain; this feature allows the network (the aggregate of all chains) to scale to process an unlimited number of transactions per second (TPS). If network transaction fees across all the different sidechain tokens becomes prohibitively high, new sidechains can be added to provide additional capacity. Each sidechain acts as a separate shard of the network.

The following diagram shows how the network can scale indefinitely in terms of TPS by adding more non-overlapping sidechains:

Note that running two different chain modules on some machines will not reduce the TPS of each chain by half because in Lisk’s case the bottleneck is not CPU usage but block size. Also, even if CPU was the bottleneck, it will be possible to run each chain module in a separate process on a machine which has at least 2 CPU cores so they still don’t slow each other down.

Since each sidechain is interchangeable via a DEX whose orderbook can be verified on-chain, it should be possible for people to accept sidechain tokens interchangeably as a method of payment (the value of any token can be automatically determined based on its relative price on known DEXs).

How the DEX works

The lisk-dex provides the following features:

• Cross-chain token conversion which typically takes about 1 minute (assuming that there is good market liquidity).
• Orders are placed on-chain.
• It maintains a decentralized order book which is constructed from blockchain data in a deterministic way. From the user’s perspective, the order matching behaves similarly to a regular exchange. A single large order can automatically match multiple small counteroffers.
• Unfilled orders can be closed/canceled on-chain.
• Users can submit and close orders even if all the DEX nodes are offline. The DEX nodes can sync to catch up. All the DEX’s output is deterministic.
• The DEX can charge a fee (flat and percentage rate) so that there is an incentive for DEX members to run nodes and process cross-chain trades.
• Uses a decentralized 2-way federated peg mechanism to execute the cross-chain token swap.
• Each DEX can have up to 16 members. A cross-chain transfer can only happen if the majority of DEX members/nodes agree with it so this provides a high degree of security (a hacker would have to hack at least 8 different members’ wallets in order to steal any funds).
• The number of signatures which are required to process cross-chain transactions can be configured when the DEX is first set up. The required number of signatures as well as the list of all DEX members is publicly visible on both the mainchain and sidechain.
• All DEX behaviors can be fully verified based on the underlying public blockchains.

To work, the DEX needs to have two multisignature wallets; one on the mainchain and one on the sidechain and each DEX member needs to be a member of both multisig wallets. Each DEX member then needs to run a Lisk node which has the required sidechain module and the lisk-dex module.

The DEX simply watches the two blockchains for incoming transactions that are sent to its own multisig wallet on either chain. A transaction should contain a DEX command which tells the DEX what to do with the funds. If the DEX does not recognize the command, it will issue a refund back to the sender’s wallet (minus blockchain fees). If the command instructs the DEX to buy a sidechain token, it will add the order to its decentralized order book. If the new incoming order matches a limit order in the decentralized order book (from the opposite chain), all DEX nodes will independently prepare the necessary cross-chain transactions on both the mainchain and sidechain and will start collecting signatures from each other. When a node has collected enough valid signatures from their DEX peers, they will broadcast the multisig transaction to the relevant blockchain.

Because all the nodes process and verify both blockchains independently in a deterministic way, a transaction will only be sent out from a DEX multisig wallet address if enough DEX nodes come to the same conclusion based on their own copies of the order book.

How DEX handles forks

If one (or both) of the two blockchains of a DEX node forks, the affected chain module will detect this and start rewinding blocks (this is the Lisk fork recovery mechanism), when this happens, the DEX node will immediately reset to the last good snapshot of the order book and wait for the affected blockchains to resume normal progress. When both chains are progressing again, the DEX node will rebuild its order book from that last known safe state until it reaches the latest height. Note that during a significant fork, DEX nodes would typically not be able to reach consensus with each other so no cross-chain transactions should go through. In case of a particularly bad fork (e.g. 50% of the network affected) if the fork recovery mechanism fails to kick in and also if the majority of DEX nodes end up following the bad fork (due to bad luck in peer selection), then the DEX could potentially lose some funds due to processing invalid forked chain transactions; the chance of this perfect storm of problems happening simultaneously is ‘DEX fork risk’ and can be reduced or even mitigated depending on DEX configs (I.e. having more DEX members, requiring signatures from more members in the multisig wallets and/or increasing DEX block finality); in any case, the % exchange fee per trade charged by the DEX should be more than enough to cover this risk; also, the more DEX nodes/members there are, the less likely this is to occur due to random peer selection.

If you want a more info about the DEX protocol and behaviours, see this repo: https://github.com/jondubois/lisk-dex#dex-protocol

If you have any questions or feedback, feel free to reach out to me via email (on my GitHub profile).