In the Hydranet DEX and Blockchain Layer articles we touched upon the scalability problem in the blockchain industry. For instance, when BTC is sent from one wallet to another, this transaction is typically subject to long waiting times and high transaction fees, which negatively affects the user. The reason for the long waiting times and high fees is that the Bitcoin blockchain can only process 7 transactions per second, while there are occasionally many more submitted to the blockchain. Transferring money from one wallet to another therefore becomes impractical, especially when the transaction has to go fast, as in your everyday grocery store. Best practice today is to use a credit card for payments. Credit cards can handle up to 24,000 transactions per second (Visa). This makes them cheap, fast and easy to use for money transfers between peers.

For the Hydranet DEX to get access to cheap and fast transactions, it uses the Lightning Network. The Lightning Network has a structure that allows Bitcoin transfers between two wallets for close to zero fees and instant confirmation times. In this article we are going to touch upon how this works. 

Payment Channels

The Lightning Network offers an environment parallel to the Bitcoin blockchain, see the figure below. This environment is what is referred to as an "off-chain" solution, since actions within this environment will not interact with the blockchain directly. Connections, called ‘’payment channels’’, are created between different wallets (addresses) within this environment (see the colored arrows in the figure). These payment channels are opened by one or two users locking a certain amount of coins through an on-chain funding transaction. The equivalent amount of coins will be available within the payment channel. Once the payment channel is open, the two wallets can make as many transactions between them as they want. Since the transactions made within the payment channel are not broadcasted to the blockchain, there are virtually no waiting times nor transaction fees.  When the wallets no longer want to make any transactions, the payment channel can be closed. The final state of the payment channel will be broadcasted to the blockchain and the two wallets will be updated with the latest state of the payment channel.

The use of HUBs

The Lightning Network creates an environment with bi-directional connections. Each connection is a two party payment channel, which makes the Lightning Network an ideal method for one-to-one transactions. However, the Lightning Network becomes less practical in scenarios when transactions are made between a large number of users, which is rather typical on exchanges, where many users trade the same trading pair. Within the Lightning Network environment this mean that every, for instance, maker would need to open a channel with every taker that fill some of the makers order, see the "point-to-point" illustration below. To avoid this widespread opening of payment channels between, more or less, every peer, HUBs can be introduced. These HUBs will be used as a liquidity pool within the Lightning Network. Makers and Takers will interact with the HUBs instead of directly with each other, see the "hub-and-spoke" illustration below. In this way, sell and buy order demands can more quickly be met. 

There are however problems with this solution. These problems mainly concern decentralization. If the liquidity is concentrated in one HUB alone, there is a high requirement of robustness on this HUB. This HUB is not allowed to have any downtime, as this would hinder the DEX users from trading. And as the figure below suggests, when the number of HUBs decreases, so does the centralization of the network and thus the operation of DEX. On the other hand, a more decentralized network with many HUBs will induce the problems mentioned earlier. Users will need to open several payment channels with all of these different HUBs, which in turn will increase the settlement time of the transactions made on the DEX.