CKB: Lightning Network promotes new situation, and the application scenarios need to be strengthened

On August 23, CKB released its Lightning Network Fiber Network light paper. Recently, I have been studying the Lightning Network in depth and have gained some results, so I did some research on Fiber as soon as possible, and thus wrote this article.

1. Improvements of Fiber

Compared with the Lightning Network on BTC, Fiber has its own considerations in design. At the same time, due to the characteristics of eUTXO and CKB network, it also brings some unique technical points.

1. Asset transfer within the channel

After Lightning Labs developed Taproot asset, the Lightning Network finally ushered in the expansion of asset issuance, but the implementation logic of Taproot asset transfer in a general Lightning Channel is as follows:

Taproot asset enters and leaves the channel through the form of "exchange rate conversion" on both sides of the channel, and BTC is actually used in the channel. If you want to realize that the Taproot asset is used in the channel, then you need to improve the channel to become a "Taproot Channel", which may need to be solved in a form similar to sidechain.

In Fiber, assets are transferred directly within the channel, and the conceptual diagram of its implementation is as follows:

Taproot asset enters and leaves the channel through "exchange rate conversion" on both sides of the channel, and BTC is actually used in the channel. If you want to realize that the Taproot asset is used in the channel, then you need to improve the channel to become a "Taproot Channel", which may need to be solved in a form similar to sidechain.

In Fiber, assets are transferred directly within the channel, and the implementation concept diagram is as follows:

2. Adoption of PTLC

The lightning network on BTC uses HTLC technology. HTLC is actually good enough in actual use, but it still has the possibility of destroying the privacy of the lightning network.

In terms of technology, HTLC uses the same original image in the entire "multi-hop" path. At the same time, given that the original image is randomly generated by the payee, it is unlikely that two different payments use the same original image. Therefore, if an entity (individual, company, etc.) controls multiple nodes on a payment path, it can obtain complete transaction information based on the input obtained by a node and the output of another node. Then, this entity can use some heuristic method (based on the path length or node type) to guess which node in the path is the payer and which node is the payee. The efforts made by onion routing in terms of privacy will be destroyed.

With PTLC, each hop in the path uses a different secret value. In this way, the privacy achieved by onion routing is protected.

3. Alleviate the problems encountered by BTC Lightning Network

Fiber's overall design is derived from BTC's Lightning Network, so some problems of the current Lightning Network have also been "inherited", such as the very important "liquidity management" problem.

In the BTC lightning network, the management of channel liquidity is a very troublesome thing, but because the entry requires liquidity, and the collection also requires liquidity, we inevitably have to involve the scenario of adjusting channel liquidity. The current solutions, whether it is "submarine swap", "JIT", or "channel splicing", will involve the problem of requiring users to conduct 1-2 transactions on the main network. The BTC main network confirmation is slow, and the gas may be high, which will make people confused or have a bad experience.

In Fiber, although the "LSP+submarine swap" solution currently revealed has not gotten rid of the problems of this liquidity solution, the cost of submitting a ckb transaction is very low, and the waiting time is also very short, and the user experience will be much better.

4. Interoperability with BTC Lightning Network

Fiber is not limited to the CKB network. It can achieve 1:1 conversion between BTC and CCBTC through the "intermediate acceptor" model. This method is somewhat similar to building "a lightning bridge", and this solution can be decentralized, that is, ordinary people who have such assets can also participate in providing such services and act as "acceptors".

If we think further, BTC can directly swap other assets in the CKB network in this way, just accept the exchange rate quote of the public Oracle.

Of course, it is currently in the conceptual design stage, and the actual development situation needs to be observed.

2. Issues with Fiber

Of course, in addition to the problems that need to be faced together due to "inheritance", Fiber also has some problems that need to be discussed.

1. Necessity

The development of BTC's Lightning Network is a solution born out of "small block restrictions" and "extremely high confirmation time on the main network". The goal is to improve these problems in the payment field, achieve a significant reduction in fees and a significant increase in TPS. As for the CKB network, through testing, the current transfer fee is about 0.0000183ckb. Combined with the current price of ckb (~0.01U), the fee is about 0.000000183U, which is already very, very, very low. Even if we consider that the price of ckb increases 10 times and the ckb network is 10 times more congested, the fee of a transaction is only 0.0000183U, which is still very low. Therefore, the necessity of the Lightning Network is obviously insufficient compared to the BTC network. At the same time, considering that lightning payment still has problems such as [difficulty in operating and maintaining nodes], [requires both parties to pay online], and [insufficient capital utilization], although there are certain means to improve it, it seems that the necessity is not so strong.

Of course, we can also look at this issue from several angles:

1) From the perspective of payment speed, the block time of the CKB network is 8~48s, and the lightning network is basically close to "immediate payment", which improves the payment speed;

2) From the perspective of technological development, the CKB network itself has its own ecosystem, and the development of the lightning network is conducive to the development and expansion of the entire ecological technology map. In the future, other technologies such as ZK may also be introduced, which can also be viewed from this aspect.

2. Lightning model problem

The lightning model used by Fiber is based on "Daric", which is a traditional P2P model. However, if we look at the recent development of the BTC lightning network, the P2P model has encountered great problems. The entire market is turning to LSP hosting, and the closure of Mutiny wallet also confirms this.

Whether the current lightning model will undergo a major change in direction, I think it is possible. Once this happens, the future framework may undergo major changes, and Fiber based on the Daric model may need to be reshaped.

Therefore, in-depth thinking about the lightning industry should be very necessary to find the "end game".

3. Outlook for Fiber

I have always respected the CKB development team. I have said the reason before, that is, I respect the team that is still willing to explore and develop, especially the Eastern team, regardless of success or failure. Therefore, I have expectations for Fiber. I have thought about the direction that may be prospected or considered, and I would like to share it here.

1. How to make use of the advantages of the ckb network to innovate

The CKB network introduced a new architecture at the beginning of its design. So whether it can make use of its network characteristics to make more innovations on the lightning network is the direction I am looking forward to. For example:

1) How to perfectly solve the problem of offline payment?

2) Can the liquidity management problem be dealt with from the fundamental design framework?

3) Can the difficulty of interaction in multi-channels be cured?

4)……

Innovation is always the first productive force and the cornucopia of this market!

2. Build more lightning demand scenarios

There is a universal problem in the lightning network, that is, where should the application scenarios of the lightning network be? We have millions of TPS, but in reality, what situations have such strong interactive needs? Or what scenarios are very necessary or can only be solved through the Lightning Network?

I have considered "streaming payment" and "game", and "LAPP" was derived for a time, but these types of projects on the market either have not improved or have "died", so the scenarios should be left there, and Fiber will also encounter such a problem.

I hope Fiber can explore or even "build" more lightning demand scenarios. Technology can only reflect its value when it is put into practice, otherwise it will easily become a "geek's plaything". However, in my conversations with relevant personnel, I learned that the CKB team attaches great importance to this and I hope to see their continuous progress in this regard.