Author: Faust & Nickqiao, Geek Web3; Original link: System Interpretation of Fiber: A Grand Experiment of Integrating the Lightning Network onto CKB
On August 23, the CKB team released a Lightning Network solution based on CKB — Fiber Network. This news quickly sparked heated discussions in the community, causing the price of CKB to rise nearly 30% in a single day. The strong reaction to the news is mainly due to the powerful narrative appeal of the Lightning Network, and Fiber's upgrades to the traditional Lightning Network, which made numerous improvements.
For example, Fiber can natively support multiple types of assets, such as CKB, BTC, stablecoins, etc., and the transaction fees on CKB are much lower than those on BTC, with faster response times, allowing Fiber to achieve breakthroughs in user experience (UX). Additionally, Fiber has made significant optimizations in terms of privacy and security.
Moreover, Fiber can interconnect with the BTC Lightning Network, forming a larger P2P network. In previous offline events, the CKB team even stated that they would set up 100,000 physical nodes in Fiber and the Lightning Network to promote the improvement and advancement of the P2P payment network. Undoubtedly, this is an unprecedented grand story.
If the CKB team's vision is realized in the future, it will be a huge boon for both the Lightning Network and CKB, as well as the Bitcoin ecosystem. According to mempool data, currently, over $300 million is allocated in the BTC Lightning Network, with approximately 12,000 nodes, creating nearly 50,000 payment channels among them.
On spendmybtc.com, we can also see an increasing number of merchants supporting Lightning Network payments. As the recognition of BTC grows stronger, the momentum for the rise of off-chain payment solutions like the Lightning Network and Fiber will undoubtedly increase.
With the aim of systematically interpreting Fiber's technical solution, "Geek Web3" has written this research report on the overall Fiber scheme. As a Lightning Network implementation based on CKB, Fiber's principles are largely consistent with those of the Bitcoin Lightning Network, but many details have been optimized.
The overall architecture of Fiber includes the following four core components: payment channels, Watchtower, multi-hop routing, and cross-domain payments. Below, we will first explain the most important "payment channels."
The Cornerstone of the Lightning Network and Fiber: Payment Channels#
Payment channels essentially move transfers/transactions off-chain, and after a period, the final state is submitted on-chain for "settlement." Since transactions are completed off-chain instantaneously, they can often escape the performance limitations of main chains like BTC.
Suppose Alice and Bob jointly open a channel. They first create a multi-signature account on-chain and deposit some money into it, for example, Alice and Bob each deposit 100 units as their respective balances in the off-chain channel. Next, both parties can conduct multiple transfers within the channel, and when exiting the channel, they synchronize the final balances on-chain, with the multi-signature account making payments to both parties, i.e., "settlement."
For instance, if both parties start with 100 units each, and then Alice transfers 50 to Bob, followed by Alice transferring another 10 to Bob, and then Bob transfers 30 back to Alice, the final balances will be: Alice — 70, Bob — 130. It is easy to see that the total balance of both parties remains unchanged, and the example of the abacus beads moving back and forth illustrates this point well.
If one party exits the channel, the current balances Alice: 70/Bob: 130 are synchronized on-chain, and the 200 units in the multi-signature account are distributed according to their respective balances, completing the settlement. The above process seems simple, but many complex situations must be considered in practice.
First, you actually do not know when the other party wants to exit the channel. In the above example, Bob could exit right after the second transfer or right after the first transfer, and the payment channel does not enforce any strict requirements, allowing participants to exit freely. To achieve this, it must be assumed that someone may exit at any time, and either party may submit the final balance on-chain for settlement.
Thus, there is a setting for a "commitment transaction," which is used to declare the latest balances of both parties in the channel, and a corresponding "commitment transaction" is generated for each transfer that occurs. If you want to exit the channel, you can submit the latest "commitment transaction" on-chain to withdraw your entitled funds from the multi-signature account.
We can note this conclusion: commitment transactions are used for on-chain settlement of the balances of both parties in the channel, and either party can submit the latest commitment transaction on-chain at any time and then exit the channel.
However, there is an important malicious scenario: Bob can submit an outdated balance and commitment transaction on-chain. For example, after the generation of Commit Tx3 in the above image, Bob's balance is 130, but to profit himself, Bob submits the outdated Commit Tx2 on-chain, claiming his balance is 160, and this balance state is not real-time, which is a typical case of "double spending."
To prevent such double-spending scenarios, appropriate punitive measures must be in place, and the design of these punitive measures is precisely the core of the entire 1-to-1 payment channel. Understanding this part is essential to truly grasp payment channels. In the design of the channel, if either party submits an outdated state and Commit Tx on-chain, not only will they not achieve their goal, but the other party will also be able to withdraw all funds.
This involves the concepts of "asymmetric commitment transactions" and "revocation keys," both of which are very important. Let's first explain "asymmetric commitment transactions." Taking the previous Commit Tx3 as an example, the following image illustrates the commitment transaction:
This commitment transaction is constructed by Bob and then sent to Alice for her to handle. As shown, this is a Bitcoin transfer, declaring that 70 units from the multi-signature account go to Alice and 130 units go to Bob, but the unlocking conditions are "asymmetric," with Alice facing stricter limitations, which is more favorable to Bob.
After Alice receives the commitment transaction constructed by Bob, she can attach her signature to satisfy the 2/2 multi-signature requirement. After that, Alice can proactively submit the "commitment transaction" on-chain, allowing her to exit the channel. If she does not do this, she can continue to transfer funds within the channel.
Here we need to note: this commitment transaction is actively constructed by Bob, with conditions unfavorable to Alice. Alice can only accept or reject it, and we need to find a way to give Alice some autonomy. In the design of the payment channel, only Alice herself can put the "unfavorable" commitment transaction on-chain to trigger it, because the commitment transaction requires a 2/2 multi-signature, and after Bob constructs the transaction locally, he only has his signature and not Alice's.
Alice can "only receive Bob's signature but not send her own signature to him," which is like a contract unfavorable to you that requires both you and someone else to sign. The other party signs first and then gives you the document, and you can prevent the other party from obtaining your signature. You want the contract to take effect, so you sign and publicize it; if you do not want it to take effect, you do not sign or publicize it. Clearly, in the above case, Alice has a way to restrict Bob.
Now to the key point: every time a transfer occurs in the channel, a pair of commitment transactions will appear, with two similar mirrored versions, as shown below. Alice and Bob can each construct commitment transactions favorable to themselves, declaring the amounts they should receive upon exit, and then send the transaction content to each other for processing.
Interestingly, these two commitment transactions declare the "amount received upon exit" to be the same, but the withdrawal conditions differ, which is precisely the origin of the earlier mentioned "asymmetric commitment transactions."
As explained earlier, each commitment transaction requires a 2/2 multi-signature to take effect. The commitment transaction constructed locally by Bob, which is favorable to him, does not satisfy the 2/2 multi-signature requirement, while the commitment transaction that satisfies the 2/2 multi-signature is held by Alice, and Bob cannot submit it; it can only be submitted by Alice, creating a balance of power. The reverse is also true.
In this way, Alice and Bob can only actively submit commitment transactions unfavorable to themselves. As long as one party submits the Commit Tx on-chain and it takes effect, the channel will be closed. Returning to the earlier mentioned "double spending" scenario, what happens if someone submits an outdated commitment transaction on-chain?
Here we need to mention something called a "revocation key." If Bob submits an outdated commitment transaction on-chain, Alice can use the revocation key to withdraw the funds that Bob is entitled to.
Looking at the following image, suppose the latest commitment transaction is Commit Tx3, and Commit Tx2 is outdated. If Bob submits the outdated Tx2 on-chain, Alice can use the revocation key of Tx2 to withdraw Bob's funds (Alice must act within the time lock range).
For the latest Tx3, Alice does not have its revocation key; she can only obtain the revocation key for Tx3 after Tx4 appears in the future. This is determined by the characteristics of public-private key cryptography and UTXO, and due to space constraints, this article will not delve into the implementation principles of revocation keys.
We can remember this conclusion: as long as Bob dares to submit an outdated commitment transaction on-chain, Alice can take Bob's money using the revocation key as a punishment. Conversely, if Alice commits wrongdoing, Bob can also punish her in the same way. In this way, the 1-to-1 payment channel can effectively avoid double spending, as long as the participants are rational individuals, none will dare to act maliciously.
Regarding payment channels, Fiber based on CKB has made significant optimizations compared to the Bitcoin Lightning Network, enabling native support for transfers/transactions of multiple asset types, such as CKB, BTC, and RGB++ stablecoins, while the Lightning Network can only natively support Bitcoin. Even with the launch of Taproot Asset, the Bitcoin Lightning Network still cannot natively support non-BTC assets and can only indirectly support stablecoins.
(Image source: Dapangdun)
(Image source: Dapangdun)
Additionally, since the L1 main chain that Fiber relies on is CKB, the fees for opening and closing channels are much lower, unlike the BTC Lightning Network, which can consume a lot of user fees, making it a clear advantage in terms of UX.
Around-the-Clock Security: Watchtower#
The revocation key mentioned earlier has a problem: channel participants must constantly monitor each other to prevent the other party from secretly submitting outdated commitment transactions on-chain. But no one can guarantee being online 24/7; what if the other party commits wrongdoing while you are offline?
To address this, both Fiber and the Bitcoin Lightning Network have designed Watchtower, which will help users monitor on-chain activities around the clock. Once someone in the channel submits an outdated commitment transaction, the Watchtower will promptly handle it to ensure the safety of the channel and funds.
The specific explanation is as follows: for each outdated commitment transaction, Alice or Bob can pre-construct the corresponding punitive transaction (using the revocation key to handle the outdated commitment transaction, with the beneficiary declared as themselves) and then send the plaintext of the punitive transaction to the Watchtower. Once the Watchtower detects that someone has submitted an outdated commitment transaction on-chain, it will also submit the punitive transaction on-chain for targeted punishment.
To protect the privacy of channel participants, Fiber only allows users to send the "hash of the outdated commitment transaction + plaintext of the punitive transaction" to the Watchtower, so the Watchtower initially does not know the plaintext of the commitment transaction, only its hash. Unless someone truly submits an outdated commitment transaction on-chain, the Watchtower will only see the plaintext and then subsequently submit the punitive transaction on-chain. In this way, unless someone truly commits wrongdoing, the Watchtower will not see the transaction records of channel participants (even if it does, it can only see one of them).
Here we should mention the optimization of Fiber compared to the Bitcoin Lightning Network. The aforementioned punitive mechanism related to the revocation key is called "LN-Penalty," and the Bitcoin Lightning Network's LN-Penalty has obvious drawbacks: the Watchtower must store all outdated commitment transaction hashes and their corresponding revocation keys, which can create significant storage pressure.
As early as 2018, the Bitcoin community proposed a solution called "eltoo" to address this issue, but it requires a Bitcoin fork to support the SIGHASH_ANYPREVOUT opcode. The idea is that when an outdated commitment transaction is submitted on-chain, the latest commitment transaction can punish it, allowing users to only store the latest commitment transaction. However, the SIGHASH_ANYPREVOUT opcode has yet to be activated, and the solution has not been implemented.
Fiber has implemented the Daric protocol, modifying the design of the revocation key so that the same revocation key can be applied to multiple outdated commitment transactions. This can significantly reduce the storage pressure on the Watchtower and user clients.
The Traffic System in the Network: Multi-Hop Routing and HTLC/PTLC#
The payment channels discussed earlier are only suitable for 1-to-1 transaction scenarios, while the Lightning Network supports multi-hop payments, meaning that transfers can occur between two parties that do not have a direct channel by routing through intermediate nodes. For example, if Alice and Ken do not have a channel, but Ken has a channel with Bob, and Bob has a channel with Alice, Bob can act as an intermediary between Alice and Ken, allowing transfers to occur. "Multi-hop routing" refers to constructing transfer paths through multiple intermediaries.
"Multi-hop routing" can enhance the flexibility and coverage of the network. However, the sender needs to be aware of the status of all public nodes and channels. In Fiber, all public channels and the network structure are completely open, and any node can obtain the network information held by other nodes. Since the state of the entire network in the Lightning Network is constantly changing, Fiber will use Dijkstra's shortest path algorithm to find the shortest routing path, minimizing the number of intermediaries, and then establish a transfer path between the two parties.
However, there is a need to address the trust issue of intermediate nodes: how can you ensure they are honest? For instance, if Alice wants to transfer 100 units to Ken through the intermediary Bob, Bob could potentially withhold the funds. To prevent intermediaries from acting maliciously, HTLC and PTLC are used to solve such problems.
Suppose Alice wants to pay Daniel 100 units, but they do not have a channel established. Alice discovers that she can pay Daniel through the two intermediaries Bob and Carol. In this case, HTLC is introduced as the payment channel. First, Alice initiates a request to Daniel, who then sends Alice a hash r, but Alice does not know the plaintext R corresponding to r.
Next, Alice constructs the payment terms with Bob using HTLC: Alice is willing to pay Bob 102 units, but Bob must reveal the key R within 30 minutes; otherwise, Alice will withdraw her funds. Similarly, Bob creates HTLC with Carol: Bob will pay Carol 101 units, but Carol must reveal the key R within 25 minutes; otherwise, Bob will withdraw his funds.
Carol does the same with Daniel: Carol is willing to pay 100 units, but Daniel must tell her the plaintext R within 20 minutes; otherwise, the funds will be reclaimed by Carol.
Daniel understands that the key R requested by Carol is actually what Alice wants because no one else cares about the content of R. Therefore, Daniel cooperates with Carol, tells her the content of R, and receives 100 units from Carol. This way, Alice achieves her goal of paying Daniel 100 units.
The subsequent events are easy to imagine: Carol tells Bob the key R and receives 101 units; Bob then tells Alice the key R and receives 102 units. Observing the gains and losses of everyone, we can see that Alice loses 102 units, while Bob and Carol each net 1 unit, and Daniel receives 100 units. The 1 unit earned by Bob and Carol is the fee they extracted from Alice.
Even if someone in the above payment path gets stuck, for example, if Carol does not inform Bob of the key R, Bob will not incur a loss: after some time, Bob can withdraw the constructed HTLC. The same applies to Alice.
However, the Lightning Network also has issues: the path should not be too long. If the path is too long with too many intermediaries, it will reduce the reliability of the payment. Some intermediaries may be offline, or they may not have enough balance to construct a specific HTLC (for example, each intermediary in the previous case must have over 100 units). Therefore, adding an intermediary to the path increases the likelihood of errors.
Additionally, HTLC may leak privacy. Although onion routing can provide some privacy protection by encrypting the routing information at each hop, allowing only the initial sender Alice to know the complete path, HTLC is still prone to correlation inference. From a god's-eye view, consider the following path:
Suppose Bob and Daniel are two nodes controlled by the same entity, and they receive many HTLCs from various users daily. They notice that every time Alice and Carol send HTLCs, the keys they want to know are always the same, while the downstream node Eve connected to Daniel always knows the content of the key R. Therefore, Daniel and Bob can infer that there is a payment path between Alice and Eve because they are always associated with the same key, allowing them to deduce the relationship between Alice and Eve and impose surveillance.
To address this, Fiber adopts PTLC, which improves privacy over HTLC, as each PTLC in the payment path uses a different key for unlocking, making it impossible to determine the correlation by merely observing the keys requested by PTLC. By combining PTLC with onion routing, Fiber becomes an ideal solution for privacy payments.
Moreover, the traditional Lightning Network faces the "replacement cycling attack" scenario, which can lead to the theft of the assets of intermediaries in the payment path. This discovery even led developer Antoine Riard to withdraw from Lightning Network development. To date, the Bitcoin Lightning Network has not implemented fundamental measures to resolve this issue, which has become a pain point.
Currently, the CKB team has improved the transaction pool layer, allowing Fiber to address the aforementioned attack scenarios. Since the replacement cycling attack and its solutions are quite complex, this article will not delve further into the explanation. Interested readers can refer to the following article from BTCStudy and related materials from CKB:
https://www.btcstudy.org/2023/10/24/how-does-a-lightning-replacement-cycling-attack-work/
Overall, Fiber has made significant improvements over the traditional Lightning Network in terms of both privacy and security.
Cross-Domain Atomic Payments Between Fiber and the Bitcoin Lightning Network#
Using HTLC and PTLC, Fiber can achieve cross-domain payments with the Bitcoin Lightning Network while ensuring the "atomicity of cross-domain actions," meaning that all steps related to cross-domain actions either succeed entirely or fail entirely, with no partial success or failure.
With the guarantee of cross-domain atomicity, it can ensure that cross-domain actions do not lead to property losses, allowing Fiber to interconnect with the Bitcoin Lightning Network. For example, payment paths can be established in a hybrid network composed of Fiber and the Lightning Network, allowing direct transfers from Fiber to users in the BTC Lightning Network (the receiving end is limited to BTC) and enabling exchanges of equivalent Bitcoin using CKB and RGB++ assets in the BTC Lightning Network.
To briefly explain the principle: suppose Alice runs a node in the Fiber network, while Bob runs a node in the Bitcoin Lightning Network. If Alice wants to transfer some money to Bob, she can achieve this transfer through a cross-domain intermediary, Ingrid. Ingrid will run nodes in both the Fiber and BTC Lightning Network, acting as an intermediary in the transfer path.
If Bob wants to receive 0.001 BTC, Alice can negotiate an exchange rate with Ingrid to exchange 7550 CKB for 0.001 BTC. Then Alice sends 7551 CKB to Ingrid in Fiber, and Ingrid sends 0.001 BTC to Bob in the BTC Lightning Network, keeping 1 CKB as a fee.
The specific operation method is essentially to establish a payment path between Alice and Bob with Ingrid, i.e., Alice → Ingrid → Bob, and HTLC will be used. The same reasoning applies here; for Bob to receive the money, he must tell Ingrid the content of the key R. Once Ingrid obtains the key R, she can unlock the funds Alice locked in HTLC.
It is important to note that these two cross-domain actions occurring in the BTC Lightning Network and Fiber are atomic, meaning that either both HTLCs are unlocked, and the cross-domain payment is successfully executed, or neither is unlocked, and the cross-domain payment fails, preventing situations where Alice sends money but Bob does not receive it. (In fact, the intermediary Ingrid could choose not to unlock Alice's HTLC after knowing the key R, but this would harm Ingrid as the intermediary, not the user Alice, so Fiber's design is safe for users.)
This method allows for transfers between different P2P networks without requiring trust in a third party and requires almost no modifications.
Other Advantages of Fiber Compared to the BTC Lightning Network#
As mentioned earlier, Fiber supports native CKB assets and RGB++ assets (especially stablecoins), giving it great potential in instant payment scenarios, making it more suitable for everyday small payments.
Additionally, the Bitcoin Lightning Network has a major pain point regarding liquidity management. You may recall that we mentioned at the beginning that the total balance in a payment channel is fixed. If one party's balance is exhausted, they cannot transfer funds to the other party unless the other party first sends money to them, at which point they need to inject new funds or open a new channel.
Furthermore, in complex multi-hop networks, if some intermediate nodes lack sufficient balance to transfer funds outward, it may cause the entire payment path to fail. This is one of the pain points of the Lightning Network, and the solutions typically involve providing efficient liquidity injection solutions to ensure that most nodes can inject funds at any time.
However, in the BTC Lightning Network, the steps for injecting liquidity, opening, or closing channels are all conducted on the BTC chain. If BTC network fees are extremely high, it will adversely affect the UX of payment channels. For example, if you want to open a channel with a capacity of $100, but the operation costs $10 in fees, that means the channel has already consumed 10% of your funds at initialization, which is unacceptable to most people; the same applies to liquidity injection tasks.
In this regard, Fiber has a significant advantage. First, the TPS of CKB is much higher than that of BTC, with fees at the cent level; second, to address the issue of insufficient liquidity leading to the inability to transfer funds, Fiber plans to collaborate with other teams to launch new solutions, allowing liquidity injection tasks to be freed from on-chain operations, thus solving UX and cost issues.
Thus, we have systematically outlined the overall technical architecture of Fiber, and the rough comparison with the Bitcoin Lightning Network is summarized in the above image. Due to the numerous and complex knowledge points involved in Fiber and the Lightning Network, a single article may not cover all aspects. In the future, we will launch a series of articles on the topics of the Lightning Network and Fiber, so stay tuned.