On August 23rd, CKB released its Lightning Network Fiber Network litepaper. Having been studying Lightning Network technology in-depth recently, I immediately conducted research on Fiber, which led to this article.
Compared to the BTC Lightning Network, Fiber introduces its own design considerations. Additionally, due to the characteristics of the eUTXO model and the CKB network, Fiber presents several unique technical features.
Since Lightning Labs developed Taproot Asset, the Lightning Network has finally expanded in terms of asset issuance. However, in a typical Lightning Channel, the logic behind Taproot Asset transfers works as follows:
Produced by Dapangdun
The transfer of Taproot assets is achieved through a combination of Taproot Channel and an “exchange rate conversion” method. The advantage of this approach is that it can reuse the current Lightning Channel architecture, which inherently maintains security and is relatively simple to implement. However, the downside is that this design does not allow for the direct transfer of Taproot assets within the channel.
In Fiber, assets are transferred directly within the channel, as illustrated in the following conceptual diagram:
Produced by Dapangdun
The BTC Lightning Network currently uses HTLC (Hashed Time-Locked Contract) technology, which works sufficiently well in practice. However, HTLC has a potential vulnerability: it can compromise the privacy of the Lightning Network, particularly in multi-hop scenarios.
Technically, HTLC uses the same preimage across the entire “multi-hop” path. Since the preimage is randomly generated by the recipient, the likelihood of two different payments using the same preimage is low. However, if an entity (such as an individual or a company) controls multiple nodes along a payment path, they could combine the input from one node and the output from another to reconstruct the full transaction information. This entity could then apply heuristics (based on path length, node type, etc.) to deduce which node is the payer and which is the recipient, undermining the privacy protections of onion routing.
In contrast, PTLC (Point Time-Locked Contracts) ensures that each hop in the path uses a different secret value, thus preserving privacy across the multi-hop route. Fiber Network adopts PTLC technology to achieve this enhanced privacy.
For more details on this technical aspect, refer to the following article:
What is Point Time-Locked Contract (PTLC)? Bitcoin Thought Collection (Chinese) www.btcstudy.org
Fiber’s overall design is rooted in the BTC Lightning Network, so it inevitably “inherits” some of the existing problems, one of the most notable being the liquidity management challenge.
In the BTC Lightning Network, managing channel liquidity can be quite cumbersome. Liquidity is required for both receiving and sending payments, so scenarios that require adjusting channel liquidity are unavoidable. Current solutions, whether using techniques like “submarine swaps,” “JIT (Just-In-Time),” or “channel splicing,” often necessitate users making 1-2 on-chain transactions on the Bitcoin mainnet. Given the slow confirmation times on the BTC mainnet and potentially high gas fees, this can lead to a frustrating user experience.
In Fiber, while the proposed “LSP (Liquidity Service Provider) + Submarine Swap” solution does not completely eliminate the liquidity management issues, the cost of submitting a CKB transaction is very low, and the waiting time is much shorter. This significantly improves the user experience compared to BTC’s network.
Fiber is not confined to the CKB network. By using an “intermediary redemption” model, Fiber enables a 1:1 conversion between BTC and CCBTC (a wrapped BTC on the CKB network). This setup functions somewhat like a “lightning bridge.” Moreover, this bridge can be decentralized, allowing ordinary users who hold these assets to participate as “redeemers” and offer this service.
Thinking further, BTC could use this model to swap with other assets within the CKB network, simply by accepting exchange rates from a public Oracle service.
Of course, this is currently in the conceptual design phase, and further observation will be needed to see how it unfolds during actual development.
Produced by Dapangdun
Aside from the issues Fiber “inherits” from the BTC Lightning Network, there are some additional concerns specific to Fiber itself that are worth discussing.
The BTC Lightning Network was developed as a solution to address the “small block limit” and “high confirmation times” on the Bitcoin mainnet, aiming to significantly reduce fees and increase TPS (transactions per second) for payments.
For the CKB network, however, tests have shown that the current fee for a single transfer is around 0.0000183 CKB. Given the current price of CKB (~0.01 USD), this translates to a fee of approximately 0.000000183 USD—an extremely low amount. Even if we consider a tenfold increase in the price of CKB and a tenfold increase in network congestion, the fee for a single transaction would still only be 0.0000183 USD, which remains very low.
Therefore, the necessity for a Lightning Network on CKB, compared to BTC, is clearly less compelling. The CKB network already offers extremely low transaction costs, making the case for implementing a Lightning Network less strong than it is for the BTC network.
Produced by Dapangdun
At the same time, considering that Lightning payments face issues such as operational difficulties for nodes, the requirement for both parties to be online during payment, and insufficient capital efficiency, although there are ways to mitigate these challenges, the necessity for a Lightning Network on CKB does not seem as compelling.
However, we can also look at the issue from a few other perspectives:
Fiber’s Lightning model is based on “Daric,” which is a traditional P2P (peer-to-peer) model. However, if we look at the recent market trends of the BTC Lightning Network, the P2P model is encountering significant challenges. The market is shifting toward LSP (Liquidity Service Provider) custodial solutions, and the shutdown of Mutiny Wallet further underscores this point. The fact that the LSP service under Mutiny also announced its cessation of operations casts doubt on whether the LSP custodial model is sustainable in the long run.
I believe we need to closely monitor the future developments in the Lightning model.
I have always held respect for the CKB development team. As I’ve mentioned before, I respect teams that are still willing to explore and innovate, especially those from the East, regardless of success or failure. Therefore, I have expectations for Fiber and have considered some possible directions for its future, which I’d like to share here.
From its inception, the CKB network introduced a new architecture. I am particularly eager to see if its unique network features can drive further innovation in the Lightning Network. For example:
Innovation is always the primary productive force and a treasure trove in this market!
The Lightning Network has a general issue: where exactly should its use cases be? While we have millions of TPS available, what real-world scenarios require such high interaction demand? Or rather, in what scenarios is the Lightning Network absolutely necessary or the only viable solution?
I’ve previously considered scenarios like streaming payments, gaming, and even dabbled in LAPP (Lightning Apps). However, projects in these areas have either failed to gain traction or have already “died out.” So, Fiber will face the same challenge—where should the use cases be?
I hope Fiber can identify or even “create” more demand scenarios for the Lightning Network. Technology only demonstrates its value when it’s grounded in practical applications; otherwise, it risks becoming nothing more than a “plaything for geeks.” However, in my discussions with related parties, I’ve learned that the CKB team is very aware of this and is actively working on it. I look forward to seeing their continued progress in this area.
On August 23rd, CKB released its Lightning Network Fiber Network litepaper. Having been studying Lightning Network technology in-depth recently, I immediately conducted research on Fiber, which led to this article.
Compared to the BTC Lightning Network, Fiber introduces its own design considerations. Additionally, due to the characteristics of the eUTXO model and the CKB network, Fiber presents several unique technical features.
Since Lightning Labs developed Taproot Asset, the Lightning Network has finally expanded in terms of asset issuance. However, in a typical Lightning Channel, the logic behind Taproot Asset transfers works as follows:
Produced by Dapangdun
The transfer of Taproot assets is achieved through a combination of Taproot Channel and an “exchange rate conversion” method. The advantage of this approach is that it can reuse the current Lightning Channel architecture, which inherently maintains security and is relatively simple to implement. However, the downside is that this design does not allow for the direct transfer of Taproot assets within the channel.
In Fiber, assets are transferred directly within the channel, as illustrated in the following conceptual diagram:
Produced by Dapangdun
The BTC Lightning Network currently uses HTLC (Hashed Time-Locked Contract) technology, which works sufficiently well in practice. However, HTLC has a potential vulnerability: it can compromise the privacy of the Lightning Network, particularly in multi-hop scenarios.
Technically, HTLC uses the same preimage across the entire “multi-hop” path. Since the preimage is randomly generated by the recipient, the likelihood of two different payments using the same preimage is low. However, if an entity (such as an individual or a company) controls multiple nodes along a payment path, they could combine the input from one node and the output from another to reconstruct the full transaction information. This entity could then apply heuristics (based on path length, node type, etc.) to deduce which node is the payer and which is the recipient, undermining the privacy protections of onion routing.
In contrast, PTLC (Point Time-Locked Contracts) ensures that each hop in the path uses a different secret value, thus preserving privacy across the multi-hop route. Fiber Network adopts PTLC technology to achieve this enhanced privacy.
For more details on this technical aspect, refer to the following article:
What is Point Time-Locked Contract (PTLC)? Bitcoin Thought Collection (Chinese) www.btcstudy.org
Fiber’s overall design is rooted in the BTC Lightning Network, so it inevitably “inherits” some of the existing problems, one of the most notable being the liquidity management challenge.
In the BTC Lightning Network, managing channel liquidity can be quite cumbersome. Liquidity is required for both receiving and sending payments, so scenarios that require adjusting channel liquidity are unavoidable. Current solutions, whether using techniques like “submarine swaps,” “JIT (Just-In-Time),” or “channel splicing,” often necessitate users making 1-2 on-chain transactions on the Bitcoin mainnet. Given the slow confirmation times on the BTC mainnet and potentially high gas fees, this can lead to a frustrating user experience.
In Fiber, while the proposed “LSP (Liquidity Service Provider) + Submarine Swap” solution does not completely eliminate the liquidity management issues, the cost of submitting a CKB transaction is very low, and the waiting time is much shorter. This significantly improves the user experience compared to BTC’s network.
Fiber is not confined to the CKB network. By using an “intermediary redemption” model, Fiber enables a 1:1 conversion between BTC and CCBTC (a wrapped BTC on the CKB network). This setup functions somewhat like a “lightning bridge.” Moreover, this bridge can be decentralized, allowing ordinary users who hold these assets to participate as “redeemers” and offer this service.
Thinking further, BTC could use this model to swap with other assets within the CKB network, simply by accepting exchange rates from a public Oracle service.
Of course, this is currently in the conceptual design phase, and further observation will be needed to see how it unfolds during actual development.
Produced by Dapangdun
Aside from the issues Fiber “inherits” from the BTC Lightning Network, there are some additional concerns specific to Fiber itself that are worth discussing.
The BTC Lightning Network was developed as a solution to address the “small block limit” and “high confirmation times” on the Bitcoin mainnet, aiming to significantly reduce fees and increase TPS (transactions per second) for payments.
For the CKB network, however, tests have shown that the current fee for a single transfer is around 0.0000183 CKB. Given the current price of CKB (~0.01 USD), this translates to a fee of approximately 0.000000183 USD—an extremely low amount. Even if we consider a tenfold increase in the price of CKB and a tenfold increase in network congestion, the fee for a single transaction would still only be 0.0000183 USD, which remains very low.
Therefore, the necessity for a Lightning Network on CKB, compared to BTC, is clearly less compelling. The CKB network already offers extremely low transaction costs, making the case for implementing a Lightning Network less strong than it is for the BTC network.
Produced by Dapangdun
At the same time, considering that Lightning payments face issues such as operational difficulties for nodes, the requirement for both parties to be online during payment, and insufficient capital efficiency, although there are ways to mitigate these challenges, the necessity for a Lightning Network on CKB does not seem as compelling.
However, we can also look at the issue from a few other perspectives:
Fiber’s Lightning model is based on “Daric,” which is a traditional P2P (peer-to-peer) model. However, if we look at the recent market trends of the BTC Lightning Network, the P2P model is encountering significant challenges. The market is shifting toward LSP (Liquidity Service Provider) custodial solutions, and the shutdown of Mutiny Wallet further underscores this point. The fact that the LSP service under Mutiny also announced its cessation of operations casts doubt on whether the LSP custodial model is sustainable in the long run.
I believe we need to closely monitor the future developments in the Lightning model.
I have always held respect for the CKB development team. As I’ve mentioned before, I respect teams that are still willing to explore and innovate, especially those from the East, regardless of success or failure. Therefore, I have expectations for Fiber and have considered some possible directions for its future, which I’d like to share here.
From its inception, the CKB network introduced a new architecture. I am particularly eager to see if its unique network features can drive further innovation in the Lightning Network. For example:
Innovation is always the primary productive force and a treasure trove in this market!
The Lightning Network has a general issue: where exactly should its use cases be? While we have millions of TPS available, what real-world scenarios require such high interaction demand? Or rather, in what scenarios is the Lightning Network absolutely necessary or the only viable solution?
I’ve previously considered scenarios like streaming payments, gaming, and even dabbled in LAPP (Lightning Apps). However, projects in these areas have either failed to gain traction or have already “died out.” So, Fiber will face the same challenge—where should the use cases be?
I hope Fiber can identify or even “create” more demand scenarios for the Lightning Network. Technology only demonstrates its value when it’s grounded in practical applications; otherwise, it risks becoming nothing more than a “plaything for geeks.” However, in my discussions with related parties, I’ve learned that the CKB team is very aware of this and is actively working on it. I look forward to seeing their continued progress in this area.